End-of-Life (EoL)
Field Trigger Scripts
Field change 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 tab,
when you edit or Create a Custom Incident Field. If you did
not add the tag when creating the automation, it cannot be added.
Cortex XSOAR comes out-of-the-box with the following field change
scripts in the Automation page:
- 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.
The ExtraHop Reveal(x) Content Pack contains a field trigger script,
which only tracks the incident if it is from an ExtraHop Detection.
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.
args = demisto.args() user = args["user"] if user: demisto.executeCommand("setIncident", {args["name"]: args["old"]})
The automation checks who made the change using the
user
field.
The name
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 false0 . |
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.
Recommended For You
Recommended Videos
Recommended videos not found.
