{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":46795,"path":"servicenow-platform/configuration-management-database-cmdb/c_ProposedChanges.md","title":"Managing proposed changes","bundle":null,"doc_type":null,"release":"australia","body":"\n# Managing proposed changes\n\nThe proposed changes feature allows you to pre-configure changes to configuration items and their associated relationships. These pre-configured changes are prepared to be implemented, but do not actually happen until they are applied at a later time.\n\nWhen you view a CI, the proposed changes can be displayed so that you can see what is planned.\n\nThis feature is useful when you want to make modifications while a change process is in the approval stage, and only implement the changes after the approvals are complete. If the change is never approved, no changes to records have to be reversed. If the change is approved, a quick command applies all the proposed changes.\n\nYou can make the following proposed changes to a CI:\n\n-   Modify any field on the CI form.\n-   Add or delete a relationship to that CI.\n\nTo modify a relationship, you must delete the current relationship and add a new relationship. You cannot delete a proposed change.\n\n## View CI history\n\nYou can view the history of changes to a CI in a list, calendar, or timeline format.\n\n## View the proposed changes of a CI\n\nYou can view the proposed changes so that you can see what is planned for the CI.\n\n### Before you begin\n\nRole required: personalize\\_form\n\n### About this task\n\nTo view any proposed changes, configure the CI form layout to display the **CMDB Scheduled Changes** field. Proposed changes are not displayed in a CI form by default.\n\n### Procedure\n\n1.  Navigate to **All** &gt; **Change** &gt; **Open** and open a change request.\n\n2.  In the **Affected CIs** related list, open the **Configuration Item**.\n\n    You may also navigate directly to the CI form.\n\n3.  Right-click the form header bar.\n\n4.  Select **Configure** &gt; **Form Layout**.\n\n5.  Move the **CMDB Scheduled Changes** field to the **Selected** pane.\n\n6.  Click **Save**.\n\n    The CI form shows the details of any proposed changes in the **Scheduled changes** area.\n\n\n## Add a proposed change to a CI\n\nProposed changes to a CI can be made while viewing a change request or any task-related record.\n\n### Before you begin\n\nRole required: sn\\_cmdb\\_editor or itil\n\n### Procedure\n\n1.  In the Change Request form, go to the **Affected CIs** related list.\n\n    If there are no CIs in the Affected CIs list, click **Edit** to add CIs that are affected by this change request.\n\n2.  Right-click the CI that you want to configure for a proposed change, and select **Proposed Change**.\n\n3.  Complete the form to make the proposed changes, and click **Save Proposed Change**.\n\n    Click **Update** to apply the changes immediately. Click **Delete** to delete the CI.\n\n4.  To propose an addition or a removal of a CI relationship:\n\n    1.  Click the plus icon in the **Related Items** section.\n\n    2.  In the Relationships section, add or delete a relationship.\n\n        For information about using the relationship editor, see [Create or edit a CI relationship](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/servicenow-platform/configuration-management-database-cmdb/t_CreateCIRelationship.md).\n\n    3.  Click **Save Propose Change**.\n\n    4.  Confirm saving the proposed change.\n\n    Click **Update** or **Delete** to commit the changes immediately.\n\n    **Note:** Use only with CI relationships. Proposing additions or removal of relationships is not valid for user relationships and group relationships.\n\n\n### What to do next\n\nAfter the proposed changes are saved, the **Apply Proposed Changes** button appears on the Change Request form. This button lets the user commit the proposed changes to the CI. Your business processes determine the appropriate time to commit the changes. The CI retains the existing data until the proposed changes are committed. However, users can see that changes have been proposed.\n\n## Apply a proposed change to a CI\n\nWhen you apply the proposed changes, all the proposed changes for that change request are applied to the configuration item. You can apply proposed changes without verification, or if verification tests of the proposed changes have failed.\n\n### Before you begin\n\nRole required: sn\\_cmdb\\_editor or itil\n\n### About this task\n\nAfter you apply the proposed changes, the **Scheduled changes** part of the form displays **No scheduled changes found**. You can configure proposed change verification rules which you can use to verify proposed changes before applying the changes.\n\n### Procedure\n\n1.  Navigate to the **Change Request** form.\n\n2.  Click the **Apply Proposed Changes** button.\n\n    You may have to right-click the form header and select the **Reload Form** option to see the changes.\n\n\n## Create or edit a proposed change verification rule\n\nEnsure that proposed changes meet business requirements and do not introduce invalid data to the CMDB, create a rule that includes a script to verify the proposed changes.\n\n### Before you begin\n\nRole required: asset, sn\\_cmdb\\_editor, or itil\n\n### About this task\n\nWhen you configure proposed change verification rules for a CI, you have an option to verify that the proposed changes pass the verification test script in the rule. The verification test results are logged as passed or failed, and you can view the results. Running the verification test is not mandatory, and a failed verification test does not prevent you from applying proposed changes.\n\n### Procedure\n\n1.  Navigate to **All** &gt; **Configuration** &gt; **Change Verification** &gt; **Proposed Change Verification Rules**.\n\n2.  Click **New** or select an existing rule to edit.\n\n3.  Fill in the fields, as appropriate.\n\n<table id=\"table_rsd_rm5_ms\"><thead><tr><th>\n\nField\n\n</th><th>\n\nDescription\n\n</th></tr></thead><tbody><tr><td>\n\nRule name\n\n</td><td>\n\nThe name of this rule.\n\n</td></tr><tr><td>\n\nTable name\n\n</td><td>\n\nThe table to which the rule applies.\n\n</td></tr><tr><td>\n\nFilter condition\n\n</td><td>\n\nConditions to apply this rule to specific CIs.\n\n</td></tr><tr><td>\n\nActive\n\n</td><td>\n\nCheck box to activate this rule.\n\n</td></tr><tr><td>\n\nRule script\n\n</td><td>\n\nA verification Java script that needs to return true or false. For example:\n\n ```\nvalidateRule()\n {\n var os = current.getValue(\"os\");\n var cpu = current.getValue(\"cpu_count\");\n\n    //Use current.getValue(fieldName) to get the proposed change value, eg. var os = current.getValue(\"os\");\n    //Your verification code\n\n if (os != \"SunOS\" || cpu < 2)\n return false;\n     //Return true to pass the verification and false if the verification failed\n return true;\n }\n```\n\n</td></tr></tbody>\n</table>4.  Click **Submit** or **Update**.\n\n\n### Result\n\nOn the **Change Request** form, you can click **Verify Proposed Changes** to verify proposed changes for the affected CIs.\n\n## Verify proposed changes\n\nBefore applying proposed changes to affected CIs, use proposed change verification rules to verify that the changes meet business requirements and do not add invalid data to the CMDB.\n\n### Before you begin\n\nCreate or edit the rules used to verify proposed changes. For details, see [Create or edit a proposed change verification rule](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/servicenow-platform/configuration-management-database-cmdb/c_ProposedChanges.md).\n\nRole required: none\n\n### About this task\n\nYou can apply proposed changes even if they are unverified or fail a verification test.\n\n### Procedure\n\n1.  Open the **Change Request** form that affects the CI.\n\n2.  Click **Verify Proposed Changes**.\n\n    The proposed changes are verified against any proposed change verification rules in which the CI meets the **Filter condition** criteria.\n\n3.  Review the message that appears at the top of the form after the verification process is finished.\n\n    The message states whether the verification tests passed or failed.\n\n\n### What to do next\n\nTo view the details of any verification tests that were performed for the change request in the past two days, click the **Proposed Change Verification Log** related link.\n\n## Create or edit a planned change validation script\n\nCreate a custom script that checks if a change to a class was valid according to business requirements, and whether the change was planned or not. A planned change validation script is used whenever a CI change is viewed in the CI timeline or change history.\n\n### Before you begin\n\nRole required: sn\\_cmdb\\_admin, sn\\_cmdb\\_editor, admin, or itil\n\n### About this task\n\nThe system attempts to validate each CI change as follows:\n\n-   If a custom script exists for the CI or one of the CI parents, then the script is executed and the results are used to flag the change as valid or invalid. Parent CIs are examined in the hierarchical order.\n-   If a custom script does not exist for the CI or any of its parents, then a predefined validation script is used. The change is determined as a planned change if the change occurred between the **Work start** and **Work end** dates of the change request associated with the changed CI.\n\n    However, this check is not always reliable because a user might have manually modified the CI within the work dates, which flags the change as valid even if it is invalid.\n\n\nThe script needs to return a boolean, true or false, which depends on meeting the test criteria in the script. You can define a separate script for each CI class, and you can define multiple planned change validation scripts for a single class. For example, to maintain different versions of the script. Only one script can be active for a CI class at any given time.\n\nThese are the parameters that uniquely characterize a change:\n\n-   The fields that were changed\n-   The data source that performed the change\n-   The time stamp of the change\n\nTo correctly determine the validity of a change, examine the parameters and apply business logic to evaluate if the validation tests are met. A planned change validation script can test any of these characteristics and determine when a change meets pre-established criteria. For example, the custom script can check if the mode of the CI is operational or maintenance, or who initiated the change.\n\n### Procedure\n\n1.  Navigate to **All** &gt; **Configuration** &gt; **Change Verification** &gt; **Planned Change Validation Script**.\n\n2.  Click **New** or select a validation script to edit.\n\n3.  Complete the form.\n\n    |Control|Description|\n    |-------|-----------|\n    |Active|Check box to activate this script for validating changes.|\n    |Applies to|Class that this script applies to.|\n    |Script|Script to run to validate a change. If the script does not return a boolean value, then it is configured to false.|\n\n    The script has a template which displays the input variables of the script.\n\n    |Variable|Type|Description|\n    |--------|----|-----------|\n    |current|GlideRecord|Current record that is being processed.|\n    |updatedOn|GlideDateTime|Time stamp of the change.|\n    |updatedBy|String|Entity responsible for the change.|\n    |fieldsChanged|String|Comma-separated list of the names of all fields that were changed.|\n\n    This sample script checks who initiated the record update. It returns true if sn\\_cmdb\\_admin or admin initiated the record update. Otherwise, the script returns false.\n\n    ```\n    isValidChange();\n     \n    function isValidChange(/*GlideRecord current, GlideDateTime updatedOn, String updatedBy, String changedFields*/) {\n        //Return true if the user that updated the record has an admin role\n        return isUserAdmin(updatedBy);\n    }\n     \n    function isUserAdmin(userName){\n        var grUser = new GlideRecord(\"sys_user\");\n        grUser.addQuery('name', userName);\n        grUser.query();\n        if(grUser.next()) {\n            var roles = new GlideRecord (\"sys_user_has_role\");\n            roles.addActiveQuery();\n            roles.addQuery('user', grUser.sys_id);\n            roles.query();\n            while(roles.next()) {\n                if(roles.role.name == 'sn_cmdb_admin' || roles.role.name == 'admin')\n                    return true;\n            }\n        }\n        return false;\n    }\n    ```\n\n4.  Click **Submit**.\n\n\n**Related topics**  \n\n\n[Timeline of CI changes](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/platform-security/c_HistoryTimeline.md)\n\n"}}