Server CIs and related change requests

[kg4ult]

Hello all,

I have some Dynamic CI groups with servers that range from 1-150 servers respectively.
When a change request is created we have users populate the Dynamic Ci groups name in the Configuration Item Field.

Now the issue we are having is, when we look at the change request we can see the following:
Affected CI tab
Dynamic CI Group name CI
Any and all servers in that group

The issue is, when you select each server from this list or you go to the individual server CI record, you cannot see any related changes.  Another vaveat - when you select the "Open Dependency View" button, you can see that server and the "lego icon" - it only has the most recent open Change Request present. 


My situation
I have application instances for specific customers with related servers and network devices. 
These can be seen as Dynamic CI groups a they are setup similarly. 
Short of just listing the server name in the Configuration Item box in the change request, how  can i visualize any and all changes related to that server or groups of servers?

NOTE: I am not an admin unfortunately. So there is very little i can modify or change. I am the configuration manager for the company i work for but they will not grant me admin rights (long story of how this company operates the CMDB)

Thank you.

[danmjunqueira · Accepted solution]

Hey @kg4ult how are you?

You're describing a very common challenge in environments where Dynamic CI Groups are used in Change Requests, but the traceability back to individual CI change history is incomplete or inconsistent.

Here’s a breakdown of why this happens, and my suggestion about what you can do as a Configuration Manager without admin rights.

Why You Can’t See All Changes on Individual CI Records:
When a Dynamic CI Group is added as the Configuration Item (CI) on a Change Request;

The group itself is tracked as the main CI on the Change.

The individual CIs in the group are listed as "Affected CIs".

However, these affected CIs are not automatically updated with a reference back to the Change Request in their cmdb_ci_chg_assoc (Change-CI) relationship table.

This means:

The group sees the change.

The Change sees the individual CIs (Affected tab).

But the individual CI records themselves do not show the change under "Related Changes".

What You Can Do (Without Admin Rights)
1. Use Reports or Dashboards Based on Affected CIs
You can create a Change Request report using the task_ci table.

This table stores the Affected CI relationships.

Filter by: task.type = Change Request and ci.name = [Your Server Name]

This will show all changes where your server was an affected CI, regardless of whether it was in a Dynamic Group.

You can request your admin or reporting team to publish this as a dashboard.

2. Use Dependency View Strategically (As You're Already Doing)
The Dependency View does reflect the most recent open Change Request due to its default filtering.

Ask if they can configure Dependency View to show a timeline of past changes, or if you can at least manually filter by CI or task.

It’s limited but still useful for one-off analysis.

3. Request a Business Rule (If You Can Convince Admins)
Even though you can’t do it yourself, suggest to your dev/admin team:

Create a Business Rule that, when a Dynamic CI Group is added to a Change Request, automatically:

Writes a Change-CI (task_ci) record for each member of the group.

This would populate the Change history on each individual CI.

This is standard best practice and doesn't require major refactoring.

4. Leverage CMDB Query Builder (if available)
If CMDB Query Builder is enabled:

You can construct a query that relates all servers to their affected changes.

It's read-only and doesn’t require admin access.

Exporting or visualizing this over time can help you build customer-specific change maps.

I hope this can help you to have a solution.

[kg4ult]

Thank you very much. I will speak to the admin.

Another interesting issue is i tested individual servers by adding them to the affected and impacted table. Curiously enough, these dont show relationships to the change request despite me adding the servers to the change directly. So something is off.

I then checked (because we have a CMDB that is used globally for our company) other changes abroad where a server was added to either "Affected or Impacted" fields and low and behold those are linked to any changes either. 
I suspect that the out of the box relationship functionality is "turned off" for some reason. 

I will try the CMDB Query Builder function now. 

[danmjunqueira]

You're right to suspect that something deeper is misconfigured or disabled in your instance,  what you’re observing is not expected OOB behavior.

By default, when you add a Configuration Item (CI) to either the Affected CIs (task_ci) or Impacted CIs (task_impact) related list on a Change Request, ServiceNow should automatically show those relationships in the CI record under:

Related Changes (on the CI form)

Configuration Item → Related Lists → Change Requests

It’s very likely that some out-of-the-box CMDB-change traceability features have been deactivated or bypassed, which is common in federated or global ServiceNow instances where different BUs operate with different maturity models.  Most teams only discover it after a failed audit or root cause review. You're absolutely justified in raising this with your platform or process owner.