IRE Indentification: Related Entries

[maciep]

I've read a lot about Related Entries - there are multiple forum posts, articles, videos, etc. But I'm still missing something. How are they actually used?

The docs say, "Related entries let you create or update records on other tables".  They "let" us. Ok, what does that mean. Does the IRE actually do it for us? Or does just "let" us?

And generally, I get "updating" other records. But "creating" them? I don't understand how the IRE would know when to create a Related CI.

For example, let's say a payload for a Windows Server hits the IRE and it identifies an existing CI. It will update  that CI accordingly. Will it also iterate through the Related Entries and then update the related CIs that match. Like if there are 5 Software Installation records currently for that identified CI, does the IRE update those as well?

And what if that payload is for a new CI. Surely it doesn't "create" a record in the Software Installation table, right? I mean, we have classes inheriting Related Entries from Hardware and it would never make sense. Like an IP Switch being related to an MSSql Component or whatever.

So does the IRE actually take action on those related items? And if so, which actions and in which scenarios? Or is it literally just a reference to be used by some other processes to identify records that might need updated?

Does anyone know it well enough to walk me through some sample payloads to explain how the IRE interacts with the Related Entries? 

I think I've read all of the posts/articles that typically get linked in these questions, but I'm just too dumb to get it so far.

[AJ_01]

Hi @maciep ,

I would try to answer the best possible.
IRE is used for majority of transforms to CMDB/ non-CMDB  tables in ServiceNow. That said, it includes scheduled jobs via data sources having relevant transform maps added to the configuration, and any discovery process (top-down, horizontal discovery), service graph connectors which also have data sources and transform maps etc...

When you mention  ---"""I get "updating" other records. But "creating" them? I don't understand how the IRE would know when to create a Related CI"""... I would assume you are not considering Discovery or Service Graph Connectors, Integration Hub etc processes. 
These processes have incoming payloads which contain the relation specifications as well. To explain in very simple terms, these processes have certain integration/scanning processes which bring payloads which might be complex with all the details of the primary devices and their relationships and details of those secondary devices with as much details as possible. ServiceNow has some OOTB scripts to convert them into cleansed and formatted payloads which can be transformed using IRE and thus the primary and the secondary devices can be created as well as updated. 

But we have a lot of flexibility on how much we can control- the creation, updates as well as restricting any of those activities. 

I would request you to go through the two links below and some of the related links in those pages:

1. Identification and Reconciliation Engine (IRE) • Australia ServiceNow AI Platform Capabilities • Doc...

2. Dynamic IRE • Australia ServiceNow AI Platform Capabilities • Docs | ServiceNow

3. IRE support for non-CMDB tables • Australia ServiceNow AI Platform Capabilities • Docs | ServiceNow

Please Accept the solution if it assisted you with your question & Mark this response as Helpful.
Regards

[maciep]

Thanks. I'll check out those links to see if they help. But I still don't get it.

If the incoming payload includes a relation specification as well, then why would I need that same relation defined in the Related Entries? Does it have to be defined there for the IRE to be able to process the payload. The IRE can't handle related items in a payload otherwise?

Are you saying that those OOTB scripts use the Related Entries to help parse/format the payload first before sending to the IRE? So the IRE itself doesn't really use them, they're just a reference in like a pre-processing step?

I think like most things on this platform, I might just need to figure it out via trial/error on my PDI. Maybe I can make sense of how it's used then.

For context, I need to update the identifier for a class and trying to understand if there is a need copy all of the Related Entries that class was previously inheriting, or a subset or none at all. The majority don't seem related at all and are defined at the Hardware level, but since I don't really understand how they're used, I don't really know what's needed.

[AJ_01]

hi @maciep ,

First the Input payload is built by the SNOW processes- ( Discovery/scanning, manual import, integration paylaod etc) in JSON format. In complex payloads, this payload contains relationships and possible related entry details.

This entire payload passes through IRE, which looks for and is instructed to pickup details for primary and secondary devices from the JSON. 

The primary devices is updated/created and similarly if any valuable information is found in the payload, the relationships are built and related entry records are also created/updated. 

The second part of your question is- how to update an identifier for a class:

You can go to the Class manager and try to update the identifier for that class only. We do not need to modify the related entries or relationships(class inheritance) for OOTB classes without proper context, as we might be stopping valuable information from getting recorded in CMDB. Modification of identifier for a class is independent of other configuration like related entries and suggested relationships. However, I would suggest you to analyse the identifier you are trying to setup, since this manages how duplicates are identified. 

Please Accept the solution if it assisted you with your question & Mark this response as Helpful.
Regards

[maciep]

Thanks again for trying, but I'm going to go figure this out myself. It's not that I don't understand what you're saying, but I need more actual details. I'm going to see what I can figure out in my PDI.

And yes, I did replace the identity rule on the sub-class but that also removed all of the inhertied related entries as well. I don't know which ones to put back. And I don't want to just mindlessly copy them all, I want to understand which ones I actually need and why.