ServiceNow v2
This Integration is part of the ServiceNow Pack.#
IT service management. Cortex XSOAR interfaces with ServiceNow to help streamline security-related service management and IT operations. For example, you can use the ServiceNow integration in order to:
- View, create, update or delete a ServiceNow ticket directly from the Cortex XSOAR CLI, and enrich it with Cortex XSOAR data.
- View, create, update and delete records from any ServiceNow table.
- Query ServiceNow data with the ServiceNow query syntax.
- Manage Security Incident Response (SIR) tickets with Cortex XSOAR, update tickets and enrich them with data.
Please refer to ServiceNow documentation for additional information. We especially recommend the Operators available for filters and queries page.
This integration was integrated and tested with the Xanadu version of ServiceNow.
This is the default integration for this content pack when configured by the Data Onboarder in Cortex XSIAM.
Use cases#
- Get, update, create, and delete ServiceNow tickets, as well as add links and comments, or upload files to the tickets.
- Fetch newly created incidents.
- Get, update, create, delete records from any ServiceNow table.
Required Permissions#
To use ServiceNow on Cortex XSOAR, ensure your user account has the snc_platform_rest_api_access role. This role is required to make API calls. Also add to your user account the specific tables that you want to have access to. However, these permissions may not suffice for managing records in some tables. Make sure you have the correct role so you have permissions to work with the relevant table.
Wrapper Scripts#
There are 3 scripts that serve as examples for wrapping the following generic commands: servicenow-query-table - ServiceNowQueryIncident servicenow-create-record - ServiceNowCreateIncident servicenow-update-record - ServiceNowUpdateIncident
You can use these scripts if you want to wrap these commands around a ServiceNow table of your choice. These scripts are wrapped around the incident table, so to wrap them around another table simply copy the scripts and edit the code, arguments and outputs accordingly.
Configure ServiceNow v2 on Cortex XSOAR#
Navigate to Settings > Integrations > Servers & Services.
Search for ServiceNow v2.
Click Add instance to create and configure a new integration instance.
To ensure that mirroring works:
Select the Fetches incidents radio button.
Under Classifier, select ServiceNow Classifier.
Under Mapper (incoming), select ServiceNow - Incoming Mapper.
Under Mapper (outgoing), select ServiceNow - Outgoing Mapper.
To enable mirroring to close a ticket in Cortex XSOAR, under the Mirrored XSOAR Ticket closure method dropdown, select the ticket closing method, or set the Mirrored XSOAR Ticket custom close resolution code or Mirrored XSOAR Ticket custom close state code parameter, in order to override the default closure method with a custom close code or custom state. In order to use Mirrored XSOAR Ticket custom close resolution code or Mirrored XSOAR Ticket custom close state code parameter, it must follow this format: "custom_state_code1=custom_label1,custom_state_code2=custom_label2,...", for example: “10=Design,11=Development,12=Testing”. Also, a matching user-defined list of customized incident close reasons must be configured as a "Server configuration" in Cortex XSOAR. (Meaning each Service Now custom state label will have a matching Cortex XSOAR custom close reason with the same name). Not following this format will result in a server error! For more information about Customize Incident Close Reasons, see Cortex XSOAR 6.13 or Cortex XSOAR 8 Cloud or Cortex XSOAR 8.7 On-prem.
To enable mirroring to close an incident in ServiceNow, under the Mirrored ServiceNow Ticket closure method dropdown, select the ticket closing method, or set the Mirrored ServiceNow Ticket custom close state code parameter, in order to override the default closure method with a custom state.
Instance Creation Flow#
This integration supports two types of authorization:
- Basic authorization using username and password.
- OAuth 2.0 authorization
- JWT authentication.
OAuth 2.0 Authorization#
To use OAuth 2.0 authorization follow the next steps:
- Login to your ServiceNow instance and create an endpoint for XSOAR to access your instance (please see Snow OAuth for more information).
- Copy the
Client IdandClient Secret(press the lock next to the client secret to reveal it) that were automatically generated when creating the endpoint into theUsernameandPasswordfields of the instance configuration. - Select the
Use OAuth Logincheckbox and click theDonebutton. - Run the command
!servicenow-oauth-loginfrom the XSOAR CLI and fill in the username and password of the ServiceNow instance. This step generates an access token to the ServiceNow instance and is required only in the first time after configuring a new instance in the XSOAR platform. - (Optional) Test the created instance by running the
!servicenow-oauth-testcommand.
Notes:
- When running the
!servicenow-oauth-logincommand, a refresh token is generated and will be used to produce new access tokens after the current access token has expired. - Every time the refresh token expires you will have to run the
servicenow-oauth-logincommand again. Hence, we recommend setting theRefresh Token Lifespanfield in the endpoint created in step 1 to a long period (can be set to several years). - The grant type used to get an access token is
Resource owner password credentials. See the Snow documentation for more information.
JWT Authentication#
Prerequisites in order to support JWT#
- Create a Java Key Store and upload it to the instance. (Accessing from the upper menu :Al > System Definition > Certificates.) (Private key will be used as an integration parameter)
- Configure a JWT signing key (Use the keystore from above. Keep the Key ID. It will be used as kid integration parameter) (All > System OAuth > JWT Keys)
- Create a JWT provider with a JWT signing key (You are required to set in Standard Claims the same values for aud, iss, and sub that will be used as integration parameters. Claim Name sub in Standard Claims has to be an existing non-admin ServiceNow user with all necessary roles.)
(All > System OAuth > JWT providers) 4. Connect to an OAuth provider and create an OAuth application registry (aud in JWT provider has to be equal to Client ID from OAuth JWT application - update JWT provider If necessary. The value of kid in JWT Verifier Maps has to be the same as Key Id in JWT signing key. The value can be updated if necessary.) (All > System OAuth > Application Registry)
- Create an API Access Policy or add an Authentication profile to an existing Policy (All > System Web Services > API Access Policies > Rest API Access Policies )
IMPORTANT:
- Standard Authentication Profile of type Oauth should already be present in ServiceNow and needs to be added to the Policy. API Access Policy should be configured as global in order to cover all available resources and not just now/table
- Granting JWT to admin is not allowed. You should have a non-admin user with all necessary roles (only non-admin roles) in addition to the existing role snc_platform_rest_api_access that is required to make API calls.
Using Multi-Factor Authentication (MFA)#
MFA can be used both when using basic authorization and when using OAuth 2.0 authorization, however we strongly recommend using OAuth 2.0 when using MFA. If MFA is enabled for your user, follow the next steps:
- Open the Google Authenticator application on your mobile device and make note of the number. The number refreshes every 30 seconds.
- Enter your username and password, and append the One Time Password (OTP) that you currently see on your mobile device to your password without any extra spaces. For example, if your password is
12345and the current OTP code is424 058, enter12345424058.
Notes:
When using basic authorization, you will have to update your password with the current OTP every time the current code expires (30 seconds), hence we recommend using OAuth 2.0 authorization.
For using OAuth 2.0 see the above instructions. The OTP code should be appended to the password parameter in the
!servicenow-oauth-logincommand.Parameter Description Required ServiceNow URL, in the format https://company.service-now.com/ True Username/Client ID False Password False Use OAuth Login Select this checkbox if to use OAuth 2.0 authentication. See (?) for more information. False Default ticket type for running ticket commands and fetching incidents The ticket type can be: incident, problem, change_request, sc_request, sc_task or sc_req_item. False ServiceNow API Version (e.g. 'v1') False Fetch incidents False The query to use when fetching incidents False How many incidents to fetch each time False First fetch timestamp (<number> <time unit>, e.g., 12 hours, 7 days, 3 months, 1 year) False Timestamp field to filter by (e.g., opened_at) This is how the filter is applied to the query: "ORDERBYopened_at^opened_at>[Last Run]".
To prevent duplicate incidents, this field is mandatory for fetching incidents.False ServiceNow ticket column to be set as the incident name. Default is the incident number False Incident type False Get incident attachments False Incident Mirroring Direction Choose the direction to mirror the incident: Incoming (from ServiceNow to Cortex XSOAR), Outgoing (from Cortex XSOAR to ServiceNow), or Incoming and Outgoing (from/to Cortex XSOAR and ServiceNow). False Use Display Value Select this checkbox to retrieve comments and work notes without accessing the `sys_field_journal` table. False Instance Date Format Select the date format of your ServiceNow instance. Mandatory when using the `Use Display Value` option. More details under the troubleshooting section in the documentation of the integration. The integration supports the ServiceNow default time format (full form) HH:mm:sswith support toanotation for AM/PM.False Comment Entry Tag Choose the tag to add to an entry to mirror it as a comment in ServiceNow. False Work Note Entry Tag Choose the tag to add to an entry to mirror it as a work note in ServiceNow. False File Entry Tag To ServiceNow Choose the tag to add to an entry to mirror it as a file in ServiceNow. False File Entry Tag From ServiceNow Choose the tag to add to an entry to mirror it as a file from ServiceNow. False Timestamp field to query for updates as part of the mirroring flow According to the timestamp in this field, records will be queried to check for updates. False How many incidents to mirror incoming each time If a greater number of incidents than the limit were modified, then they won't be mirrored in. False Custom Fields to Mirror Custom (user defined) fields in the format: ufieldname1,u_fieldname2 custom fields start with a 'u'. These fields will be included in the mirroring capabilities, if added here. False Mirrored XSOAR Ticket closure method Define how to close the mirrored tickets in Cortex XSOAR. Choose 'resolved' to enable reopening from the UI. Otherwise, choose 'closed'. Choose 'None' to disable closing the mirrored tickets in Cortex XSOAR. False Mirrored XSOAR Ticket custom close state code Define how to close the mirrored tickets in Cortex XSOAR with a custom state. Enter here a comma-separated list of custom closure state codes and their labels (acceptable format example: “10=Design,11=Development,12=Testing”) to override the default closure method. Note that a matching user-defined list of custom close reasons must be configured as a "Server configuration" in Cortex XSOAR. Not following this format will result in closing the incident with a default close reason. False Mirrored XSOAR Ticket custom close resolution code Define how to close the mirrored tickets in Cortex XSOAR with a custom resolution code. Enter a comma-separated list of custom resolution codes and their labels (acceptable format example: “10=Design,11=Development,12=Testing”) to override the default closure method. Note that a matching user-defined list of custom close reasons must be configured as a "Server configuration" in Cortex XSOAR. Not following this format will result in closing the incident with a default close reason. False Mirrored ServiceNow Ticket closure method Define how to close the mirrored tickets in ServiceNow, choose 'resolved' to enable reopening from the UI. Otherwise, choose 'closed'. False Mirrored ServiceNow Ticket custom close state code Define how to close the mirrored tickets in ServiceNow with custom state. Enter here the custom closure state code (should be an integer) to override the default closure method. If the closure code does not exist, the default one will be used instead. False Mirror Existing Notes For New Fetched Incidents When enabled, comments and work notes are mirrored as note entries for each newly fetched incident. Note: This setting triggers an API call for each incident during the first mirroring, potentially causing overload if numerous incidents are present. False Use system proxy settings False Trust any certificate (not secure) False Incidents Fetch Interval False Advanced: Minutes to look back when fetching Use this parameter to determine how long backward to look in the search for incidents that were created before the last run time and did not match the query when they were created. False Click Test to validate the URLs, token, and connection.
Click Done.
Fetch Incidents#
The integration fetches newly created tickets according to the following parameters, which you define in the instance configuration: ticket_type, query, and limit. For the first fetch, the integration will fetch incidents that were created 10 minutes earlier. After that, the integration will fetch incidents created after the timestamp of the last fetch.
look-back parameter note: In case the look-back parameter is initialized with a certain value and during a time that incidents were fetched, if changing the look back to a number that is greater than the previous value, then in the initial incident fetching there will be incidents duplications. If the integration was already set with look back > 0, and the look-back is not being increased at any point of time, then those incident duplications would not occur. Note that using a look-back value that is very large (more than an hour) can lead to an increase in the memory usage of the system in some cases, and it is highly unrecommended. If there is a need to fetch incidents that require a long look-back to get fetched (for tracking issues, for example), use the mirroring feature and filter the results using the relevant tags instead of using the look-back feature. You can create a custom mapper and track the relevant fields.
Configure Incident Mirroring#
This feature is compliant with XSOAR version 6.0 and above.
When mirroring incidents, you can make changes in ServiceNow that will be reflected in Cortex XSOAR, or vice versa.
You can also attach files from either of the systems which will then be available in the other system.
The following instructions include steps for configuring the integration and incoming and outgoing mappers. However, they do not cover every option available in the integration nor classification and mapping features. For information about classification and mapping see Classification and Mapping (Cortex XSOAR 6.13) or Classification and Mapping (Cortex XSOAR 8 Cloud) or Classification and Mapping (Cortex XSOAR 8.7 On-prem).
Note:
- For Cortex XSOAR version 6.1 only, the final source of truth for an incident are the values in Cortex XSOAR. For example, if you change the severity in Cortex XSOAR and then change it back in ServiceNow, the final value that will be presented is the one in Cortex XSOAR. For versions 6.2 and later, if mirroring is in both directions then the latest update is the source of truth.
- The mirroring settings apply only for incidents that are fetched after applying the settings. Pre-existing comments or work notes are not fetched/mirrored at the time of incident creation.
- To use a custom mapper, you must first duplicate the mapper and edit the field in the copy of the mapper. If you detach the out of the box mapper and make changes to it, the pack does not automatically get updates.
To set up incident mirroring you need to:
- Configure the ServiceNow Service Account roles.
- Configure mirroring for ServiceNow trigger incidents or configure mirroring for other trigger incidents.
Configure the ServiceNow Service Account Roles#
To use ServiceNow on Cortex XSOAR, ensure your service account has the following roles required to make API calls:
- Rest_api_explorer
- Snc_platform_rest_api_access
- itil (optional)
Note: If you choose to give permissions only for specific tables, you then need to add to your user account the specific tables you want to have access to. Make sure you have the correct role so you have permissions to work with the relevant table. Keep in mind that these permissions may not suffice for managing records in some tables.
Read access to sys_journal_field (this is an elevated privilege) for accessing comments and work notes and for incoming mirroring. This is not required if you have
Use Display Valueenabled withInstance Date Formatdefined.Note:
See this ServiceNow community link for giving elevated read access and potential risks.
Configure Incident Mirroring When the Trigger Incident is ServiceNow#
When the trigger incident is ServiceNow, you use the ServiceNow Classifier and leave the Incident type as N/A, with either the default incoming and outgoing mappers or optional custom mappers.
STEP 1 - Configure the ServiceNow v2 Integration Instance for Mirroring#
Navigate to Integrations and search for ServiceNow v2.
Click Add instance.
Select Fetches incidents.
Under Classifier, select ServiceNow Classifier.
Note:
You define either the Classifier or the Incident type (not both). It is recommended to define the Classifier and leave Incident type N/A to enable labeling custom incident types under the ServiceNow Classifier.Under Mapper (incoming), for default mapping select ServiceNow - Incoming Mapper. For custom mapping, follow the instructions in STEP 2 and then select the custom mapper name.
Under Mapper (outgoing), for default mapping select ServiceNow - Outgoing Mapper. For custom mapping, follow the instructions in STEP 3 and then select the custom mapper name.
Enter the connection parameters.
- Confirm whether your organization uses basic authorization or OAuth authorization (most use basic) and enter the relevant authorization details.
- Leave ServiceNow API Version empty since ServiceNow typically automatically provides the appropriate version.
Under The query to use when fetching incidents, the default query is to filter for new incidents: stateNOT IN6,7, where 6= resolved incidents and 7= closed incidents. For a different query, ask your ServiceNow representative to provide the exact states and their numbers.
Select Get incident attachments to retrieve attachments from ServiceNow incident creation in Cortex XSOAR.
Select the Incident Mirroring Direction:
- In - Mirrors changes on the ServiceNow ticket in to the Cortex XSOAR ticket.
- Out - Mirrors changes on the Cortex XSOAR ticket to the ServiceNow ticket.
- Both - Mirrors changes both in and out on both tickets.
Enable the checkbox for Use Display Value if you want to fetch comments and work notes without using sys_journal_field table which required an elevated read only permission.
If Use Display Value is enabled, Instance Date Format needs to be set to the date format that matches the date format used in ServiceNow by the user account used to configure the instance.
- Set the Timestamp field to query as part of the mirroring flow. This defines the ticket_last_update - the epoch timestamp when the ServiceNow incident was last updated. The default is sys_updated_on.
- Enter the relevant Comment Entry Tag, Work Note Entry Tag, File Entry Tag To ServiceNow and File Entry Tag From ServiceNow values.
These values are mapped to the dbotMirrorTags incident field in Cortex XSOAR, which defines how Cortex XSOAR handles comments when you tag them in the War Room.
Note:
These tags work only for mirroring comments, work notes, and files from Cortex XSOAR to ServiceNow.
- Configure any Custom Fields to Mirror. These must start with "u_". This is available for ServiceNow v2 version 2.2.10 and later.
Note:
To enable mirroring custom fields, make a copy of the incoming and outgoing mappers and add the custom fields to the copies (see STEP 2 and STEP 3). Select these copies in the integration instance Mapper (incoming) and Mapper (outgoing) settings. - To enable mirroring when closing an incident or ticket in Cortex XSOAR and ServiceNow, select the closed option from the Mirrored XSOAR Ticket closure method dropdown and Mirrored ServiceNow Ticket closure method respectively.
- Click Done.
STEP 2 (Optional) Configure the Incoming Mapper by Incident Type for Custom Fields#
Note: Any modifications require that the mappers be cloned before any changes can be applied.
Navigate to Classification and Mapping and for Incidents search for the ServiceNow - Incoming Mapper.
Select it and click Duplicate.
Under the Incident Type dropdown, select ServiceNow Create Ticket and Mirror.
Verify the mapper has these fields mapped. They will pull the values configured on the integration instance settings at the time of ingestion.
- dbotMirrorId - dbotMirrorId - the field used by the third-party integration to identify the ticket. This should be the sys_id of the ServiceNow ticket. The value is mapped to incident.servicenowticketid.
- dbotMirrorDirection - determines whether mirroring is incoming, outgoing, or both. Default is Both. This should match the instance configuration.
- dbotMirrorInstance - determines the ServiceNow instance with which to mirror. This should match the instance configuration.
- dbotMirrorLastSync - determines the field by which to indicate the last time that the systems synchronized.
- dbotMirrorTags - determines the tags that you need to add in Cortex XSOAR for entries to be pushed to ServiceNow. They should be copied from the tags in the instance configuration. These are also the tags that must be put on the War Room record in order for it to sync.
- To mirror files, use the ForServiceNow tag.
- To mirror general notes, use the comments tag.
- To mirror private notes that can be read only by users with the necessary permissions, use the work_notes tag.
- Configure any custom fields you want mapped to Cortex XSOAR. Custom fields start with “u_” and are available for ServiceNow v2 version 2.2.10 and later. These must be added to the integration instance Custom Fields to Mirror setting.
STEP 3 - Modify the Outgoing Mapper#
Note:
Any modifications require that the mappers be cloned before any changes can be applied.
- Navigate to Classification and Mapping, and for Incidents search for the ServiceNow - Outgoing Mapper.
- Select it and click Duplicate.
The left side of the screen shows the ServiceNow fields to which to map and the right side of the screen shows the Cortex XSOAR fields by which you are mapping. - Under the Incident Type dropdown, select the relevant incident type (for example ServiceNow Ticket).
- Under Schema Type, select incident. The Schema Type represents the ServiceNow entity that you are mapping to. In our example it is an incident, but it can also be any other kind of ticket that ServiceNow supports.
- On the right side of the screen, under Incident, select the incident based on which you want to match.
- Change the mapping according to your needs, including any fields you want mapped outward to ServiceNow and any custom fields. Make sure the custom fields you want mirrored are added to the integration instance settings.
- Save your changes.
STEP 4 - Create an Incident in ServiceNow#
For purposes of this use case, it can be a simple incident. The new ticket will be ingested in Cortex XSOAR in approximately one minute.
STEP 5 - Add a Note to the Incident in Cortex XSOAR#
In the example below, we have written A comment from Cortex XSOAR to ServiceNow.
- Click Actions > Tags and add the comments tag.
- Add a file to the incident and mark it with the ForServiceNow tag.
- Navigate back to the incident in ServiceNow and within approximately one minute, the changes will be reflected there, too.
You can make additional changes like closing the incident or changing severity and those will be reflected in both systems.
Configure Incident Mirroring When the Trigger Incident is Not ServiceNow#
You can set up any source integration to create a ServiceNow ticket based on a fetched incident and mirror the ticket in Cortex XSOAR. To do this you need to:
- Configure the ServiceNow v2 integration to map the appropriate fields from the ServiceNow Create Ticket and Mirror incident type to the relevant trigger incident type (for example, Phishing Custom).
- Set up the source integration to create a ServiceNow ticket and start mirroring.
STEP 1 - Configure the ServiceNow v2 Integration Instance for Mirroring#
Navigate to Classification and Mapping. For Incidents, search for ServiceNow - Incoming Mapper and ServiceNow - Outgoing Mapper.
For each mapper, click Duplicate.
Your copied mappers will be called ServiceNow - Incoming Mapper_copy and ServiceNow - Outgoing Mapper_copy, you can rename them. The copied mappers appear in the drop down for the Mapper (incoming) and Mapper (outgoing) integration instance settings fields.Navigate to Integrations and search for ServiceNow v2.
Click Add instance.
Select Do not Fetch.
Under Classifier, select ServiceNow Classifier.
Note:
You define either the Classifier or the Incident type (not both). It is recommended to define the Classifier and leave Incident type N/A to enable labeling custom incident types under the ServiceNow Classifier.Under Mapper (incoming), select ServiceNow - Incoming Mapper_copy (or whatever you renamed it).
Under Mapper (outgoing), select ServiceNow - Outgoing Mapper_copy (or whatever you renamed it).
Enter the connection parameters.
- Confirm whether your organization uses basic authorization or OAuth authorization (most use basic) and enter the relevant authorization details.
- Leave ServiceNow API Version empty since ServiceNow typically automatically provides the appropriate version.
Under The query to use when fetching incidents, the default query is to filter for new incidents: stateNOT IN6,7, where 6= resolved incidents and 7= closed incidents. For a different query, ask your ServiceNow representative to provide the exact states and their numbers.
Select Get incident attachments to retrieve attachments from ServiceNow incident creation in Cortex XSOAR.
Select the Incident Mirroring Direction:
- In - Mirrors changes on the ServiceNow ticket in to the Cortex XSOAR ticket.
- Out - Mirrors changes on the Cortex XSOAR ticket to the ServiceNow ticket.
- Both - Mirrors changes both in and out on both tickets.
Enable the checkbox for Use Display Value if you want to fetch comments and work notes without using sys_journal_field table which required an elevated read only permission.
If Use Display Value is enabled, Instance Date Format needs to be set to the date format that matches the date format used in ServiceNow by the user account used to configure the instance.
- Set the Timestamp field to query as part of the mirroring flow. This defines the ticket_last_update - the epoch timestamp when the ServiceNow incident was last updated. The default is sys_updated_on.
- Enter the relevant Comment Entry Tag, Work Note Entry Tag, File Entry Tag To ServiceNow and File Entry Tag From ServiceNow values.
These values are mapped to the dbotMirrorTags incident field in Cortex XSOAR, which defines how Cortex XSOAR handles comments when you tag them in the War Room.
Note:
These tags work only for mirroring comments from Cortex XSOAR to ServiceNow.
- Configure any Custom Fields to Mirror. These must start with "u_". This is available for ServiceNow v2 version 2.2.10 and later.
Note:
To enable mirroring custom fields, make a copy of the incoming and outgoing mappers and add the custom fields to the copies (see STEP 2 and STEP 3). Select these copies in the integration instance Mapper (incoming) and Mapper (outgoing) settings. - To enable mirroring when closing an incident or ticket in Cortex XSOAR and ServiceNow, select the closed option from the Mirrored XSOAR Ticket closure method dropdown and Mirrored ServiceNow Ticket closure method respectively.
- Click Done.
STEP 2 (Optional) Configure the Incoming Mapper by Incident Type for Custom Fields#
Note: Any modifications require that the mappers be cloned before any changes can be applied.
Navigate to Classification and Mapping and for Incidents search for the ServiceNow - Incoming Mapper_copy (or whatever you renamed it).
Under the Incident Type dropdown, select the relevant triggering incident type, for example Phishing.
Verify the mapper has these fields mapped. They will pull the values configured on the integration instance settings at the time of ingestion.
- dbotMirrorId - dbotMirrorId - the field used by the third-party integration to identify the ticket. This should be the sys_id of the ServiceNow ticket. The value is mapped to incident.servicenowticketid.
- dbotMirrorDirection - determines whether mirroring is incoming, outgoing, or both. Default is Both. This should match the instance configuration.
- dbotMirrorInstance - determines the ServiceNow instance with which to mirror. This should match the instance configuration.
- dbotMirrorLastSync - determines the field by which to indicate the last time that the systems synchronized.
- dbotMirrorTags - determines the tags that you need to add in Cortex XSOAR for entries to be pushed to ServiceNow. They should be copied from the tags in the instance configuration. These are also the tags that must be put on the War Room record in order for it to sync.
- To mirror files from XSOAR to ServiceNow, use the ForServiceNow tag.
- Mirrored files from ServiceNow to XSOAR will be tagged by default with the FromServiceNow tag.
- To mirror general notes, use the comments tag.
- To mirror private notes that can be read only by users with the necessary permissions, use the work_notes tag.
- Configure any custom fields you want mapped to Cortex XSOAR. Custom fields start with “u_” and are available for ServiceNow v2 version 2.2.10 and later. These must be added to the integration instance Custom Fields to Mirror setting.
Save your changes.
STEP 3 - Modify the Outgoing Mapper for Custom Fields#
Note:
Any modifications require that the mappers be cloned before any changes can be applied.
- Navigate to Classification and Mapping, and for Incidents search for the ServiceNow - Outgoing Mapper_copy (or whatever you renamed it).
- Under the Incident Type dropdown, select the relevant incident type (for example ServiceNow Ticket).
- Under Schema Type, select incident. The Schema Type represents the ServiceNow entity that you are mapping to. In our example it is an incident, but it can also be any other kind of ticket that ServiceNow supports.
- On the right side of the screen, under Incident, select the incident based on which you want to
match.
The left side of the screen shows the ServiceNow fields to which to map and the right side of the screen shows the Cortex XSOAR fields by which you are mapping. - Change the mapping according to your needs, including any fields you want mapped outward to ServiceNow and any custom fields. Make sure the custom fields you want mirrored are added to the integration instance settings.
- Save your changes.
STEP 4 - Set up Your Source Integration#
Set up your source integration so that after fetching a trigger incident a ServiceNow ticket is created and mirroring starts.
- Fetch an incident with your chosen integration. For example, for Phishing using any email integration (Gmail, MSGraph, O365).
- Classify and map the incident fields.
- Create a task in the playbook that creates a ServiceNow ticket followed by a set incident task that starts the mirroring capability.
Example: The following shows the Create New Record playbook task, which creates a ServiceNow ticket.
The Create New Record task is followed by the Set Mirroring Fields task, which starts the mirroring capability.
The new ServiceNow ticket will be ingested in Cortex XSOAR in approximately one minute.
STEP 5 - Add a Note to the Incident in Cortex XSOAR#
In the example below, we have written A comment from Cortex XSOAR to ServiceNow.
- Click Actions > Tags and add the comments tag.
- Add a file to the incident and mark it with the ForServiceNow tag.
- Navigate back to the incident in ServiceNow and within approximately one minute, the changes will be reflected there, too.
You can make additional changes like closing the incident or changing severity and those will be reflected in both systems.
Commands#
You can execute these commands from the Cortex XSOAR CLI, as part of an automation, or in a playbook. After you successfully execute a command, a DBot message appears in the War Room with the command details.
All commands implement a retry mechanism for 401 (Unauthorized) error codes due to potential ServiceNow authorization issues. This mechanism attempts the request multiple times. If the issue persists, it likely indicates an authorization configuration problem.
servicenow-login#
This function should be used once before running any command when using OAuth authentication.
Base Command#
servicenow-login
Input#
| Argument Name | Description | Required |
|---|---|---|
| username | The username that should be used for login. | Required |
| password | The password that should be used for login. | Required |
Context Output#
There is no context output for this command.
Command Example#
!servicenow-login username=username password=password
Context Example#
Human Readable Output#
Logged in successfully#
servicenow-test#
Test the instance configuration when using OAuth authorization.
Base Command#
servicenow-test
Input#
There are no input arguments for this command.
Context Output#
There is no context output for this command.
Command Example#
!servicenow-test
Context Example#
Human Readable Output#
Instance Configured Successfully#
servicenow-get-ticket#
Retrieves ticket information by ticket ID.
Base Command#
servicenow-get-ticket
Input#
| Argument Name | Description | Required |
|---|---|---|
| id | Ticket system ID for which to retrieve information. | Optional |
| ticket_type | Ticket type. Can be "incident", "problem", "change_request", "sc_request", "sc_task", "sc_req_item", or "sn_si_incident". Default is "incident". | Optional |
| number | Ticket number to retrieve. | Optional |
| get_attachments | If "true" will retrieve ticket attachments.Note this option will always use the v1 API version, as it is not supported in v2. Default is "false". | Optional |
| custom_fields | Custom fields on which to query. For example: state_code=AR,time_zone=PST. | Optional |
| additional_fields | Additional fields to display in the War Room entry and incident context. | Optional |
Context Output#
| Path | Type | Description |
|---|---|---|
| ServiceNow.Ticket.ID | string | ServiceNow ticket ID. |
| ServiceNow.Ticket.OpenedBy | string | ServiceNow ticket opener ID. |
| ServiceNow.Ticket.CreatedOn | date | ServiceNow ticket creation date. |
| ServiceNow.Ticket.Assignee | string | ServiceNow ticket assignee ID. |
| ServiceNow.Ticket.State | string | ServiceNow ticket state. |
| ServiceNow.Ticket.Summary | string | ServiceNow ticket short summary. |
| ServiceNow.Ticket.Number | string | ServiceNow ticket number. |
| ServiceNow.Ticket.Active | boolean | ServiceNow ticket active. |
| ServiceNow.Ticket.AdditionalComments | string | ServiceNow ticket comments. |
| ServiceNow.Ticket.Priority | string | ServiceNow ticket priority. |
| ServiceNow.Ticket.OpenedAt | date | ServiceNow ticket opening time. |
| ServiceNow.Ticket.ResolvedBy | string | ServiceNow ticket resolver ID. |
| ServiceNow.Ticket.CloseCode | string | ServiceNow ticket close code. |
| File.Info | string | Attachment file info. |
| File.Name | string | Attachment file name. |
| File.Size | number | Attachment file size. |
| File.SHA1 | string | Attachment file SHA1 hash. |
| File.SHA256 | string | Attachment file SHA256 hash. |
| File.EntryID | string | Attachment file entry ID. |
| File.Type | string | Attachment file type. |
| File.MD5 | string | Attachment file MD5 hash. |
Command Example#
!servicenow-get-ticket number=INC0000040
Context Example#
Human Readable Output#
ServiceNow ticket#
System ID Number Impact Urgency Severity Priority State Created On Created By Active Description Opened At Short Description id INC0000040 2 - Medium 2 - Medium 3 - Low 3 - Moderate 3 - On Hold 2020-01-26 00:43:54 admin true Seeing JavaScript error message on hiring page on Explorer and Firefox. 2020-01-26 00:42:45 JavaScript error on hiring page of corporate website
servicenow-create-ticket#
Creates new ServiceNow ticket.
Base Command#
servicenow-create-ticket
Input#
| Argument Name | Description | Required |
|---|---|---|
| short_description | Short description of the ticket. | Optional |
| ticket_type | Ticket type. Can be "incident", "problem", "change_request", "sc_request", "sc_task", "sc_req_item", "sn_si_incident" or "std_change_template". Default is "incident". | Optional |
| urgency | Ticket urgency. You can either select from the predefined options or enter another value, for example: "Urgent" or "5". | Optional |
| severity | Ticket severity. You can either select from the predefined options or enter another value, for example: "Urgent" or "5". | Optional |
| impact | Ticket impact. | Optional |
| active | Whether to set the ticket as Active. Can be "true" or "false". | Optional |
| activity_due | The ticket activity due date, in the format "2016-07-02 21:51:11". | Optional |
| additional_assignee_list | List of users assigned to the ticket. | Optional |
| approval_history | Ticket history approval. | Optional |
| approval_set | The ticket approval set date, in the format "2016-07-02 21:51:11". | Optional |
| assigned_to | User assigned to the ticket. | Optional |
| business_duration | Business duration, in the format: YYYY-MM-DD HH:MM:SS. | Optional |
| business_service | Business service. | Optional |
| business_stc | Business source. | Optional |
| business_criticality | Business criticality of the ticket. | Optional |
| calendar_duration | Calendar duration, in the format: YYYY-MM-DD HH:MM:SS. | Optional |
| caller_id | Caller ID (UID format). | Optional |
| category | Category of the ticket. | Optional |
| caused_by | UID Format | Optional |
| close_code | Ticket's close code. Can be "Solved (Work Around)", "Solved (Permanently)", "Solved Remotely (Work Around)", "Solved Remotely (Permanently)", "Not Solved (Not Reproducible)", "Not Solved (Too Costly)", or "Closed/Resolved by Caller". | Optional |
| close_notes | Close notes of the ticket. | Optional |
| closed_at | When the ticket was closed, in the format: YYYY-MM-DD HH:MM:SS. | Optional |
| closed_by | User who closed the ticket. | Optional |
| cmdb_ci | UID Format. | Optional |
| comments | Format type journal input. | Optional |
| comments_and_work_notes | Format type journal input. | Optional |
| company | Company (UID format). | Optional |
| contact_type | Contact type. | Optional |
| correlation_display | Correlation display. | Optional |
| correlation_id | Correlation ID. | Optional |
| delivery_plan | Delivery plan (UID format). | Optional |
| display | Whether to display comments, work notes, and so on. Can be "true" or "false". | Optional |
| description | Ticket description. | Optional |
| due_date | Ticket due date, in the format: YYYY-MM-DD HH:MM:SS. | Optional |
| escalation | Escalation | Optional |
| expected_start | Expected start date/time, in the format: YYYY-MM-DD HH:MM:SS. | Optional |
| follow_up | Follow up date/time, in the format: YYYY-MM-DD HH:MM:SS. | Optional |
| group_list | UID format list (group). | Optional |
| knowledge | Whether the ticket is solved in the knowledge base. Can be "true" or "false". | Optional |
| location | Location of the ticket. | Optional |
| made_sla | SLA of the ticket. | Optional |
| notify | Whether to be notified about this ticket. Can be "1" or "0". | Optional |
| order | Order number. | Optional |
| parent | UID Format | Optional |
| parent_incident | UID Format | Optional |
| problem_id | UID Format | Optional |
| reassignment_count | The number of users included in this ticket. | Optional |
| reopen_count | How many times the ticket has been reopened. | Optional |
| resolved_at | The date/time that the ticket was resolved, in the format: YYYY-MM-DD HH:MM:SS. | Optional |
| resolved_by | ID of the user that resolved the ticket. | Optional |
| risk_score | Incident risk score. | Optional |
| rfc | UID | Optional |
| sla_due | SLA due date/time, in the format: YYYY-MM-DD HH:MM:SS. | Optional |
| subcategory | Ticket subcategory. | Optional |
| sys_updated_by | Last updated by. | Optional |
| sys_updated_on | Last date/time that the system was updated, in the format: YYYY-MM-DD HH:MM:SS. | Optional |
| user_input | Input from the end user. | Optional |
| watch_list | A list of watched tickets. | Optional |
| work_end | Format: YYYY-MM-DD HH:MM:SS | Optional |
| work_notes | Format journal list | Optional |
| work_notes_list | List work notes UIDs. | Optional |
| work_start | Date/time when work started on the ticket. | Optional |
| assignment_group | The sys_id of the group to assign. | Optional |
| incident_state | The number that represents the incident state. | Optional |
| number | Ticket number. | Optional |
| priority | Priority of the ticket. | Optional |
| template | Template name to use as a base to create new tickets. | Optional |
| custom_fields | Custom (user defined) fields in the format: fieldname1=value;fieldname2=value; custom fields start with a "u_". | Optional |
| change_type | Type of Change Request ticket. Can be "normal", "standard", or "emergency". Default is "normal". | Optional |
| state | State of the ticket, for example: "Closed" or "7" or "7 - Closed". | Optional |
| opened_at | Date/time the ticket was opened, in the format: YYYY-MM-DD HH:MM:SS. | Optional |
| caller | Caller system ID. | Optional |
| approval | Ticket approval. | Optional |
| additional_fields | Additional fields in the format: fieldname1=value;fieldname2=value; | Optional |
| input_display_value | Flag that indicates whether to set field values using the display value or the actual value. True will treat the input value as the display value. False treats the input values as actual values. The default setting is false. | Optional |
For more information regarding the input_display_value argument, see: https://docs.servicenow.com/bundle/xanadu-platform-administration/page/administer/exporting-data/concept/query-parameters-display-value.html
Context Output#
| Path | Type | Description |
|---|---|---|
| ServiceNow.Ticket.ID | string | ServiceNow ticket ID. |
| ServiceNow.Ticket.OpenedBy | string | ServiceNow ticket opener ID. |
| ServiceNow.Ticket.CreatedOn | date | ServiceNow ticket creation date. |
| ServiceNow.Ticket.Assignee | string | ServiceNow ticket assignee ID. |
| ServiceNow.Ticket.State | string | ServiceNow ticket state. |
| ServiceNow.Ticket.Summary | string | ServiceNow ticket short summary. |
| ServiceNow.Ticket.Number | string | ServiceNow ticket number. |
| ServiceNow.Ticket.Active | boolean | ServiceNow ticket active. |
| ServiceNow.Ticket.AdditionalComments | string | ServiceNow ticket comments. |
| ServiceNow.Ticket.Priority | string | ServiceNow ticket priority. |
| ServiceNow.Ticket.OpenedAt | date | ServiceNow ticket opening time. |
| ServiceNow.Ticket.ResolvedBy | string | ServiceNow ticket resolver ID. |
| ServiceNow.Ticket.CloseCode | string | ServiceNow ticket close code. |
Command Example#
!servicenow-create-ticket active=true severity="2 - Medium" short_description="Ticket example"
Context Example#
Human Readable Output#
ServiceNow ticket was created successfully#
System ID Number Impact Urgency Severity Priority State Created On Created By Active Opened At Short Description id INC0010002 3 - Low 3 - Low 2 - Medium 5 - Planning 1 - New 2020-05-10 09:04:06 admin true 2020-05-10 09:04:06 Ticket example
servicenow-update-ticket#
Updates the specified ticket.
Base Command#
servicenow-update-ticket
Input#
| Argument Name | Description | Required |
|---|---|---|
| short_description | Short description of the ticket. | Optional |
| ticket_type | Ticket type. Can be "incident", "problem", "change_request", "sc_request", "sc_task", "sc_req_item", or "sn_si_incident". Default is "incident". | Optional |
| urgency | Ticket urgency. You can either select from the predefined options or enter another value, for example: "Urgent" or "5". | Optional |
| severity | Ticket severity. You can either select from the predefined options or enter another value, for example: "Urgent" or "5". | Optional |
| impact | Ticket impact. | Optional |
| active | Whether the ticket is Active. Can be "true" or "false". | Optional |
| activity_due | The ticket activity due date, in the format: "2016-07-02 21:51:11". | Optional |
| additional_assignee_list | List of users assigned to the ticket. | Optional |
| approval_history | Ticket history approval. | Optional |
| approval_set | The ticket approval set date/time, in the format: "2016-07-02 21:51:11". | Optional |
| assigned_to | User assigned to the ticket. | Optional |
| business_duration | Business duration, in the format: YYYY-MM-DD HH:MM:SS. | Optional |
| business_service | Business service. | Optional |
| business_stc | Business source. | Optional |
| business_criticality | Business criticality of the ticket. | Optional |
| calendar_duration | Calendar duration, in the format: YYYY-MM-DD HH:MM:SS. | Optional |
| caller_id | Caller ID (UID format). | Optional |
| category | Category name. | Optional |
| caused_by | UID format. | Optional |
| close_code | Ticket's close code. Ticket's close code. Can be "Solved (Work Around)", "Solved (Permanently)", "Solved Remotely (Work Around)", "Solved Remotely (Permanently)", "Not Solved (Not Reproducible)", "Not Solved (Too Costly)", or "Closed/Resolved by Caller". | Optional |
| close_notes | Close notes of the ticket. | Optional |
| closed_at | Date/time the ticket was closed, in the format: YYYY-MM-DD HH:MM:SS. | Optional |
| closed_by | User who closed the ticket. | Optional |
| cmdb_ci | UID Format. | Optional |
| comments | Format type journal input. | Optional |
| comments_and_work_notes | Format type journal input. | Optional |
| company | UID Format. | Optional |
| contact_type | Contact type. | Optional |
| correlation_display | Correlation display. | Optional |
| correlation_id | Correlation ID. | Optional |
| delivery_plan | UID Format. | Optional |
| display | Whether to display comments, work notes, and so on. Can be "true" or "false". | Optional |
| description | Ticket description. | Optional |
| due_date | Ticket due date, in the format: YYYY-MM-DD HH:MM:SS. | Optional |
| escalation | Escalation. | Optional |
| expected_start | Expected start date/time, in the format: YYYY-MM-DD HH:MM:SS. | Optional |
| follow_up | Follow up date/time, in the format: YYYY-MM-DD HH:MM:SS. | Optional |
| group_list | UID format list. | Optional |
| knowledge | Whether the ticket is solved in the knowledge base. Can be "true" or "false". | Optional |
| location | Location of the ticket. | Optional |
| made_sla | SLA of the ticket. | Optional |
| notify | Whether to be notified about this ticket. Can be "1" or "0". | Optional |
| order | Order number. | Optional |
| parent | Parent (UID format). | Optional |
| parent_incident | Parent incident (UID format). | Optional |
| problem_id | Problem ID (UID format). | Optional |
| reassignment_count | The number of users included in this ticket. | Optional |
| reopen_count | The number of times the ticket has been reopened. | Optional |
| resolved_at | Date/time the ticket was resolved, in the format: YYYY-MM-DD HH:MM:SS. | Optional |
| resolved_by | Resolved by (UID format). | Optional |
| risk_score | Incident risk score. | Optional |
| rfc | UID | Optional |
| sla_due | SLA due date/time, in the format: YYYY-MM-DD HH:MM:SS. | Optional |
| subcategory | Ticket subcategory. | Optional |
| sys_updated_by | Last updated by | Optional |
| sys_updated_on | Date/time the system was last updated. | Optional |
| user_input | Input from the end user. | Optional |
| watch_list | A list of watched tickets. | Optional |
| work_end | Format: YYYY-MM-DD HH:MM:SS | Optional |
| work_notes | Format journal list. | Optional |
| work_notes_list | Comma-separated list of work notes UIDs. | Optional |
| work_start | Date/time when work started on the ticket. | Optional |
| assignment_group | Assignment group UID. | Optional |
| incident_state | Number representing the incident state. | Optional |
| number | Ticket number. | Optional |
| priority | Priority of the ticket. | Optional |
| id | System ID of the ticket to update. | Required |
| custom_fields | Custom (user defined) fields in the format: fieldname1=value;fieldname2=value; custom fields start with a "u_". | Optional |
| change_type | Type of Change Request ticket. Can be "normal", "standard", or "emergency". Default is "normal". | Optional |
| state | State of the ticket, for example: "Closed" or "7" or "7 - Closed". | Optional |
| caller | Caller system ID. | Optional |
| approval | Ticket approval. | Optional |
| additional_fields | Additional fields in the format: fieldname1=value;fieldname2=value; | Optional |
| input_display_value | Flag that indicates whether to set field values using the display value or the actual value. True will treat the input value as the display value. False treats the input values as actual values. The default setting is false. | Optional |
| clear_fields | A comma-separated list of fields to clear. | Optional |
For more information regarding the input_display_value argument, see: https://docs.servicenow.com/bundle/xanadu-platform-administration/page/administer/exporting-data/concept/query-parameters-display-value.html
Context Output#
There is no context output for this command.
Command Example#
!servicenow-update-ticket id=id severity="2 - Medium"
Context Example#
Human Readable Output#
ServiceNow ticket updated successfully#
Ticket type: incident
Active Created By Created On Description Impact Number Opened At Priority Severity Short Description State System ID Urgency true admin 2020-01-26 00:43:54 Seeing JavaScript error message on hiring page on Explorer and Firefox. 2 - Medium INC0000040 2020-01-26 00:42:45 3 - Moderate 2 - Medium JavaScript error on hiring page of corporate website 3 - On Hold 471d4732a9fe198100affbf655e59172 2 - Medium
servicenow-delete-ticket#
Deletes a ticket from ServiceNow.
Base Command#
servicenow-delete-ticket
Input#
| Argument Name | Description | Required |
|---|---|---|
| id | Ticket System ID | Required |
| ticket_type | Ticket type. Can be "incident", "problem", "change_request", "sc_request", "sc_task", "sc_req_item", or "sn_si_incident". | Optional |
Context Output#
There is no context output for this command.
Command Example#
!servicenow-delete-ticket id=id
Context Example#
Human Readable Output#
Ticket with ID id was successfully deleted.
servicenow-query-tickets#
Retrieves ticket information according to the supplied query.
Base Command#
servicenow-query-tickets
Input#
| Argument Name | Description | Required |
|---|---|---|
| limit | The maximum number of tickets to retrieve. | Optional |
| ticket_type | Ticket type. Can be "incident", "problem", "change_request", "sc_request", "sc_task", "sc_req_item", or "sn_si_incident". Default is "incident". | Optional |
| query | The query to run. To learn about querying in ServiceNow, see https://docs.servicenow.com/bundle/istanbul-servicenow-platform/page/use/common-ui-elements/reference/r_OpAvailableFiltersQueries.html | Optional |
| offset | Starting record index to begin retrieving records from. | Optional |
| additional_fields | Additional fields to present in the War Room entry and incident context. | Optional |
| system_params | System parameters in the format: fieldname1=value;fieldname2=value. For example: "sysparm_display_value=al;&sysparm_exclude_reference_link=True" | Optional |
| system_params | System parameters in the format: fieldname1=value;fieldname2=value. For example: "sysparm_display_value=true;sysparm_exclude_reference_link=True" | Optional |
Context Output#
| Path | Type | Description |
|---|---|---|
| Ticket.ID | string | The unique ticket identifier. |
| Ticket.Creator | string | A string field that indicates the user who created the ticket. |
| Ticket.CreatedOn | date | The date/time when the ticket was created. |
| Ticket.Assignee | string | Specifies the user assigned to complete the ticket. By default, this field uses a reference qualifier to only display users with the itil role. |
| Ticket.State | string | Status of the ticket. |
| Ticket.Summary | string | A human-readable title for the record. |
| Ticket.Number | string | The display value of the ticket. |
| Ticket.Active | boolean | Specifies whether work is still being done on a task or whether the work for the task is complete. |
| Ticket.AdditionalComments | Unknown | Comments about the task record. |
| Ticket.Priority | string | Specifies the ticket priority for the assignee. |
| Ticket.OpenedAt | date | The date/time when the ticket was first opened. |
| Ticket.Escalation | string | Indicates how long the ticket has been open. |
Command Example#
!servicenow-query-tickets limit="3" query="impact<2^short_descriptionISNOTEMPTY" ticket_type="incident"
Context Example#
Human Readable Output#
ServiceNow tickets#
System ID Number Impact Urgency Severity Priority State Created On Created By Active Close Notes Close Code Description Opened At Resolved By Resolved At Short Description id INC0000001 1 - High 1 - High 1 - High 1 - Critical 7 - Closed 2018-08-24 18:24:13 pat false Closed before close notes were made mandatory Closed/Resolved by Caller User can't access email on mail.company.com. 2020-01-23 23:09:51 admin 2020-04-24 19:56:12 Can't read email id INC0000002 1 - High 1 - High 1 - High 1 - Critical 3 - On Hold 2018-08-13 22:30:06 pat true User can't get to any of his files on the file server. 2020-01-17 23:07:12 Network file shares access issue id INC0000003 1 - High 1 - High 1 - High 1 - Critical 2 - In Progress 2018-08-28 14:41:46 admin true I just moved from floor 2 to floor 3 and my laptop cannot connect to any wireless network. 2020-01-24 23:07:30 Wireless access is down in my area
servicenow-add-link#
Adds a link to the specified ticket.
Base Command#
servicenow-add-link
Input#
| Argument Name | Description | Required |
|---|---|---|
| id | Ticket System ID. | Required |
| ticket_type | Ticket type. Can be "incident", "problem", "change_request", "sc_request", "sc_task", "sc_req_item", or "sn_si_incident". Default is "incident". | Optional |
| link | The actual link to publish in ServiceNow ticket, in a valid URL format, for example, http://www.demisto.com. | Required |
| post-as-comment | Whether to publish the link as comment on the ticket. Can be "true" or "false". If false will publish the link as WorkNote. | Optional |
| text | The text to represent the link. | Optional |
Context Output#
There is no context output for this command.
Command Example#
!servicenow-add-link id=id link="http://www.demisto.com" text=demsito_link
Context Example#
Human Readable Output#
Link successfully added to ServiceNow ticket#
System ID Number Impact Urgency Severity Priority State Created On Created By Active Description Opened At Short Description id INC0000040 2 - Medium 2 - Medium 2 - Medium 3 - Moderate 3 - On Hold 2020-01-26 00:43:54 admin true Seeing JavaScript error message on hiring page on Explorer and Firefox. 2020-01-26 00:42:45 JavaScript error on hiring page of corporate website
servicenow-add-comment#
Adds a comment to the specified ticket, by ticket ID.
Base Command#
servicenow-add-comment
Input#
| Argument Name | Description | Required |
|---|---|---|
| id | Ticket System ID. | Required |
| ticket_type | Ticket type. Can be "incident", "problem", "change_request", "sc_request", "sc_task", "sc_req_item", or "sn_si_incident". Default is "incident". | Optional |
| comment | Comment to add. | Required |
| post-as-comment | Whether to publish the note as comment on the ticket. Can be "true" or "false". Default is "false". | Optional |
Context Output#
There is no context output for this command.
Command Example#
!servicenow-add-comment id=id comment="Nice work!"
Context Example#
Human Readable Output#
Comment successfully added to ServiceNow ticket#
System ID Number Impact Urgency Severity Priority State Created On Created By Active Description Opened At Short Description id INC0000040 2 - Medium 2 - Medium 2 - Medium 3 - Moderate 3 - On Hold 2020-01-26 00:43:54 admin true Seeing JavaScript error message on hiring page on Explorer and Firefox. 2020-01-26 00:42:45 JavaScript error on hiring page of corporate website
servicenow-upload-file#
Uploads a file to the specified ticket.
Base Command#
servicenow-upload-file
Input#
| Argument Name | Description | Required |
|---|---|---|
| id | Ticket System ID. | Required |
| ticket_type | Ticket type. Can be "incident", "problem", "change_request", "sc_request", "sc_task", "sc_req_item", or "sn_si_incident". Default is "incident". | Optional |
| file_id | War Room entry ID that includes the file. | Required |
| file_name | Filename of the uploaded file to override the existing file name in the entry. | Optional |
Context Output#
| Path | Type | Description |
|---|---|---|
| ServiceNow.Ticket.File.Filename | string | Name of the file. |
| ServiceNow.Ticket.File.Link | string | Download link for the file. |
| ServiceNow.Ticket.File.SystemID | string | System ID of the file. |