ServiceNow has become an industry leading ITSM technology seen in a large number of IDMWORKS clients. Integration with an ITSM system to both managed accounts and leverage the ticketing functions has become a standard part of most IGA deployments. ServiceNow Service Desk integration enables organizations to create service requests, incidents, and change requests in ServiceNow using REST APIs. However, this article will only focus on service request creation.
Prerequisites
For this integration, the following two applications need to be installed in ServiceNow from ServiceNow store:
- SailPoint for Service Desk
- SailPoint Identity Governance Connector
For more details about how to install and configure these apps, please refer to these links:
Documentation – Integrating SailPoint with ServiceNow Service Desk > Prerequisites
Documentation – Requesting the ServiceNow Application From the ServiceNow Store
Besides installing these applications and setting up the required access, a catalog item needs to be created in ServiceNow for every application that we will be using for this integration in IdentityIQ. Often, the same catalog item is used for multiple applications but it varies from organization to organization.
Configuration Steps
1) Create an application of type ServiceNow and run account and group aggregation. For this purpose, only account aggregation is needed as ServiceNow Service Desk integration will be using the sysid of the aggregated accounts for a different purpose e.g., requester and requestee. If desired, account schema attributes that are not necessary can be removed and group aggregation is also not required.
2) Open IdentityIQforServiceNowServiceDesk.xml in a text editor of your choice. This file can be found under WEB-INF\config\connector directory of IdentityIQ installation.
3) Rename the name attribute in xml to create the application with a different name.
4) Set connectorAppForServiceNow entry as the name of the application of type ServiceNow created in step 1.
5) Set ticketType entry to serviceRequest if not set already. This entry defines if the application is supposed to handle Service Requests (serviceRequest), Incidents (incident) or Change Requests (changeRequest).
6) Depending on the authentication type used, modify the following parameters:
- authenticationType – It can be Basic for Basic Authentication and OAuth2 for OAuth2 Authentication.
- client_id
- client_secret
- grant_type – It can be REFRESH_TOKEN for refresh token grant type and PASSWORD for password grant type.
- refresh_token
- token_url
- url
- username
- password
7) This application xml is divided into three parts:
- Change Request – <entry key=”changeRequest”>
- Incident – <entry key=”incident”>
- Service Request – <entry key=”serviceRequest>
Every type of request has two sections:
Configuration to check request status
- Check Status – <entry key=”checkStatus”>
Configuration to create the request in ServiceNow
- Provision – <entry key=”provision”>
8) Configure checkStatus
- resource – keep it to the default value
- responseElement – keep it to the default value
- checkStatusQueryParam – keep it to the default value
- statusMap – Modify this mapping based on the responses configured in ServiceNow. Usually, the default ones work fine.
9) Configure provision
- resource – keep it to the default value
- catalogItem – Configure this with a map where key is the application name in IdentityIQ that is supposed to be using this integration and value will be the catalog item sys id in ServiceNow for this application. It is possible that multiple applications are going to be using same catalogItem. In that case, all the entries will have same catalog item sys id as value
- responseElement – keep it to the default value
- requestObject – keep it to the default value
- request – This is the map of the attributes that need to be passed to ServiceNow to be able to create the ticket. Modify it based on the ServiceNow catalog item requirement.
10) Configure the applications that are supposed to be using this integration as ManagedResource under ProvisioningConfig. The application names should match with the application names under provision -> catalogItem.
How it Works
When an account request is created for an application configured as ManagedResource, IdentityIQ redirects the provisioning to Service Desk integration. IdentityIQ uses the provision entry to create ServiceNow ticket. Once the ticket is created, IdentityIQ parses the response, finds the ticket number based on responseElement and stores it in IdentityIQ. The request remains pending and IdentityIQ keeps checking the request’s status at regular interval based on the statusCheck entry. Status check depends on the following workflow variables in “Check Status of queued items” workflow or corresponding custom workflow if custom workflow is used:
- provisioningStatusCheckInterval – Interval in minutes define how frequently IdentityIQ will check the ticket status. Default is 60 minutes.
- provisioningMaxStatusChecks – This is the number of times IdentityIQ will check the ticket status. After that it will be marked as times out. Default is -1 i.e. indefinitely.
Once the ticket is closed in ServiceNow based on the statusMap, it is completed in IdentityIQ also.
Common Issues Troubleshooting
If there is any issue, enable trace for openconnector.connector.servicedesk.ServiceDeskConnector class to debug the issue. This will print the actual request and response in logs and will help adjust different parameters accordingly.
1) Ticket is not getting created in ServiceNow.
- Make sure that all the credentials, URLs etc are correct.
- Make sure that all the required parameters are passed as part of provision -> request.
2) Ticket is getting created in ServiceNow, but the ticket number is not updating in IdentityIQ.
- Check the response returned from ServiceNow and make sure that responseElement entry has the correct expression to be able to extract the ticket number from the response.
3) Request is not getting marked as completed in IdentityIQ even though the ticket has been closed in ServiceNow.
- Check the response returned from ServiceNow and make sure that statusMap has correct mappings. Also, make sure that the status check happened after the ticket has been closed as ticket status is checked every hour by default.
4) Ticket is getting created in ServiceNow but requested for and/or requested by fields are not populating.
- Check if these identities have a ServiceNow account associated with their identity cube in IdentityIQ.
Conclusion
Integrating SailPoint IdentityIQ with ServiceNow can significantly streamline your ITSM processes. By following the outlined steps, you can create service requests, incidents, and change requests directly in ServiceNow using REST APIs. This integration not only enhances the efficiency of your IT operations but also ensures seamless management of accounts and ticketing functions.
However, it’s important to note that troubleshooting may be necessary to fine-tune the integration process. With the right configuration and regular status checks, you can leverage the full potential of this integration to optimize your IGA deployment.
Author: Gaurav Jain, IDMWORKS, Sr. Identity & Access Management Architect