1 CI but multiple change approver groups
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
In CMDB, they say there has to be 1 CI for 1 instance.
For example, lets say Azure Databricks.
It can have multiple instances owned by many different teams but there should be only 1 CI - Azure Databricks.
Now, different teams are saying they each need to be change approver group on this CI, so they are asking us to create multiple Azure Databricks entries but we know this goes against general CMDB principles.
So, 1 CI but multiple change approver groups.
How do we resolve this dilemma?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @NOW_seeker ,
You are correct creating multiple CIs for the same shared platform or service just to support different approver groups would go against CMDB normalization and CSDM principles.
For shared platforms like Azure Databricks, the recommended approach is usually
- Maintain a single CI for the shared service/platform
- Use multiple Change Approval Groups through:
- CI Relationships
- Service Offerings
- Dynamic approval logic
- CAB rules
- Change Models / Risk conditions
Instead of duplicating the CI.
A common pattern is:
- 1 platform CI
- separate Application Services / Service Offerings / Technical Services for each owning team
- approvals derived dynamically based on the impacted service or assignment ownership
ServiceNow best practice is generally:
- avoid duplicate CIs for ownership or process reasons
- keep the CMDB normalized
- drive approvals using relationships and governance logic rather than CI duplication
Otherwise you end up with:
- duplicate discovery reconciliation issues
- inaccurate impact mapping
- fragmented ownership
- reporting inconsistencies