Change Models not appearing on the Change Request form? Check these four settings

[Claire_Conant]

You activated the Change Management plugin. You confirmed the activation completed but the Change Model field still isn't showing up on the Change Request form. What's actually going on is that plugin activation is only part of the setup. Four other settings can each keep the field hidden on their own, and the activation flow doesn't tell you they exist. Confirm both plugins are active, then check the four below in order.

Before you check the settings, confirm both plugins are active

These are separate required plugins, and are active by default on base system instances, but if either has been deactivated, Change Models won't function as expected.

• Change Management - Change Models (com.snc.change_management.change_model) This is the core plugin that enables Change Model functionality. The properties mentioned in this article depend on this plugin.
• Change Management - Change Model Foundation Data (com.snc.change_management.change_model.foundation). This plugin provides model definitions and demo data and depends on the core Change Models plugin.

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.

Check these four settings

Each of these settings can independently block Change Model visibility, so fixing one won't automatically resolve the others. Items 1 and 2 are system properties that affect whether Change Models appear for anyone at all. Start there, since they account for most cases of the field simply not showing up. Items 3 and 4 apply when Change Models are visible to some users but not others, or when they appear in Core UI but not in the Service Operations Workspace.

1. The change_model.hide property is set to true

This is the single most common cause when Change Models don't appear after plugin activation. The com.snc.change_management.change_model.hide system property controls whether the Change Model field and the Change Model interceptor page appear on change requests.

Why it's often missed

This property behaves differently depending on how your instance was provisioned.

• On upgraded instances, the property is created during upgrade and defaults to true, which hides Change Models entirely.
• On new instances, the property isn't created at all, so Change Models are visible without any configuration.

If you're comparing a production instance (upgraded) to a developer instance (fresh), this asymmetry is usually the explanation.

How to check

Go to System Properties and filter for change_model.hide. If the property exists and is set to true, set it to false. If the property doesn't exist, this isn't your issue. Move to the next item.

2. The type_compatibility property isn't aligned with your routing approach

This property does not affect whether the Change Model interceptor or field appears. That's controlled by the change_model.hide property in item 1. What it does affect is whether Change Models run alongside the older Type field approach or replace it entirely.

Why it's often missed

Setting the change_model.hide property to false makes Change Models visible, but if the type_compatibility property is also set to true, the instance runs in compatibility mode. In this mode, both Change Models and workflows based on the Type field are active, which can cause duplicate approvals and change tasks if your workflows aren't updated to account for both paths.

For instances that want to use Change Models as the primary routing method, both properties (change_model.hide and type_compatibility ) need to be set to false.

How to check

Go to System Properties and filter for change_model.type_compatibility. If you're keeping this set to true during a transition period, update your workflow conditions to exclude changes where the Model field is populated. Otherwise, both the flow (Flow Designer) and the workflow (Workflow Editor) will run.

3. User Criteria is restricting visibility per user or group

This item and item 4 apply to a different symptom pattern: Change Models are visible to some users but not others, or visible in one UI but not another. If no one can see Change Models at all, the cause is likely in items 1 or 2.

Each Change Model record has its own visibility settings through User Criteria, controlled by the Available For, Not Available For, and Can Write tabs. This is a record-level visibility layer that operates separately from the system properties in items 1 and 2.

Why it's often missed

The typical symptom is that the Change Models work for you but not for your team because as an admin, you may have access that other roles don't. System properties control whether Change Models are visible at all; User Criteria controls which models are visible to which users.

By default, the base system ACL on the chg_model table evaluates standard User Criteria like role, department, group, location, or company. However, if you customized your ACL by modifying roles or adding conditions, those customizations can affect how User Criteria is evaluated. If any of your User Criteria records use advanced scripts, verify that your ACL customizations support those conditions.

How to check

Go to Change > Administration > Change Models, select the model that isn't visible to the expected users, and review the Available For and Not Available For related lists. Confirm that the target users match at least one entry in Available For and don't match any entry in Not Available For.

4. Workspace-specific ACLs are missing roles after upgrade

After an upgrade, the base system ACL configuration for Change Models in the Service Operations Workspace (SOW) may be missing the itil role. This prevents ITIL users from seeing Change Models through the workspace UI, even though Core UI works normally.

Why it's often missed

This is a workspace-specific issue that doesn't produce an error message. ITIL users can still access Change Models through Core UI, so the problem only surfaces when someone tries to use the SOW. Additionally, the current_version field on the std_change_record_producer table may lack proper read access, which causes the SOW interceptor page to fail silently.

How to check

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 check whether 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 there as well.

Where to go from here

If the Change Models interceptor page isn't loading at all, even for admins, try changing the Accessible from field on the StdChangeUtils script include to All Application Scopes.

See: Resolve Change Model page not appearing on interceptor

If Change Models are visible but state transitions produce errors like "Change model prevented state transition," the Change Model may be missing required transition definitions.

See:  Resolve Change Model state transition errors

If your symptom doesn't match any of the four settings above—for example, if Change Models worked yesterday and stopped today, or if the issue only appears for certain users in certain UIs—the companion article, Get Change Models working again: Start with the right diagnosis, walks through three broader symptom patterns and routes you to the right diagnosis.

Working through these four settings, you'll have a fuller picture of what controls Change Model visibility. And you'll also know exactly where to look if something shifts after a future upgrade or configuration change.

Quick reference links

• Change model and Type field behavior in change requests
• Change Models unavailable for ITIL users in SOW after upgrading instance
• Change model state transition blocked after workflow approval
• Change Models advanced security: RBAC and User Criteria
• Change Models properties reference 
• Activate Change Management - Change Models