Managing ServiceNow Tickets with IdentityNow Workflows
This workflow will help you create and manage ServiceNow tickets to address the requirements related to onboarding and off boarding users in IdentityNow (IDN). It can interact with not only ServiceNow but any other ticketing tool, as long as it supports working with REST APIs.
This workflow is not a replacement but an alternative to using the standard IDN ServiceNow Service Desk Integration for handling provisioning actions for disconnected systems. Here is a quick comparison of the capabilities of both:
| Workflow | ServiceNow Service Desk Integration |
|---|---|
| Has the ability to filter out identities based on specific criteria | Cannot filter identities within sources that are integrated with Service Now |
| Offers more flexibility to create any object like an Incident/Task/Request/Request Items as desired | Currently, the ServiceNow Service Desk integration supports only the Service Request ticket type |
| Can be configured to retry ticket creation in case of failure or can notify manager to create ticket in ServiceNow manually | Built-in retry mechanism for creation and check ticket status failure. |
| Ticket number available at your finger tips | Ticket number can be found only in Account Activity of the user using Search |
| Easy tracking/monitoring of ticket status | Ticket status is monitored internally at regular intervals per configuration |
| Can be configured to send email notifications/escalations/reminders as needed | No email notification options available |
Using workflows is definitely advantageous, so I’ll show you how to build one!
This workflow is very simple and straightforward to implement. I’ll demonstrated creating an incident and a request in the following flows. Make sure you read through the most common errors you may get while configuring this workflow and steps to resolve those in the Troubleshooting section. This may save you some time and effort when you’re working on it.
User on-boarding workflow design
This workflow will perform the following steps.
- Trigger: Identity Created
- Create a Service Now Ticket
- Send Notification to Manager with Ticket Number
- Check Ticket Completion Status
- On completion Notify Manager
- If ticket reaches Due Date without completion, notify Manager to follow up with Team offline.
Note: The workflow can be built using Manage ServiceNow Ticket action or HTTP Request action. The advantage of using ServiceNow action is that it handles the generation and usage of access token by itself - if you use HTTP, you will need to make an additional HTTP call to get the token before your request.
Manage ServiceNow Ticket:
Step 1 – Trigger
For the on boarding use case, use the ‘Identity Created’ trigger to get the workflow started.
Step 2 – Get Identity (Manager)
Use this step to fetch the manager of the created identity to be able to email/notify him or her about the ticket creation and its progress.
Step 3a – Define Variable (Due Date = 7 days + Today)
$.now() will provide today’s date. This example will provide the user a week to complete the manual provisioning tasks.
Step 3b – Define Variable (Due Date Substring)
The $.now() variable returns the date in ISO8601 format. This example sends the date part to ServiceNow in the MM/dd/yyyy format and drops the time string.
Step 4 – Manage ServiceNow Ticket
The action gives you the flexibility to create Incident/Task/REQs. Based on your requirement, pick the correct endpoint URL from the following list or get one from your Service Now team:
Incident: https://tenant.service-now.com/api/now/table/incident
Request: https://tenant.service-now.com/api/now/table/sc_request
Task: https://tenant.service-now.com/api/now/table/sc_task
You can use the Basic or OAuth method, depending on your client. This example uses Basic Auth.
In the ‘Additional Fields’ textbox, add attributes you want to be included in ticket like category, subcategory, short_description, assignment_group, requested_for, opened_by, urgency, etc.
Step 5 – Wait
Wait for 2 - 5 minutes for the ServiceNow API to complete processing the ticket creation. You can skip this step, but I’ve included it because it’s important for both the systems to be in sync.
Step 6 – Compare numbers
Check whether the ‘Ticket Creation’ action completed successfully. Response 201 = Created Success
$.manageServieNowTicket.statusCode = 201
Step 7 – Send email
Send an email to the user’s manager, notifying him or her about the ticket number that was created for provisioning the new user.
Email Body
Hi,<br/><br/>ServiceNow ticket for user ${displayName} has been created successfully. <br/><br/>The ticket number is ${ticketNumber}.<br/><br/>Thanks,<br/>Your IAM Team
Templating context
{"displayName.$":"$.trigger.identity.name","ticketNumber.$":"$.manageServiceNowTicket.body.result.task_effective_number"}
Step 8 – Wait
Wait for 7 days or until your ticket’s due date. You can edit this step in the interim and configure some ‘Send Email’ actions to send reminders/escalations before the ticket due date.
Step 9 – Manage ServiceNow Ticket1 - get ticket status
Now you can get the Ticket status from ServiceNow.
Request URL
https://tenant.service-now.com/api/now/v1/table/sc_request?sysparm_query=
Ticket ID
{{$.manageServiceNowTicket.body.result.task_effective_number}}
Step 10 – Compare strings
Check whether the ‘Request Status’ is “Closed Complete”.
Step 11- Send email
Send an email to the user’s manager, notifying him or her that the ticket is “Closed Complete”. This will assure the manager that provisioning is complete and no further action is required.
Step 12 – End step - success
In addition to these standard steps, I’ve included more ‘Send Email’ actions to notify managers about Ticket creation failures, status etc.
The completed workflow should look like this:
HTTP Request:
If the ‘Manage’ ServiceNow action doesn’t work out for you as expected or you need more flexibility, you can use the ‘HTTP Request’ action to configure the same workflow. You will first need to make an API call to get an access token that can be used by the next request to create tickets.
For example, remove ‘Manage ServiceNow Ticket’ actions from the earlier workflow and replace them with two HTTP Request actions configured like this:
HTTP Request – Get access token
This action will get an access token that can be used in following POST calls to create tickets.
Request URL: POST https://tenant.service-now.com/oauth_token.do
Request Content Type: Form
Request Body:
grant_type: password
client_id: xxx
client_secret: xxx
username: xxx
password: xxx
HTTP Request 1 – Create an incident
This action will use the access token from the previous request and create an incident in ServiceNow.
Request URL: POST https://dev111815.service-now.com/api/now/v1/table/incident
Request Headers:
Authorization Bearer {{$.hTTPRequest.body.access_token}}
Request Content Type: JSON
Request Body:
You can add all the attributes you want to be included in the ticket in the request body:
{"caller_id":"admin","comments":"This incident was created from Sailpoint IDN Custom Workflow for user {{$.trigger.identity.name}}. Please provision this user to XYZ systems. Thank you.","description":"Please Create Accounts for the new user provisioned in XYZ system","due_date":"{{$.defineVariable.dueDate}}","short_description":"New User {{$.trigger.identity.name}} created in Sailpoint IDN","urgency":"3"}
To track ticket status, you can use one HTTP request to get token and a second one in the form of a GET call to fetch the status. The GET call should be configured like this:
The completed workflow should look like this:number: {{$.hTTPRequest1.body.result.task_effective_number}}
Testing the workflow
You can test this workflow with the built-in ‘Test Workflow’ functionality.
Here’s a sample of test payload input with some dummy data you can use for testing. For more realistic testing you can replace the Identity and manager details below with actual values in your tenant.
{
"attributes": {
"created": "2020-04-27T16:48:33.597Z",
"customAttribute1": "customValue",
"customAttribute2": "customValue2",
"department": "Sales",
"displayName": "John Doe",
"email": "john.doe@gmail.com",
"employeeNumber": "E001",
"firstname": "John",
"identificationNumber": "E001",
"inactive": "true",
"isManager": false,
"lastname": "Doe",
"manager": {
"id": "b8992ce4f28746898b32001851523e28",
"name": "Ashley Parker",
"type": "IDENTITY"
},
"phone": null,
"uid": "E001"
},
"identity": {
"id": "ee769173319b41d19ccec6cea52f237b",
"name": "John Doe",
"type": "IDENTITY"
}
}
Troubleshooting
Error parsing response body
“error parsing the response body: invalid character ‘<’ looking for beginning of value”
This error is related to the ‘Manage ServiceNow Ticket’ or ‘HTTP Request’ action. I am sure this is one of the most common errors. You get this error when there’s an issue with ‘Manage ServiceNow’ step, and because the response is in HTML, IDN can’t parse the ‘<’. This step expects a JSON response. To find the full HTML response you may turn on logging and check the CCG logs.
Here are some of the possible reasons you may see this error:
- ServiceNow tenant is down or not reachable.
- ServiceNow tenant is blocking certain IP addresses.
- You can’t authenticate successfully to ServiceNow to create the ticket.
- ServiceNow endpoint URL is incorrect.
Resolution
For the first three reasons you will have to work closely with your ServiceNow team and verify that connectivity, credentials and authorization is set up accurately.
If all of that seems correct, make sure you have provided the correct ‘ServiceNow Request URL’. This is the most common pitfall because the ServiceNow instance URL is usually provided in the ‘Request URL’ text box, but this should be the full URL of ServiceNow tenant, along with the endpoint of the object you plan to create.
For example:
Incident: https://tenant.service-now.com/api/now/table/incident
Request: https://tenant.service-now.com/api/now/table/sc_request
Task: https://tenant.service-now.com/api/now/table/sc_task
You can set up either one of these URLs based on whether you plan to create a ticket, request, task, or incident.
Request failed: 404
request failed: 404 - {“error”:{“message”:“No Record found”,“detail”:“Record doesn’t exist or ACL restricts the record retrieval”},“status”:“failure”}
This error is related to the ‘Manage ServiceNow Ticket: Get ticket status’ action. You must work with your ServiceNow team to manage ACLs for the service account used to create and manage tickets.
Note: You can read a request if you opened it, or if you are the record’s ‘requested for’ user.
If the ACL is all set, make sure you’ve provided the correct Request URL:
Ex. https://tenant.service-now.com/api/now/table/sc_request?sysparam_query
Failed to add CustomFields
failed to add CustomFields to HTTP Request, key value pair not provided
This error is related to the ‘Additional Fields’ in the ‘Manage ServiceNow Ticket’ action. This step expects data i key:value pairs to be separated by line breaks - make sure you enter it in that exact format. There is no requirement to enclose text/string in quotes and commas aren’t necessary. Just enter plain text like this:
comments:New Ticket for provisioning user Hardware
due_date:{{$.defineVariable.dueDate}}
assignment_group:Hardware
Feature flag for dynamic schema is not enabled
error: feature flag for dynamic schema is not enabled
This error is related to the ‘Define Variable’ action. Submit a SailPoint support ticket to check whether that feature flag is enabled in your tenant.
Miscellaneous errors
Misc errors - when using multiple operators on same Variable A
This operator is still in Beta and looks like it doesn’t completely support multiple operators yet. As a workaround, use multiple ‘Define Variable’ steps to perform your operations in the sequence you want.
JSON file
See the attached JSON files for both workflows. One uses the ‘Manage Service Now Ticket’ Action to create a request, and the other uses the ‘HTTP Request’ to create an incident in ServiceNow.
Manage Service Now Ticket with Workflows.json (7.6 KB)
Manage Service Now Ticket with HTTP Request in Workflows.json (6.9 KB)
Conclusion
This workflow will give you a head start to handle ticket creation and monitor ticket status from IDN. For the offboarding use case, you can use a similar workflow and just change the trigger to ‘Identity Deleted’ or ‘Identity Attributed Changed’ (filter on the ‘inactive’ lifecycle state). You can add email actions for reminder/escalations before reaching the ticket’s due date. Feel free to tailor this workflow to fit your requirements.
