Check for the change manager in a change request

[NamanChaturvedi]

Hi,
I have a requirement to update the change managers for a certain application.
I am having a look at one of the normal changes, not able to figure out from where and how is the change managers getting populated.

For my change request I have in total 3 groups as change managers for that change.
I need to know is it based on the CI selected, the assignment group, flow designer or something else.
I need all the possible scenarios from where we could see change managers getting populated.

[Naveen20]

These are possible scenarios.

1. Change Management Assignment Rules

ServiceNow has out-of-box assignment rules specifically for Change Management. Navigate to Change > Administration > Assignment Rules (or sysrule_assignment table filtered by the change_request table). These rules evaluate conditions like category, type, CI, assignment group, or any other field on the change, and can auto-populate the Change Manager or Change Manager Group. This is one of the most common sources and is easy to overlook.

2. CI-Based (CMDB Configuration Item)

When a CI is selected on the change request, the CI record itself can have a "Managed by" or "Managed by group" field. Business rules or assignment rules can copy these values into the Change Manager fields. Check the CI record's Managed by and Managed by group fields, and then look for any business rules on change_request that reference cmdb_ci or copy values from the CI.

3. Assignment Group Mapping

The assignment group selected on the change can drive the change manager population. There could be a custom mapping table or a business rule that says "when assignment group is X, set change manager group to Y." Look for business rules that trigger on the assignment_group field change.

4. Flow Designer / Workflow

Flows or legacy workflows can set the change manager at various stages. Check Flow Designer for any flows associated with the change request table, and also check Process Automation > Flow Designer filtering by the change_request table. Legacy workflows can be found under Workflow > Workflow Editor — open any workflows tied to change request. Either of these could have a step that sets the change manager field programmatically.

5. Business Rules

This is the most common hidden culprit. Navigate to System Definition > Business Rules, filter by table change_request, and look for any rules that set change_manager, change_manager_group, or u_change_manager (if customized). Pay special attention to rules that fire on insert or on update of fields like CI, category, assignment group, or type. To quickly find them, right-click the Change Manager field on the form, select Configure Dictionary, and check if there's a Default value or a Calculated flag set. Also try right-clicking and choosing "Show - Loss of focus" or check the client scripts.

6. Client Scripts / UI Policies

An onChange client script on the CI field, assignment group, or category could be making a GlideAjax call to fetch and set the change manager. Check System UI > Client Scripts filtered for change_request. Similarly, UI Policies can set field values — check System UI > UI Policies for the change_request table.

7. Data Lookup and Record Matching Rules

Navigate to System Policy > Data Lookup Definitions and check if there are any lookup rules for the change_request table. These can auto-populate fields (including change manager) based on matching conditions like CI class, category, or assignment group, without writing any code.

8. Script Includes Called via GlideAjax

A client script might call a Script Include that performs complex logic (e.g., looking up a custom mapping table) to determine the appropriate change manager groups. Search Script Includes for references to change_manager.

9. ACE / Change Model / Template

If the change was created from a Change Model or a Record Producer/Catalog Item with a template, the template itself could have pre-defined change manager values. Check the change model under Change > Administration > Change Model and see if the model has default values for change manager.

Recommended Debugging Approach

To pinpoint which mechanism is setting your three change manager groups, do the following. First, enable the Debug Business Rules session flag (navigate to sys.scripts.do or use the session debug modules) and create or update a change — the debug output will show which business rules fire and which fields they set. Second, open your browser's developer console Network tab, create/update the change, and watch for any GlideAjax calls that might be fetching change manager data. Third, run this quick script in Scripts - Background to find all business rules touching the change manager field:

var gr = new GlideRecord('sys_script');
gr.addQuery('collection', 'change_request');
gr.addQuery('active', true);
gr.addQuery('script', 'CONTAINS', 'change_manager');
gr.query();
while (gr.next()) {
    gs.info('BR: ' + gr.name + ' | When: ' + gr.when + ' | Order: ' + gr.order);
}

You can run similar queries replacing sys_script with sys_script_client (client scripts), sys_ui_policy (UI policies), sysrule_assignment (assignment rules), and dl_definition (data lookup rules).