IRE Indentification: Related Entries

maciep · 3 weeks ago

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 · 2 weeks ago

Hi @maciep ,

Ahh, I believe you "replaced" the Identification type Rules. It is supposed to modify everything underneath because that is the first step to define the Parent-Child relationship name and its behaviour. When we try to modify that, the underlying Identifier Entries and Related Entries are bound get wiped out. When we say "Identifier rule"- we generally mean the "Identifier Entries" for the specific class. Most gets defined and copied from the parent class when the "Identifier Rule Types" are defined. But when you "Replace" the relationship, you are first removing the existing class relationship hence removing all other sub definitions as well.

Pls refer to this article for better understanding: Identification rules • Australia ServiceNow AI Platform Capabilities • Docs | ServiceNow

Happy to be of any help 🙂

Regards.

maciep · 2 weeks ago

Yep, that's correct.

And I just threw together a quick bg script to see if any records in the related entries tables referenced any records in the class I'm modifying. There were none, so I'm not going to add those related entries back. We'll create them if needed in the future.

And now that I've had time to play with this in my PDI, I have a better understanding of how related entries are used (creating the payloads helped a ton). There are still some scenarios I want to understand better, so I'll keep playing for a bit and then come back here with my thoughts.

doug_schulze · 2 weeks ago

I did a write up on those a while back, you can find it here.

https://www.servicenow.com/community/itom-articles/switching-from-probes-sensors-to-patterns-somethi...

The images are gone but all they are showing is the two sections of the identifier entries

maciep · 2 weeks ago

Thanks, Doug. I had come across your article already. I just like tangible details, so I think I really needed to put the payload together myself and see how it actually works. And now I'm seeking more understanding through trial/error.

If the related entry is a CI class with its own identification rule, does that rule affect the CI as related item? Doesn't seem to. If I don't specify an attribute in the related entry, does it just always create a new CI. Doesn't seem to, but want to understand that better. What if there are multiple CIs that match the attribute for the related entry, does it error? update one? update them all? etc.

I like to understand how everything actually works and servicenow doesn't like to document those details. Or if they do, I can never find them. I usually find their docs are effectively like "related items are for items that are related" or "to create a related item, click this button and fill in these fields". It just rarely does it for me.

doug_schulze · a week ago

Identifier entries match the base class CI, measured in the identification of a hardware CI, think of a windows server.

Identifier entries 'and' Related entries support non-base class CI's in their reference and relationships built within the patterns, think of disks, memory modules ect.

So if someone didnt want to use serial number as an example to match their servers, the hardware CIs, they can take it out of the identifier entries section. BUT we still need to match serial number tables references and relationships in the pattern so it would have to be entered into the related entries section so that does not fail..