Use Incident Fields to accept or populate
incident data coming from incidents. You create fields for information
that arrives from third party integrations in which you want to
insert information. The fields are added to Incident Type layouts
and are mapped using the Classification and Mapping feature.
Incident Fields can be populated by the incident
team members during an investigation, at the beginning of the investigation,
or prior to closing the investigation.
Creating Incident Fields is an iterative process in which
you continue to create fields as you gain a better understanding
of your needs and the information available in the third party integrations
that you use.
You can set and update all system incident fields using the
setIncident
command,
of which each field is a command argument.
Incident Field Types
You can add the following field types, when adding a
new field.
Attachments : enables adding an attachment, such as .doc, malicious
files, reports, images of an incident, etc.
Boolean (checkbox)
Date picker
Grid (table): include an interactive, editable grid as a
field type for selected incident types or all incident types.
HTML
Long text
Markdown
Multi select
Number: can contain any number. The default number is 0.
Any quantity can be used.
Role: roles assigned to the incident determine which users
(by the role to which they are assigned) can view the incident.
Short text: maximum of 60,000 characters.
Single select
Tags
Timer/SLA: view how much time is left before an SLA becomes
past due, as well as configure actions to take in the event that
the SLA does pass.
URL
User : a user in the system to state a manager or fallback.
Basic Settings
The following table lists the fields that appear in
the Basic Settings page, and their descriptions. The Basic Settings
page is available for the following field types:
Long text
Mult select
Short text
Single select
Tags
Name
Description
Placeholder
Define the text that appears in the field before
users enter a value.
Values
A comma separated list of values that are valid
values for the field.
Timer/SLA Fields
The following table lists the fields specific to Timer/SLA
fields, and their descriptions.
Name
Description
SLA
Determine the amount of time in which this
item needs to be resolved. If no value is entered, the field serves
as a counter.
Risk Threshold
Determine the point in time at which an item
is considered at risk of not meeting the SLA. By default, the threshold
is 3 days, which is defined in the global system parameter.
Run on SLA Breach
In the Run on SLA Breach field, select the
script to run when the SLA time has passed. For example, email the
supervisor or change the assignee.
Only scripts to which
you have added the SLA tag appear in list of scripts that you can
select.
Attributes Parameters for Incident Fields
The following tables list the fields that are common
to all Incident Fields.
Name
Description
Script upon change
The script that dynamically changes the field
value when script conditions are met. For a script to be available,
it must have the
Determines which fields display in forms, as
well as the values that are available for single-select and multi-select
fields. For more information, see Create Dynamic Fields in Incident Forms.
Add to incident types
Determines for which incident types this field
is available. By default, fields are available to all incident types.
To change this, clear the
Associate to all
checkbox
and select the specific incident types to which the field is available.
Default display on
Determines at which point the field is available.
For more information, see Incident Field Examples.
Edit Permissions
Determines whether only the owner of the incident
can edit this field.
Make data available for search
Determines if the values in these fields are
available when searching.
In most cases, Cortex XSOAR recommends that
you select this checkbox so values in the field are available for indexing
and querying. However, in some cases, to avoid adverse affects on
performance, you should clear this checkbox. For example, if you
are ingesting an email to an email body field, we recommend that
you not index the field.
Add as optional graph
Determine if you can create a graph based on
the contents of this field. This field does not appear for all field
types.
Incident Field Examples
The following section shows several examples of common
fields that are used in real-life incidents.
False Positive
Below is an example of a mandatory Incident field "False Positive"
to be filled at time of Incident Close. The Field can have a value
YES or NO and the SOC admin should be able to query or run report
based on this field. After this field is added, all incidents will
need to have this filled in before an incident can be marked closed.
SLA Fields
The following SLA field can be used to trigger a notification
when the status effecting the SLA of an incident changes. If the
SLA is breached, we have configured the field such that an email
is sent to the owner's supervisor.
Troubleshooting Conflicts with Custom Incident Fields
When trying to download a content update, you receive
the following message:
Warning: content update has encountered some conflicts
This occurs when a content update has an incident field with
the same name as a custom incident field that already exists in
Cortex XSOAR.
Solution
Click
Install Content
to force the update
and retain your custom incident field. The content update will install
without the system version of the incident field.
