--- sourceDocument: Australia IT Service Management sourceDocumentLink: https://www.servicenow.com/docs/r/australia/it-service-management Release : - australia ft:locale : - en-US ft:publication_title : - Australia IT Service Management ft:clusterId : - itsm bundleId : - itsm workflow : - Technology --- # Change model attributes # Change model attributes {#ariaid-title1} Release version: Australia Updated September 30, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Change model attributes Change model attributes in ServiceNow are tags assigned to states within a change model, enabling scripts to detect and respond to the presence of these attributes in the current state of a change request. This allows you to control and customize functionality based on the specific state of the change. Change models define the lifecycle states of change requests, and attributes enhance control over what actions are allowed in each state. Show full answer Show less ## How Change model attributes work * Each attribute has a label, name, optional description, and is associated with the Change Request \[changerequest\] table or its extensions. * Attributes do not have inherent effects until assigned to one or more states in a change model. * Once assigned, both server-side and client-side scripts (such as business rules, UI actions, and client scripts) can check for these attributes to enable or disable functionality in that state. * Attributes are assigned per state via the Attributes list found in the Model States related list of a change model, alongside state transitions and field policies. ## Base system change model attributes The system includes two predefined attributes that govern key change request behaviors: * **Allow CI Modification**: Determines which states allow modification of the Configuration Item (CI) and affected CIs. Without this attribute, the CI field is read-only and affected CI modifications are disabled. * **Allow Implementation**: Defines states where proposed CI changes can be applied. If the Allow CI Modification attribute is not assigned to any state, the default behavior permits CI modification only in the New state. Assigning this attribute to specific states restricts CI modification to those states only. ## Practical example For organizations that create a configuration item as part of the change process, the CI field remains empty initially and is populated only after approvals. Assigning the Allow CI Modification attribute solely to final states supports this workflow by allowing CI modification only when appropriate. ## Managing change model attributes * **Create a change model attribute**: Define custom attributes to assign to change model states and control behavior via scripting. * **Assign attributes to states**: Attach these attributes to specific states in a change model to enable scripts to detect and react accordingly. * **Use API methods**: Utilize provided server-side and client-side API methods to check the presence of change model attributes for a change request in its current state, facilitating dynamic behavior control. Change model attributes are tags that you assign to states in a change model. Scripts can check which attributes are present in the current state of a change and turn functionality on or off for that state. A change model defines the states that a change request moves through. With change model attributes, you can also control what's allowed in each of those states. You define an attribute once, and then assign it to one or more states in a change model. Within a state, the attribute is available to both server-side and client-side scripting, so business rules, UI actions, and client scripts can check for it and trigger different behaviors. ## How change model attributes work {#change-model-attributes__section_how-attributes-work} Each attribute has a label, a name, an optional description, and a table. You can define attributes only for the Change Request \[change_request\] table or tables that extend it. An attribute defined on a table is available for all extensions of that table. A new attribute doesn't do anything on its own. After you assign it to a state in a change model, scripts can check whether the attribute is present for a change in that state. For example, a script can allow a feature when the attribute is present and disable it when the attribute is absent. You assign attributes in the Attributes list under each state in the Model States related list of a change model. This list appears alongside the state transitions and state field policies for the state. ## Change model attributes in the base system {#change-model-attributes__section_base-attributes} The base system includes two attributes that already drive change request behavior. {#change-model-attributes__section_base-attributes__entry__3} | Label | Name | Description | |-|-|-| | Allow CI Modification | `allow_ci_modification` | Determines the states in which you can modify the configuration item and the affected CIs on a change. When the attribute isn't present for a state, the Configuration item field is read-only and the options to add or modify affected CIs are removed. | | Allow Implementation | `allow_implementation` | Determines the states in which you can apply proposed CI changes from a change request. | [Table 1. Base system change model attributes] ## Default behavior when a model has no Allow CI Modification attribute {#change-model-attributes__section_default-behavior} If you don't assign the Allow CI Modification attribute to any state in a change model, change requests that use the model follow the original change request behavior. The configuration item can be modified only in the New state. After you assign the attribute to at least one state, the model controls CI modification. The configuration item can be modified only in the states that have the attribute. For example, if you assign the attribute only to the Assess state, the Configuration item field is read-only in the New state. ## Example use of change model attributes {#change-model-attributes__section_example-use} Some organizations use a change request to create a configuration item. The CI doesn't exist at the start of the process, so the Configuration item field stays empty. After the change passes through the required approvals, the CI is created and added to the change at the end of the process. Assigning the Allow CI Modification attribute to only the final states supports this process. * **[Create a change model attribute](https://www.servicenow.com/docs/knuoqMbEnOZ4BywTeVV51Q)** Create a custom change model attribute that you can assign to states in a change model and check in scripts to control behavior for each state. * **[Add an attribute to a change model state](https://www.servicenow.com/docs/~r5yf4CncW6CX82nyxCBWw)** Assign a change model attribute to a state in a change model so that scripts can check for the attribute when a change request is in that state. * **[Change model attribute API methods](https://www.servicenow.com/docs/zMBFdwbAgdA_g4p7HOGU1Q)** Use these server-side and client-side methods to check which change model attributes are present for a change request in its current state.