Integrating with ServiceNow

Service Panel has multiple integration approaches that may be used with ServiceNow. Choice of integration will determine level of developer effort on the the Service Panel and ServiceNow sides. The following documentation is divided into Inbound integration options (where requests are coming from ServiceNow), and Outbound integration (where requests in ServiceNow are being updated or created).

It should be noted that these approaches are not mutually exclusive. They may be mixed and matched based on the business requirements of particular user stories.

Inbound Integration

There are three approaches to inbound integration:

Push based ReST API Integration

The ServiceNow workflow engine may be used to push request data into Service Panel via Service Panel's ReST API for posting form data.

Pros

• Immediate event based integration means requests are fulfilled automatically
• Forms can be built in Service Panel which may be accessed directly by users, or by the ServiceNow workflow engine
• By adding a hidden input in Service Panel to capture the sysid, an outbound integration can be used to update ServiceNow after the request is fulfilled.
• There is no need to implement custom APIs or create service accounts with elevated access in ServiceNow.

Cons

• This integration approach is by far the most labor intensive, as it requires extensive implementation work on both the Service Panel side and the ServiceNow side.
• If ServiceNow developers are busy in the organization there may be a substantial project delay to schedule enough implementation time to perform the integration
• Reliant on both teams correctly and completely implementing form fields and passing data validation
• ServiceNow developers may find it challenging to implement the SCRAM-SHA authentication used by daemon requests to Service Panel

Pull based ReST API Integration

The Identity Panel ServiceNow provider may be used to pull request data by scanning the ServiceNow table API

Pros

• Can be lower effort to configure on both the ServiceNow and Service Panel side
• May not need to implement Service Panel forms at all: Instead workflows can be written directly off the ServiceNow data feed

Cons

• Requires a service account in ServiceNow
• If using standard request tables, the service account will need fairly elevated permissions. Alternatively, workflows will need to be implemented in ServiceNow to copy requests into a staging table.
• Reliant on ServiceNow to implement forms for all required data, and full validation must be performed inside ServiceNow

Hyperlink Based Integration

Hyperlink based integration relies on Service Panel's ability to bind form inputs based on URL query parameters passed via hyperlink. This integration method waits for the user to open a request in ServiceNow, then uses the ServiceNow workflow engine to add a comment to the request with a hyperlink for the user to click on, which will take them to a Service Panel form.

Pros

• This integration method has by far the lowest implementation effort on the ServiceNow side. Catalog items only need basic information capture to handle approvals and category of operation, and full details and form validation may be implemented in Service Panel
• Forms may be implemented in Service Panel in advance, then bound to ServiceNow catalog items gradually over time or on an as-needed basis
• Any data captured by ServiceNow can be relayed in the link where it can be re-validated by Service Panel and missing data can be captured

Cons

• Requires an additional step of the user to follow the fulfillment link over to Service Panel

Outbound Integration

All outbound integration from Service Panel back to ServiceNow requires implementation effort in the ServiceNow ReST APIs.

In order to add an outbound integration to update requests, the inbound integration must pass the request id or other suitable identifier (supported by all three inbound integration methods).

Data may be sent back to ServiceNow by:

1. Using fixtures to directly update records in the standard ServiceNow tables using the TableAPI (not recommended)
2. Using fixtures to write records into a custom staging table in ServiceNow using the TableAPI, at which point the records must be processed by ServiceNow workflows
3. Using fixtures to directly call a custom ReST API implemented in ServiceNow using the custom API builder