Get Change Models working again: Start with the right diagnosis

Claire_Conant · 2 weeks ago

Change Models can fail in ways that look similar on the surface but require completely different fixes. A missing Change Model field and a Change Model your team can't see are two separate problems with two separate causes. And the steps that solve one will do nothing for the other. Start with the following two prechecks, then use the three diagnostic questions to route yourself to the right path.

Before you start, confirm that these required plugins are both active:

Change Management - Change Models
Change Management - Change Model Foundation Data

Go to All > System Applications > All Available Applications > All and search for each plugin name. If the status isn't Active, select Install to activate it.

Which scenario matches yours?

Before working through the sections below, answer these three questions:

Is the Change Model field missing entirely: no field on the form and no interceptor page when creating a new change? → Go to: The Change Model field is missing from the Change Request form
Can you see Change Models, but colleagues on your team can't? → Go to: Change Models are visible to you but not to your team
Is the Change Model field visible and selectable, but something about how changes are routed or processed has shifted since an upgrade? → Go to: Change Models are present but behave differently after an upgrade

The Change Model field is missing from the Change Request form

If no one can see the Change Model field or the interceptor page that appears when creating a new change, a system property is almost certainly hiding it. The com.snc.change_management.change_model.hide system property defaults to true on upgraded instances but doesn't exist at all on new ones. This is the single most common reason for a missing Change Model field.

Quick check: Go to System Properties, filter for change_model.hide, and set it to false if it's currently true. If the field still doesn't appear, the companion type_compatibility property may also need adjustment.

For a step-by-step walkthrough of both properties and how they interact, see the companion article, Change Models not appearing on the Change Request form? Check these four settings.

Change Models are visible to you but not to your team

The issue here is in the access layers that sit underneath the system properties. There are two distinct places to check, and it's worth working through them in order.

Check 1: User criteria

Each Change Model record controls its own visibility through the Available For and Not Available For tabs. As an admin, you may have access that other roles don't. Go to Change > Administration > Change Models, open the model that your team can't see, and check whether the affected users match at least one entry in Available For and that they don't appear in Not Available For.

Check 2: Role assignments

The itil role (which contains sn_change_read) is what grants Change Model visibility to most users. After an upgrade, ACL configurations can shift in ways that aren't immediately obvious. A common post-upgrade symptom: your team can see Change Models in Core UI but not in the Service Operations Workspace (SOW).

Go to All > System Security > Access Control (ACL) and filter for the std_change_record_producer table with the current_version field. Open the ACL record and verify that the itil role is listed on the Roles tab. If it's missing, add it. Also check the ACLs on the change_request table to verify that the expected roles are in place.

Change Models are present but behave differently after an upgrade

If the Change Model field is visible and users can select models, but how changes are routed or processed has shifted since your upgrade, the issue is usually in how the platform decides which automation runs.

ServiceNow can route change requests in two ways: through the Type field (Normal, Standard, Emergency), which drives workflows based on the type value, or through Change Models, which define the full lifecycle in a single record. The com.snc.change_management.change_model.type_compatibility system property controls whether both approaches run at the same time.

When the type_compatibility property is set to true, both routing methods are active. Common symptoms include:

Both the flow (Flow Designer) and the workflow (Workflow Editor) run for the same change, producing duplicate approvals or change tasks
The Type field shows a Model option that wasn't present before the upgrade
State transitions fail with errors like "Change model prevented state transition"

What to check

Go to System Properties, filter for change_model.type_compatibility, and confirm whether the value aligns with your intended routing approach. If you want Change Models to be the only routing method, set this to false. If state transitions are failing, the Change Model may be missing required transition definitions.

Where to go from here

If none of the three scenarios above matched your situation, one additional check is worth making: if the Change Models interceptor page isn't loading at all—even for admins—you may need to update the Accessible from field on the StdChangeUtils script include to All Application Scopes.

If you're still stuck after working through all of this, the ITSM Community forum is the right next stop. When you post, include your instance version, the values of the two system properties covered above, and which UI you're working in—those three details can save several rounds of back-and-forth.