Impact of changing Class Dependency

[JakePowers]

Hello,

I'm looking to change the Identification Rule of a custom class, and I want to change the class dependency from dependent to independent. This custom class is a child of the Application (cmdb_ci_appl) class, and currently inherits the Application Rule from its parent class. This Application Rule is dependent, but I want to change the class into an independent class.

However, the custom class is used in a lot of scripts, it has many relationships and is vital to our organisation. What would the (possible) effects be if we were to make this change?

[Rafael Batistot]

Hi @JakePowers 

Possible Effects of Making the Class Independent

1. Identification and Reconciliation Changes
   
• Right now, discovery and integration use the Application Identification Rule.
• If you make it independent, discovery patterns, integrations, and imports may fail to reconcile with existing records — leading to:
  
• Duplicate CIs (if the new independent rule doesn’t align with how they were previously matched).
• Orphaned data if references/relationships are tied to old sys_ids.
• You’ll need to redefine the unique keys (attributes that identify this class).
2. Relationships
   
• Relationships to other CIs won’t automatically break. They stay with the sys_id.
• But if duplication happens (old + new CI created), relationships may end up tied to the “wrong” CI.
• Dependency Views and Service Maps might show inconsistent or duplicated nodes.
3. Scripts / Business Logic
   
• Any script, flow, or integration that expects this class to behave like an Application (inherited identification) may stop working or behave unpredictably.
• Example: custom code that looks up cmdb_ci_appl records may not automatically “see” the custom class anymore if you shift its identification.
4. Discovery and Integrations
   
• Discovery patterns that currently populate cmdb_ci_appl-child CIs expect the Application rule.
• After making it independent, they may fail to reconcile → duplicates.
• External integrations (like Service Graph Connectors, imports, APIs) might create new records instead of updating existing ones.
5. Upgrades and Best Practices
   
• ServiceNow best practice: keep dependent identification rules unless you have a very strong reason to break inheritance.
• Making a child independent increases maintenance: you’ll need to manage its Identification Rule forever (updates, merges, collisions)

https://www.servicenow.com/community/itom-forum/what-is-the-difference-between-dependent-and-indepen...

[JakePowers]

Hey Rafael,

Thanks for your reply! It does look suspiciously similar to the answer that I got from ChatGPT, but thanks nonetheless!

[Bhuvan]

@JakePowers 

Below Knowledge Articles should help you,

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1064718#mcetoc_1fs4m6qm716

https://noderegister.service-now.com/kb?id=kb_article_view&sysparm_article=KB0812249

If this helped to guide you or answer your query, please mark it helpful & accept the solution.

Thanks,

Bhuvan