> 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/xsoar-6-administrator-guide/6.13/learn-about-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/incident-customization/incident-fields/incident-field-trigger-scripts.md). # Incident Field Trigger Scripts Incident fields can be associated with trigger automation scripts that can check for field change conditions and take actions based on the change. These scripts can perform any action, such as dynamically changing the field value, notifying the responder when an incident severity has been changed, etc., when the conditions are met. For example, when using the **`ChangeRemediationSLAOnSevChange`** automation, it changes the Remediation SLA of an incident, when the severity of the incident changes for any reason. 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 tag when creating the automation. You can then add the automation in the [Attributes](/xsoar-6-administrator-guide/6.13/learn-about-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/incident-customization/incident-fields.md) tab, when you edit or [Create a Custom Incident Field](/xsoar-6-administrator-guide/6.13/learn-about-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/incident-customization/incident-fields/create-a-custom-incident-field.md). If you did not add the tag when creating the automation, it cannot be added. Cortex XSOAR comes out-of-the-box with field change scripts in the Automation page, such as: * **`ChangeRemediationSLAOnSevChange`** * **`emailFieldTriggered`**: Changes the incident field when the email body or subject changes. * **`StopTimeToAssignOnOwnerChange`**: Stops the Time to Assignment SLA field, as soon as an owner was assigned to an incident. A common use case is to create the following automation that verifies that changes made by a playbook only will take place and not by a user manually. ```programlisting args = demisto.args() user = args["user"] if user: demisto.executeCommand("setIncident", {args["cliName"]: args["old"]}) ``` The automation checks who made the change using the **`user`** field. The **`cliName`** argument returns the field name, so that it can be attached to multiple incident fields, and block changes to them, without the need to have a different automation for each field. **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. | | **`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. | | **`unmapped`** | Whether it is not mapped to any incident. | | **`useAsKpi`** | Whether it is being used for tracking KPI on an incident page. | | **`user`** | The username of the user who triggered the script. | | **`validationRegex`** | Whether there is a regex associated for validation the values the field can hold. | **Script Limitations** * Trigger scripts cannot close incidents. * Post-processing scripts can modify an incident, but if a modified field has a trigger script, it is not called. * Incident modifications executed within a trigger script are only saved to the database after the modifications are completed. --- # 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/xsoar-6-administrator-guide/6.13/learn-about-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/incident-customization/incident-fields/incident-field-trigger-scripts.md?ask=&goal= ``` `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.