What Is Coalesce in ServiceNow? The Tiny Checkbox That Protects Your Data

BillMartin · Sunday

A tiny checkbox in ServiceNow holds a lot of power over your data strategy. Check it wrong, you get duplicates and broken workflows. Check it right, your imports stay clean and your processes run smoothly. That checkbox is Coalesce.

Coalesce controls whether ServiceNow updates an existing record or creates a new one during an import. It helps you use identity logic, like an employee ID or a serial number, to match incoming data to what already exists. When set up properly, it keeps your CMDB, user tables, and other records consistent and trustworthy.

I’ll walk through a real HR-to-user import using CSV files, show how to set up a Transform Map, and explain how the Coalesce field decides what updates and what gets inserted.

Common pitfalls I see all the time:

Not setting Coalesce on the correct fields
Coalescing on fields that change, which creates duplicates
Skipping Mapping Assist and relying on auto-map alone
Using too many coalesce fields and making matching too strict

Setting Up Your Personal Developer Instance (PDI) for Hands-On Learning

I treat a Personal Developer Instance like a lab. It is safe to try things, make mistakes, and build confidence. If you’re following along, use your PDI so you can practice without touching production data.

Here is a simple path to get into the platform and ready for imports:

Log in to your ServiceNow developer account and request a PDI if you do not have one.
From the PDI home, click Start Building to open the platform.
Confirm you have admin rights in your PDI.
Keep a CSV ready for testing. I used a small HR user list.

Why use a PDI?

You can experiment without worrying about downstream impact. When you see what happens with and without Coalesce, the concept clicks fast. This hands-on time is what turns a feature into a skill.

Step-by-Step: Loading Data into ServiceNow

I started from the Application Navigator and typed “import sets.” This opens System Import Sets where you create a temporary staging table for your file. Think of this staging table as a mirror of your CSV.

To load a simple HR Users CSV:

Go to System Import Sets, then Load Data.
Add a short label, like “HR Users.”
Upload your CSV file.
Choose the correct tab in the file if prompted.
Set the first row as column headers.
Submit and click the Loaded Data link to preview rows.

On the Loaded Data page, I verified that three records were present, each with a unique employee ID, an email, and a few attributes. In my sample, the three users were David, Sara, and Maria. Your file may have many more fields, especially in enterprise HR or CMDB loads. The key is that the staging table captured your source file cleanly.

Previewing Your Imported Data

Open a row from the staging table to confirm the fields you expect are present. You should see your employee ID or other unique field, plus names, emails, and any other attributes. If the source looks wrong here, fix the CSV before moving forward.

Creating and Configuring Transform Maps

After loading the data, I created a Transform Map to move the records from the import set table into the target table. Since I was creating users, the target table was sys_user. I named the map “HR Users v1” so I could create a second version later for an update test.

Auto-map is a good start, but not perfect. ServiceNow tries to match fields with the same names between source and target, which saves time. Still, you will often need to map key fields by hand. This is where Mapping Assist helps. It lets you pick the source field and choose the target field, then set options like Coalesce.

In this example:

Source unique identifier: HR employee ID
Target identity field: User ID (username) in sys_user

I mapped employee ID to the username field and set that mapping to coalesce.

A quick comparison looks like this:

Source field: employee_id
Target field: user_name (sys_user.user_name)
Coalesce: true

The Role of Coalesce in Transform Maps

Coalesce is the identity check. It tells ServiceNow how to match incoming rows to existing records:

If a record exists with the same coalesce field value, update it.
If no match exists, insert a new record.

The purpose is simple and powerful: prevent duplicates. If you import without coalescing on a stable identity field, you risk creating a second Sara and a third Sara, which will break approvals, assignments, and reporting.

Here is a quick view of how field mapping might look:

Field Name	Source Field	Target Field	Coalesce
Employee ID	employee_id	user_name	True
Email	email	email	False
First Name	first_name	first_name	False
Last Name	last_name	last_name	False
Department	department	department	False

I keep Coalesce set only on the field that represents a stable identity. In HR imports, that is often the employee ID mapped to username. Your organization may use a different approach depending on HRIS standards.

Live Demo: First Import and Verifying Results

With “HR Users v1” configured, I ran the transform. The job reported success, and I moved over to the target table to confirm inserts.

To verify:

Open the user list: sys_user.list
Search for user IDs starting with emp (or whatever pattern your file uses)
Confirm the three new rows are present for David, Sara, and Maria

At this point, I had clean inserts based on the v1 file. The coalesce field was set, so the stage was ready for a second test where some records should update instead of insert.

Challenging the System: Handling Updates and New Records

Next, I prepared a second CSV. Two of the rows matched the existing users, and the third was a new employee, Michael Ton from Marketing with an analyst role. The expectation was simple. On import, ServiceNow should update David and Sara, and insert Michael.

I loaded the second file as a new import set and created a new Transform Map called “HR Users v2.” I repeated the same auto-map and Mapping Assist steps, making sure the employee ID mapped to username again with Coalesce set to true. That way, ServiceNow used the same identity logic.

Then I ran the transform.

Expected and observed results:

One update, one insert, one ignored
The update operation matched the existing employees by employee ID
The insert created a new record for Michael
The ignore occurred if a row had no changes from the previous load

To verify:

Open sys_user.list again.
Filter for user IDs starting with emp.
Confirm there are now four records, including Michael.

What Happens Behind the Scenes with Coalesce

ServiceNow scans the target table for matches on fields marked as coalesce. If it finds a record with the same value, it updates that record. If it does not find a match, it inserts a new record. If the incoming data is identical to what is already stored, it may be ignored.

In our HR example, the expected outcome was simple: one update, one insert, one ignored. That is how you keep the user table clean without duplicates.

Real-World Story: Fixing Chaos with Coalesce

At a client site, duplicate users caused chaos. Managers could not approve because the system saw two versions of the same person. Tickets routed to the wrong owner. Reports were off. The fix was not a big migration or a custom script. We corrected the coalesce field on the Transform Map, aligned the identity logic to HR, and the issues cleared up. That is when it hit me. Coalesce is not just a checkbox, it is a safeguard for platform integrity.

Advanced Tips: Using Multiple Coalesce Fields

Some records need more than one field to define identity. In asset management, a laptop might be identified by serial number and asset tag. In those cases, Coalesce can use multiple fields. ServiceNow will only update a record when all coalesce fields match.

Use this with care.

Pros:

Better uniqueness for complex data
Fewer false matches when one field is not stable

Cons:

Stricter matching can create unintended inserts
If one field changes, you might create a duplicate

For example, if you coalesce on employee ID and email, and the email changes, ServiceNow might treat the row as a new person. That is why you should pick fields that stay stable for the full lifecycle.

Questions to ask yourself before setting Coalesce:

Which field represents a true identity over time?
Will this field ever change when the person or asset is the same?
Do I need one field or a combination?
What will break if this field shifts?

Architects think beyond what is unique today. We pick identity rules that stay stable across onboarding, transfers, and terminations, and across updates from discovery or vendor feeds.

Step-by-Step Summary: Clean Imports With Coalesce

Load your CSV into an import set and preview the data.
Create a Transform Map to the correct target table, like sys_user.
Use auto-map, then correct gaps with Mapping Assist.
Set Coalesce on a stable identity field, like employee ID mapped to username.
Run the transform and verify inserts or updates in the target table.
For subsequent loads, keep the same coalesce logic to update existing records and insert only true new ones.

Common Mistakes and How I Avoid Them

Coalescing on a field that changes: I pick employee ID over email for HR.
Not mapping the identity field at all: I always check Mapping Assist before running the first transform.
Using too many coalesce fields: I test with one, then add a second only if needed.
Skipping verification in the target table: I filter by a pattern like emp to confirm the exact changes.

Conclusion: Build Clean Data, Build Strong Systems

That tiny Coalesce checkbox defines identity in your data flows. It affects updates, inserts, workflows, integrations, and dashboards. The next time you set up a Transform Map, ask yourself what identity you are defining. Get that right and you protect every downstream process.

Every great system starts with clean, trusted data. Build yours the right way.