Following our Identification and Reconciliation post in this series, I wanted to briefly introduce the Identification Rule, a key part of the IRE system. We’ll continue to dig into IRE with this series, check back for more soon.
Now that you’ve decided to funnel all of your Configuration Items (CIs) into ServiceNow via IRE, we need to sort out what each item is, and how it should be marked as unique. Identifications Rules perform this step with two distinct parts.
Part 1 – Identification Rules (the obvious one)
- You’ll find these under CI Identifiers
- Each destination CI class will get one CI Identifier / Identification rule
- Specifies whether this CI class is Independent or Dependent (dependant CIs must be related to another CI to be allowed through IRE into your CMDB)
- Your post to IRE includes the destination class, which indicates the rule to use
With an Identification Rule selected by your inbound CMDB payload, lets take a look at the contents of the rule and why they are critical to your configuration.
Part 2 – Identifier Entries
- One or more are contained within the Identifier Rule
- Specifies what properties make this CI unique
- Indicates what table to look at to find a matching record
- Sets the order [priority] to use when matching an existing CI
Putting it all together
Using the combination of an Identification Rule and an Identification Entry ServiceNow can now uniquely identify an inbound CMDB payload. After identification, the system can use this information to create a new CI or update an existing one, rather than creating duplicates.
In our next post we’ll talk about Related Entries in identification.
Succinct ServiceNow; condensing complex topics into an elevator pitch.