Who Really Changed My Assignment?

Objective

In this Case File, you'll build four different ServiceNow platform components that all interact with the same field.

Each component appears to influence the Assigned To value, but only one ultimately determines what is written to the database.

By the end of this investigation, you'll understand why users sometimes insist "That's not what I entered!" even though ServiceNow is behaving exactly as designed.

Difficulty

Intermediate

Estimated Time: 30–45 minutes

Skills Practiced

• Client Scripts
• UI Policies
• Data Policies
• Business Rules
• Order of Execution
• Client vs. Server Processing
• Troubleshooting Record Updates

Lab Overview

Throughout this exercise you'll repeatedly edit the same Incident record.

Each experiment introduces one additional platform component while leaving the previous ones enabled.

Before every save, predict what you think ServiceNow will do and then compare your prediction to what actually happened.

Prerequisites

Before beginning, ensure you have:

• A Personal Developer Instance (PDI)
• The admin role
• Access to create Client Scripts, UI Policies, Data Policies, and Business Rules

Starting Environment

Locate or create an Incident.

For consistency, use the following values.

We'll return this record to its original state between each experiment.

Experiment 1 — Client Script

Step 1 — Create the Client Script

Navigate to:

System Definition → Client Scripts

Select New.

Configure the Client Script.

Leave every other setting at its default value.

Replace the generated script with:

function onChange(control, oldValue, newValue, isLoading, isTemplate) {

    if (isLoading) {
        return;
    }

    g_form.setMandatory('assigned_to', true);

}

Save the Client Script.

Why These Settings?

Type = onChange

The script executes immediately after the user changes the Assigned To field.

Using onLoad or onSubmit would produce different behavior and wouldn't demonstrate this scenario.

Verify Your Configuration

Open the Incident.

Change Assigned To.

A red mandatory indicator should immediately appear beside the field.

If it does, the Client Script is working correctly.

Test

Change:

Assigned To

from

Abel Tuter

to

Beth Anglin

Submit the Incident.

Verify Your Results

After saving:

Observation

The Client Script only modified the browser.

It never changed the value submitted to the server.

Reset

Return the Incident to:

Assigned To = Abel Tuter

Experiment 2 — UI Policy

Leave the Client Script enabled.

Step 1 — Create the UI Policy

Navigate to:

System UI → UI Policies

Create a new UI Policy.

Create the following condition.

Save the UI Policy.

Step 2 — Create the UI Policy Action

Create one UI Policy Action.

Save.

Why These Settings?

The UI Policy executes after the field changes.

Although the field becomes read-only, the user's new value already exists in the browser and will still be submitted.

Prediction

Before clicking Submit, answer this question.

Will making the field read-only prevent Beth Anglin from being saved?

Write down your answer before testing.

Test

Change:

Assigned To

from

Abel Tuter

to

Beth Anglin

Submit.

Verify Your Results

Observation

UI Policies only affect the user interface.

They don't rewrite data that's already waiting to be submitted.

Reset

Return the Incident to:

Assigned To = Abel Tuter

Experiment 3 — Data Policy

Leave both previous components enabled.

Step 1 — Create the Data Policy

Navigate to:

System Policy → Data Policies

Create a new Data Policy.

Save.

Step 2 — Create the Data Policy Rule

Create one Data Policy Rule.

Save.

Why This Matters

Unlike Client Scripts and UI Policies, Data Policies execute on the server.

However, they validate data.

They don't replace field values.

Prediction

Will adding a Data Policy change the saved value?

Or will it simply verify the field contains data?

Test

Assign the Incident to:

Beth Anglin

Submit.

Verify Your Results

Observation

Nothing changed.

The Data Policy confirmed the field contained a value and allowed the update to continue.

Reset

Return the Incident to:

Assigned To = Abel Tuter

Experiment 4 — Before Business Rule

Leave every previous configuration enabled.

Step 1 — Create the Business Rule

Navigate to:

System Definition → Business Rules

Select New.

Configure the Business Rule.

Replace the script with:

(function executeRule(current, previous) {

    current.assigned_to = gs.getUserID();

})(current, previous);

Save.

Why These Settings?

When = Before

The Business Rule must execute before the database update occurs.

If this were an After Business Rule, the user's value would already be saved and this experiment wouldn't demonstrate execution order.

Order = 100

This ensures the rule executes early in the Before Business Rule phase while keeping the configuration simple.

Final Prediction

Everything is now enabled.

• Client Script
• UI Policy
• Data Policy
• Before Business Rule

When you submit the Incident...

Who wins?

• Beth Anglin?
• The logged-in user?
• Something else?

Commit to an answer before testing.

Test

Change:

Assigned To

from

Abel Tuter

to

Beth Anglin

Submit.

Verify Your Results

What Happened?

Although the browser submitted Beth Anglin, the Before Business Rule executed on the server before the database update.

The Business Rule replaced the incoming value with the currently logged-in user.

The Data Policy then verified that the field contained a value, so validation passed.

The database never stored the value entered by the user.

Challenge

Disable only the Business Rule.

Leave everything else enabled.

Without changing anything else:

• What value will be saved?
• Why?
• Which platform component now determines the outcome?

Test your answer before moving on.

Key Takeaways

• Client Scripts execute in the browser.
• UI Policies modify the user interface but don't change database values.
• Data Policies validate incoming data on the server.
• Before Business Rules can overwrite incoming values before the database update occurs.
• The final database value is determined by the last server-side process that modifies the record before it is written.

Why This Matters

This lab used a single Incident and one field so the platform's behavior was easy to observe.

Now imagine a production environment where a record is affected by multiple Client Scripts, UI Policies, Flows, Business Rules, Script Includes, and Data Policies.

When users report, "ServiceNow changed my data," the platform is almost never acting randomly.

Understanding where each component executes—and which ones still have the ability to modify a record before it's written—is one of the most valuable troubleshooting skills a ServiceNow administrator can develop.