Managing Service Now Tickets in Workflows

[sharvari (Sharvari Bharatiya)]

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:

number: {{$.hTTPRequest1.body.result.task_effective_number}}

The completed workflow should look like this:

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": "[email protected]",
    "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.

[ccarlton (Chad Carlton)]

Really Great Post! I have used theJSON file “Manage Service Now Ticket with Workflows” and have only changed the SN authentication method from basic to OAUTH. (I used the same values in this workflow that were used in our SDIM connector).

I am getting the following error when trying to test the workflow: ( a popup appears on the IDN test workflow page and says)

"An Error occurred. Please contact your administrator.

Trace ID: wefiwnfoweivnweoignog24

has a primitive type that is NOT VALID – given: // Expected valid values are:[array boolean integer number null object string]
"

I am unsure what this error means?

[sharvari (Sharvari Bharatiya)]

Thanks a lot, Chad.

This error indicates one of your variables/data you are passing to the workflow step is not acceptable and needs to be of a different data type. If you could share your JSON payload, I might be able to assist you further.

[dopstrick (Dylan Strickland)]

You mentioned this workflow step is an alternative to using the standard IDN ServiceNow Service Desk Integration.

Does this workflow step require the ServiceNow Service Desk Integration to be configured in IDN and ServiceNow, or can this generate tickets without downloading the App from the ServiceNow store?

[sharvari (Sharvari Bharatiya)]

This workflow doesn’t require the app to be installed.

[manisha_temkar]

Nice blog, Have you tried using SailPoint’s Generic SDIM Service Desk Integration module? It’s very easy platform to integrate with any ITSM solution for any ticket type.

[sharvari (Sharvari Bharatiya)]

Thanks a lot for viewing my blog, Manisha.

To answer your question, yes, I have used the built in SDIM integration and it’s comparatively easier to setup and use as we don’t have to worry about a lot of things that the integration will take care of automatically like authentication/error retry mechanism etc… The only part I don’t like about it is the way to we have to use a dummy source and dummy entitlement to trigger the provision/de-provisioning action to get the ticket created.

This workflow is just a demo of how we can manage tickets with a little more flexibility using some of the features of IDN workflows.

[manisha_temkar]

To understand more, in this case if you want to create ticket - what’s the purpose? As you mentioned dummy source/dummy entitlement to create it.

While requesting access, we are creating ticket so entitlement details and source details are required. Could you please share the use case where you want to create ticket without source and entitlement?

[sharvari (Sharvari Bharatiya)]

It’s a genuine case for user on boarding/termination where in we wanted to create a ticket when an Identity LCS is active/inactive. This ticket isn’t tied to a specific real disconnected source/entitlement, it’s just a general ticket to IT team.

[pkgupta1 (Pradeep Gupta)]

Very useful documentation

[kkilafwasru (Kamsky Kilafwasru)]

Hey Sharvari, great post! I am implementing a similar workflow, but I’m running into errors on the Auth step. I’ve configured the Auth call using the same configuration you have attached below; however, I am receiving a “failed to add form body to HTTP Request, key value pair not provided” when I run a test within the workflow module. I’ve setup/ran this call in Postman and can received the Auth token without an issues. Any ideas on why the flow fails to find the key value pairs?

[atarodia (Animesh Tarodia)]

Hi @kkilafwasru, you can refer this post here:

Manage Service Now Ticket Additional Fields

Hi @sharvari_shah, I was able to make the request using dynamic variable. Looks like the request does not like the format “2023-07-07T14:37:01.675Z”. I added another Define Variable to get the substring(0,10) which results in “2023-07-07”. Wflow:- [image] Define Variable:- [image] SNOW Request:- [image] Result:- [image]

[kkilafwasru (Kamsky Kilafwasru)]

Hey Animesh! I’m actually using the HTTP action (1 for auth, 1 to create the ticket) for this workflow. I’m attempting to pass those key value pairs like this (sensitive content removed)

[sharvari (Sharvari Bharatiya)]

Hi Kamsky,
When you are testing the workflow, are you able to see the values getting populated accurately in the full JSON being generated at runtime? Do you have any special characters in there that could interfere with the JSON format for this HTTP call?

[spatil19 (Shail Patil)]

@sharvari Amazing post! However, I wanted to clarify something, in the comparison of workflow vs SNOW Service Desk Integration you mention the below point

@sharvari

Can be configured to retry ticket creation in case of failure or can notify manager to create ticket in ServiceNow manually vs Built-in retry mechanism for creation and check ticket status failure.

I have not found this to be my experience nor have I seen any documentation. For example:- I broke the service desk connection and tried an access request which obviously failed and it did not retry (not that I can see). Is that behavior unexpected?

[sharvari (Sharvari Bharatiya)]

Thanks @spatil19 !

I haven’t tried that particular scenario but when it’s setup for provisioning a disconnected system via criteria role, it tries to recreate ticket if the previous try wasn’t successful.

As per documentation the Integration does support -

• Retry Mechanism for check ticket status failure.

[spatil19 (Shail Patil)]

@sharvari thanks for your response.

1. For role based provisioning to a disconnected system I believe it retries because the identity gets refreshed and sees that the entitlement is not assigned yet thus re-triggering the provisioning. Which is different than access request, as there is nothing to re-trigger it.
2. “Retry Mechanism for check ticket status failure” - I believe this is more for retry on failing to check the status of an already created ticket rather than a 2nd attempt to create a ticket when the 1st attempt failed.

[sharvari (Sharvari Bharatiya)]

Agree on both your points!

[MVKR7T (Krishna Reddy Mummadi)]

Thanks @sharvari for the blog and appreciate your efforts.

I am facing below error. Any idea ?

{
    "type": "ActivityTaskCompleted",
    "timestamp": "2023-11-01T10:40:11.954128054Z",
    "attributes": {
      "displayName": "Manage ServiceNow Ticket",
      "result": {
        "body": {
          "error": {
            "detail": "TypeError: Cannot read property \"variables\" from undefined (sys_ws_operation.f1f3898edbffb300e90690b3db961966.operation_script; line 21)",
            "message": "Cannot read property \"variables\" from undefined"
          },
          "status": "failure"
        },
        "headers": null,
        "responseTime": "0.111634 seconds",
        "statusCode": 500
      },
      "stepName": "manageServiceNowTicket",
      "task": "sp:snow"
    }
  }

[sharvari (Sharvari Bharatiya)]

Thank you Krishna!

@MVKR7T

Cannot read property \"variables\"

From the error, it looks like you need to check the variables that you are passing to this step maybe some need an escape character. Please compare the JSON attached here to your json for Manage Service Now ticket step, that may help to identify the issue.