> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xsoar-6-threat-intel-management-guides/6.14/configure-indicators/indicator-customization/indicator-fields/indicator-field-trigger-scripts.md).

# Indicator Field Trigger Scripts

You can associate indicator fields with trigger automation scripts that check for field changes, and then take actions based on them. These scripts can perform any action when the conditions are met. Indicator field trigger scripts allow indicators to become a proactive force within Cortex XSOAR. For example, you can:

* Define a script that will run when the **Verdict** field of an indicator has changed. For example, the script will fetch all incidents related to that indicator, and take any action that is configured (reopen, change severity, etc.).
* Define a script that will run when the **Expiration Status** field has changed. For example, you can define a script that will immediately update the relevant allow/block list (and not wait for the next iteration) as seen in the following script example:

  ```programlisting
  indicators = demisto.args().get('indicators')
  new_value = demisto.args().get('new')

  indicator_values = []
  for indicator in indicators:
      current_value = indicator.get('value')
      indicator_values.append(current_value)

  if new_value == "Expired":
      # update allow/block list regarding expired indicators
  else:
      # update allow/block list regarding active indicators
  ```

{% hint style="info" %}

### Note

You must have a TIM license to run field change triggered scripts on indicator fields.
{% endhint %}

Automations can be created in Python, PowerShell, or JavaScript in the Automation page. To use a field trigger automation, you need to add the **`field-change-triggered-indicator`** tag when creating the automation. You can then add the automation in the Attributes tab, when you edit or [Create a Custom Indicator Field](/cortex-xsoar-6-threat-intel-management-guides/6.14/configure-indicators/indicator-customization/indicator-fields/create-a-custom-indicator-field.md). If you did not add the tag when creating the automation, the automation will not be available for use.

**Automation Arguments - Related Information**

When an automation is triggered on a field, it has the following triggered field information available as arguments (args):

| Argument              | Description                                                                              |
| --------------------- | ---------------------------------------------------------------------------------------- |
| **`associatedToAll`** | If the field is associated to all or some incidents. Value: **`true`** or **`false`**.   |
| **`associatedTypes`** | An array of the incident types, with which the field is associated.                      |
| **`cliName`**         | The name of the field when called from the command line.                                 |
| **`description`**     | The description of the field.                                                            |
| **`indicators`**      | A list of indicators that had the current change.                                        |
| **`isReadOnly`**      | Specifies whether the field is non editable. Value: **`true`** or **`false`**.           |
| **`name`**            | The name of the field.                                                                   |
| **`new`**             | The new value of the field.                                                              |
| **`old`**             | The old value of the field.                                                              |
| **`ownerOnly`**       | Specifies that only the creator of the field can edit. Value: **`true`** or **`false`**. |
| **`placeholder`**     | The placeholder text.                                                                    |
| **`required`**        | Specifies whether this is a mandatory field. Value: **`true`** or **`false`**.           |
| **`selectValues`**    | If this is a multi-select type field, these are the values the field can take.           |
| **`system`**          | Whether it is a Cortex XSOAR defined field.                                              |
| **`type`**            | The field type.                                                                          |
| **`user`**            | The username of the user who triggered the script.                                       |

**Script Limitations and Best Practices**

* Indicator field trigger scripts react to changes that have already occurred to the field and cannot validate or block changes to the field.
* Indicator field trigger scripts can be configured on: **Verdict**, **Related Incidents**, **Expiration Status**, **Indicator Type**, and all custom indicator fields in the system.
* Indicator field trigger scripts work in all TIM (Threat Intelligence Management) scenarios and workflows, except for feed ingestion.
* Fields that may hold a list (related incidents, multi-select/tag/role type custom fields) will provide an array of the delta. For example, if a multi-select field value has changed from \["a"] to \["a", "b"], the new argument of the script will get a value of \["b"].
* Indicator field trigger scripts run as a batch. This means that if multiple indicators were changed in the same way and are set to trigger the same action, it will happen in one batch. For example:
  1. There's a configured indicator field trigger script named **`myTriggerScript`** on the **Verdict** indicator field.
  2. The Threat Intel Library has two existing Malicious indicators: 1.1.1.1, 2.2.2.2.
  3. The user runs the following command **`!setIndicators indicatorsValues="1.1.1.1,2.2.2.2" verdict=Benign`**.
  4. The **`myTriggerScript`** script will run just once, with the following parameters:
     * new - "Benign"
     * old - "Malicious"
     * indicators - "\[{\<indicator\_1.1.1.1>},{\<indicator\_2.2.2.2}]"
* When writing indicator field trigger scripts, it's crucial to avoid scenarios that will call the scripts endlessly (for example, a change in field A triggers script X, which changes field B's value, which in turn calls script Y, which changes field A's value).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://cortex-docs.paloaltonetworks.com/cortex-xsoar-6-threat-intel-management-guides/6.14/configure-indicators/indicator-customization/indicator-fields/indicator-field-trigger-scripts.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.