---
sourceDocument: Australia ServiceNow AI Platform Capabilities
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/de-DE/servicenow-platform

 Release :

    - australia

ft:locale :

    - de-DE

ft:publication_title :

    - Australia ServiceNow AI Platform Capabilities

ft:clusterId :

    - platcap

bundleId :

    - platcap

workflow :

    - Platform


---

# Managing proposed changes

# Managing proposed changes {#ariaid-title1}

* Freigeben Version: Australia
* 
* Aktualisiert 12. März 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 8 Minuten Lesedauer

The 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.
When you view a CI, the proposed changes can be displayed so that you can see what is
planned.

This 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.

You can make the following proposed changes to a CI:

* Modify any field on the CI form.
* Add or delete a relationship to that CI.

{#c_ProposedChanges__ul_gnm_4nr_dr}

To modify a relationship, you must delete the current relationship and add a new relationship.
You cannot delete a proposed change.

## View CI history {#c_ProposedChanges__section_mvs_t3g_xz}

You can view the history of changes to a CI in a list, calendar, or timeline format.

## View the proposed changes of a CI {#ariaid-title2}

You can view the proposed changes so that you can see what is planned for the
CI.

### Vorbereitungen

Role required: personalize_form

### Warum und wann dieser Vorgang ausgeführt wird

To 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.

### Prozedur

1. Navigate to AllChangeOpen and open a change request.
2. In the Affected CIs related list, open the Configuration Item.  
   You may also navigate directly to the CI form.
3. Right-click the form header bar.
4. Select ConfigureForm Layout.
5. Move the CMDB Scheduled Changes field to the Selected pane.
6. Click Save.  
   The CI form shows the details of any proposed changes in the Scheduled changes area.

## Add a proposed change to a CI {#ariaid-title3}

Proposed changes to a CI can be made while viewing a change request or any
task-related record.

### Vorbereitungen

Role required: sn_cmdb_editor or itil

### Prozedur

1. In the Change Request form, go to the Affected CIs related list.  
   If there are no CIs in the Affected CIs list, click Edit to add CIs that are affected by this change request.
2. Right-click the CI that you want to configure for a proposed change, and select Proposed Change.
3. Complete the form to make the proposed changes, and click Save Proposed Change.  
   Click Update to apply the changes immediately. Click Delete to delete the CI.
4. To propose an addition or a removal of a CI relationship:
   1. Click the plus icon in the Related Items section.
   2. In the Relationships section, add or delete a relationship.  
      For information about using the relationship editor, see [Create or edit a CI relationship](https://servicenow-prod.fluidtopics.net/0_XqY0aRzUO8P9n9BQCSDw "Use the relationship editor to view, create, or modify CI relationships. You can open the relationship editor from the CI Relations formatter.").
   3. Click Save Propose Change.
   4. Confirm saving the proposed change.

   {#t_AddAProposedChange__substeps_xhv_4g5_dbb}  
   Click Update or Delete to commit the changes immediately.  
   Hinweis:  
   Use only with CI relationships. Proposing additions or removal of relationships is not valid for user relationships and group relationships.

### Nächste Maßnahme

After 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.

## Apply a proposed change to a CI {#ariaid-title4}

When 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.

### Vorbereitungen

Role required: sn_cmdb_editor or itil

### Warum und wann dieser Vorgang ausgeführt wird

After 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.

### Prozedur

1. Navigate to the Change Request form.
2. Click the Apply Proposed Changes button.  
   You may have to right-click the form header and select the Reload Form option to see the changes.

## Create or edit a proposed change verification rule {#ariaid-title5}

Ensure 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.

### Vorbereitungen

Role required: asset, sn_cmdb_editor, or itil

### Warum und wann dieser Vorgang ausgeführt wird

When 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.

### Prozedur

1. Navigate to AllConfigurationChange VerificationProposed Change Verification Rules.
2. Click New or select an existing rule to edit.
3. Fill in the fields, as appropriate.  
   {#t_CreatPropChngVerifiRule__table_rsd_rm5_ms__entry__2}

   | Field | Description |
   |-|-|
   | Rule name | The name of this rule. |
   | Table name | The table to which the rule applies. |
   | Filter condition | Conditions to apply this rule to specific CIs. |
   | Active | Check box to activate this rule. |
   | Rule script | A verification Java script that needs to return true or false. For example: validateRule() { var os = current.getValue("os"); var cpu = current.getValue("cpu_count"); //Use current.getValue(fieldName) to get the proposed change value, eg. var os = current.getValue("os"); //Your verification code if (os != "SunOS" || cpu < 2) return false; //Return true to pass the verification and false if the verification failed return true; } |
   [Tabelle : 1. Proposed Change Verification Rules form]

   {#t_CreatPropChngVerifiRule__table_rsd_rm5_ms}
4. Click Submit or Update.

### Ergebnisse

On the Change Request form, you can click Verify Proposed Changes to verify proposed changes for the affected
CIs.

## Verify proposed changes {#ariaid-title6}

Before 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.

### Vorbereitungen

Create or edit the rules used to verify proposed changes. For details, see [Create or edit a proposed change verification rule](https://servicenow-prod.fluidtopics.net/gXqx~p9109u4kWYJWlr1aQ#t_CreatPropChngVerifiRule "Ensure 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.").

Role required: none

### Warum und wann dieser Vorgang ausgeführt wird

You can apply proposed changes even if they are unverified or fail a verification
test.

### Prozedur

1. Open the Change Request form that affects the CI.
2. Click Verify Proposed Changes.  
   The proposed changes are verified against any proposed change verification rules in which the CI meets the Filter condition criteria.
3. Review the message that appears at the top of the form after the verification process is finished.  
   The message states whether the verification tests passed or failed.

### Nächste Maßnahme

To 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.

## Create or edit a planned change validation script {#ariaid-title7}

Create 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.

### Vorbereitungen

Role required: sn_cmdb_admin, sn_cmdb_editor, admin, or itil

### Warum und wann dieser Vorgang ausgeführt wird

The system attempts to validate each CI change as follows:  
* 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.
* 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.

  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.
{#t_CreatePlanChngValidScript__ul_g3w_ycm_zs}

The 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.

These are the parameters that uniquely characterize a change:  
* The fields that were changed
* The data source that performed the change
* The time stamp of the change
{#t_CreatePlanChngValidScript__ul_uv4_4cm_zs}

To 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.

### Prozedur

1. Navigate to AllConfigurationChange VerificationPlanned Change Validation Script.
2. Click New or select a validation script to edit.
3. Complete the form.  
   {#t_CreatePlanChngValidScript__table_qlq_313_ts__entry__2}

   | Control | Description |
   |-|-|
   | Active | Check box to activate this script for validating changes. |
   | Applies to | Class that this script applies to. |
   | Script | Script to run to validate a change. If the script does not return a boolean value, then it is configured to false. |
   [Tabelle : 2. Planned change validation script form]

   {#t_CreatePlanChngValidScript__table_qlq_313_ts}  
   The script has a template which displays the input variables of the script.{#t_CreatePlanChngValidScript__table_ufr_kzh_ts__entry__3}

   | Variable | Type | Description |
   |-|-|-|
   | current | GlideRecord | Current record that is being processed. |
   | updatedOn | GlideDateTime | Time stamp of the change. |
   | updatedBy | String | Entity responsible for the change. |
   | fieldsChanged | String | Comma-separated list of the names of all fields that were changed. |
   [Tabelle : 3. Template script input variables]

   {#t_CreatePlanChngValidScript__table_ufr_kzh_ts}  
   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.

       isValidChange();
        
       function isValidChange(/*GlideRecord current, GlideDateTime updatedOn, String updatedBy, String changedFields*/) {
           //Return true if the user that updated the record has an admin role
           return isUserAdmin(updatedBy);
       }
        
       function isUserAdmin(userName){
           var grUser = new GlideRecord("sys_user");
           grUser.addQuery('name', userName);
           grUser.query();
           if(grUser.next()) {
               var roles = new GlideRecord ("sys_user_has_role");
               roles.addActiveQuery();
               roles.addQuery('user', grUser.sys_id);
               roles.query();
               while(roles.next()) {
                   if(roles.role.name == 'sn_cmdb_admin' || roles.role.name == 'admin')
                       return true;
               }
           }
           return false;
       }

4. Click Submit.
**Zugehörige Informationen**   

* [Timeline of CI changes](https://www.servicenow.com/docs/access?context=c_HistoryTimeline&version=australia&pubname=australia-platform-security&ft:locale=en-US)