If you have looked at the schema for many of the tables within Service-now, you’ve probably noticed the Correlation ID and Correlation Display fields and may have wondered what they are for.Â Typically, these fields are used for integrating a third-party system with Service-now. Let’s assume that I am doing an integration with a alerting system system from HP called OpenView.Â In this integration, alerts are sent from HP to Service-now.Â When the ticket is updates and/or closed, Service-now updates/closes the alert in OpenView.
When an alert is received by Service-now, the relevant fields from the alert are mapped to a Service-now incident. Since it is so common to want to know what the actual alert number is in OpenView, we have place to store that on the incident table.Â The field is called the correlation_id.
The correlation_id field stores the unique identifier (in the other system) for the incoming task, or for the sake of our example, the incoming alert.Â This field is important for a couple of reasons.Â First, many customers want to display the OpenView ticket number on the incident form itself in case the operator wants to go to OpenView and look at the alert himself.Â Second, storing this information allows Service-now to update the alert in OpenView when the incident is updated and/or closed.Â In this integration, we use our mid server to call an OpenView shell command that accepts the unique id for the ticket in addition to other parameters to update that ticket.
It is common for administrators to desire to know the origin of the tasks, CI’s, users, etc, that exist in their table.Â If they are looking at a list of CIs, it might be important to know whether the Service-now discovery tool, a LANDesk integration, or a consumed csv file was the source of each of the CIs now existing in our CMDB.Â This is where the correlation display comes in handy.Â In our OpenView integration example, whenever we receive an incident from an alert sent from OpenView, we hardcode the correlation_display to be “HPOVO”.Â This allows administrators to know the source of their incident.Â Using this field they will know that it became an incident because of the OpenView system, as opposed to their MS SCOM alerting tool or even a service desk operator.
Another use for the correlation display is to assist with the integration itself.Â When a business rule is written to send data back to OpenView, it is good practice to put in the condition field: current.correlation_display == “HPOV” in addition to your other conditions.Â The reason should be obvious.Â If you want to update an alert in the 3rd party system, you want to make sure that you’re sending the updated alert information to the correct system!Â While many people often leave this out of the condition statement, it is considered good practice to put it in.Â If you do, your integration will not break if a new alerting integration is added in the future.