2
24.08.00
Xanadu, Washington DC, Vancouver
Kyndryl Integration - Service Request Inbound is built to standardize all Service Request inbound integrations using Web Services that acts as publisher for all external tools. Service Request inbound integration can be setup quickly using a properties console. This app also enables a developer to configure the integration based on specific customer requirements.
- Easy implementation
- When building new ServiceNow instances or new integrations on existing instances, a faster, consistant, well tested and centrally managed scoped application which is ready for use within a few hours.
- This application offers wide variety of configuration options. Therefore code customization is not needed.
- Processes the payload received on the API endpoint, enforces security (authentication, OAuth if configured, access to Service Request Integration), validates the payload and creates or updates Requested Items and/or Catalog Tasks.
- No custom tables added that will incur ServiceNow licensing charges as of this document published date.
- No ServiceNow out of the box tables or forms modified.
- Publisher/Consumer concept
- Based on Publisher/Consumer concept, inbound into this instance (Publisher) uses generic processing that all Service Request integrations are supposed to abide by.
- There is no unique custom code for each integration.
- Coding
- Fully utilizes the ServiceNow platform features (OAuth/Basic Authentication, Web Services, Import Sets, Transform Maps etc) and builds on top of them.
- All coding is on ServiceNow’s no code/low code Flow Designer.
- Returns custom/clean JSON (or XML) responses.
- Flexibility - Application supports:
- Both Domain Separated Instances and Dedicated Instances.
- REST (preferred) and SOAP API’s.
- Inbound – Service Requests
- Catalog Items from source tool are NOT duplicated in the target instance.
- Service Requests are submitted on the source instance (can be non-ServiceNow tools), approved and sent to your target ServiceNow instances for fulfilment.
- Target ServiceNow identifies the inbound Service Request by a service_identifier. Within target ServiceNow easy table-driven definitions create Request/RITM/Catalog Tasks with and without dependencies.
- Source tool is free to change the Catalog Items (questions, choice lists etc) and target system’s fulfilment is NOT impacted.
- Security
- Specific security roles for Service Request web services rather than at the instance level.
- If configured via properties, OAuth will be enforced and integration will not be allowed to use Basic authentication.
- Inbound – Defaults
- Defaults are applied at different stages of life cycle of the record. If the payload contains no value or incorrect value, defaults are applied based on the State of the record.
- On Domain Separated Instances, defaults can be specified at the global level or at a sub-parent domain level.
- Inbound – Easy consistent transformation for fields with numeric values
- On your instance, State numeric values could be different from ServiceNow out of the box or you may have added your own State values. This application uses English words (open, inprogress, onhold, resolved, closed_complete/incomplete/cancelled) for State values which are easily mapped via properties.
- For certain States, automatically set “Assigned to”.
- Inbound - Set external tool number fields
- Usually ServiceNow instances have multiple ITSM integrations.
- Using properties, each & every external tool number can be saved in a specific ITSM field without updating Flow Designer. If no specific field is used, Correlation display & Correlation ID are used.
- Inbound – Support for “misrouted tickets”
- Built-in code to reassign the ticket and break the bond so that no further updates will bridge to that external tool.