ServiceNow – Incident Integration

There are times when you would like to Integrate two instances and send record data back an forth between the two. This model is based on the fact that one of the two instances is the instigator of Ingratiating a record (is the one that will make first contact), the other will not (Customer | Supporter). This model is also built around the ‘Assignment Group’ on company ‘A’ being the trigger for integration. When a Integrated Assignment Group is picked for a record then that is when the Integration workflow will kick in, and if the Assignment Group is changed to a none-integrated group it will the trigger ‘Integration Breaker’ and end integration (This or ‘Resolved’ status, or if Company ‘B’ is manually stetting Group to ‘Generic Integration Breaker’).

This model is also great for the company being the receiver as model is designed to be able to host multiple integrations against the same workflow and tables on the receiver company (all filtered against ‘Company’). Rather than new workflow and tables for each new integrated company.

Check-boxes and Explanation set up and controlled via ‘System Properties‘:

This overview will talk about:

• Mapping tables needed in both instances
• Configuration of web service (allowing instances to communicate by sending XML records)
• Business Rules (containing the actions that will take place in an instance when the XML is received)
•  SOAP / REST
• Integration Breaker and it’s components.

Field Mapping (Each Instance, unless they are identical) needs to be able to map attribute values to create a common understanding. Attributes Like:

Assignment Group Mapping (On both sides) – Example: Company (A) Assignment Group = ‘HUK L2‘ <-> Company (B) Assignment Group = ‘EMEA-RUK-ITS-L2′.

• The same mapping table has an attribute called ‘Company (A) support’ (TRUE or FALSE) that is used by business rules to determine which of the added Groups will trigger integration to start.
• 

State Mapping – We also need to map the States between the two instances A & B. In this case Company (A) also have a sub state field called ‘Reason Code’ (Not existing in company ‘B’) why this attribute is also added as ‘Reason Code’.

Closure Code Mapping – When a record is Resolved then we also need to send mapped Closure Code data why this reference mapping table also is needed. In this table we hold both ‘Closure Category’ and ‘CC Description’ for both companies.

Application Mapping Table – This one is interesting as company (A) has ‘Application’ and ‘Business Services’ that translate to ‘Service Offerings’ in company ‘B’. Due to this all data is mapped. In this table we also hold sys_id BUT only as a choice as we can validate either against label name or sys_id.

NOW WE ALSO HAVE THE SAME TABLES ON THE RECEIVING COMPANY SIDE BUT THESE ARE DESIGNED TO HOST DATA FOR MULTIPLE INTEGRATIONS FILTERED AGAINST ‘COMPANY’ FLAG.

State Mapping:

Incident Priority Mapping:

Assignment Group Mapping

Core Company Mapping:

Generic Outbound Endpoints:

To Connect ‘INBOUND INCIDENT WEB-SERVICE’