Designing data merge workflows for Master Data Management

Designing data merge workflows for Master Data Management

Designing data merge workflows for Master Data Management

Designing data merge workflows for Master Data Management

I designed a core workflow within an enterprise Master Data Management product to help Data Stewards merge duplicate records into a single trusted Golden Record.

I designed a core workflow within an enterprise Master Data Management product to help Data Stewards merge duplicate records into a single trusted Golden Record.

Duration

Jul-Oct, 2025

Jul-Oct, 2025

Client

Lumina Blooms

Lumina Blooms

Services

Lumina Blooms

Lumina Blooms

Lumina Blooms

Lumina Blooms

01 · Context

About the project

About the project

This project was part of a larger Master Data Management (MDM) transformation initiative for a Fortune 500 B2B SaaS client. The organisation brought us in to build a new, internal MDM tool on the ServiceNow Platform.

The project involved reviewing and modifying several existing workflows for the primary users, known as Data Stewards. We were developing this new experience on the ServiceNow platform, so most of the new workflows were designed to leverage the capabilities of ServiceNow Workspace. All but one.

02 · The Problem

Three problems compounding into one broken experience.

Before sketching a single screen, I mapped out what was actually broken, not just the surface symptoms, but the structural reasons why the existing experience couldn't be improved incrementally. The problems were layered and mutually reinforcing.

01 · Legacy tooling

01 · Legacy tooling

Scattered across too many systems

Stewards toggled between the legacy MDM tool, ServiceNow Workspace, external sources to evaluate a single merge. Each switch broke focus and cost time.

02 · Platform ceiling

ServiceNow couldn't support the logic

The rest of the MDM system would live in ServiceNow Workspace, but it was only able for for simple, single-field merges. We had to design for a new multi-relational data model.

03 · A new data model

The schema was changing underneath us

We were replacing the flat schema with a new layered model, introducing parent-child relationships between records. A merge now meant reconciling entire hierarchies of connected data across related tables.

The pre-existing merge workflow required switching between at least three separate systems

03 · Understanding the Data

Understanding what changed in the data and how it would affect our proposed solution

The move from a flat schema to a layered one fundamentally altered what a merge involved and what the interface needed to do. Understanding this shift was foundational to every design decision that followed.

Before - Flat model

Everything in a single table

  1. A merge meant picking one full record as the "winner" with no field-level selection

  1. Every record was a peer to every other

  1. Data stored as plain text strings, no typed references or linkable IDs

  1. No visibility into survivorship scoring

  1. No data lineage

After - Multi-layered model

Choose each attribute and child record

  1. Merges operate at the field level so each attribute can be sourced from any record

  1. Merges must account for all children

  1. Parent and child records explicitly linked via typed references

  1. Every field carries a survivorship score

  1. Full data lineage

A transition from flat merges to a layered data model, introducing new decision points around related records.

04 · Discovery

04 · Discovery

Learning to think like a data steward.

Enterprise data management is a domain with its own logic and its own language. I couldn't design a good merge experience without understanding the world of the data steward. I needed to understand how stewards made decisions, what questions they were actually asking when they looked at two records, what "correct" even meant in this context.

Process walkthrough sessions with data stewards

  • I sat with stewards and asked them to narrate their merge workflow to understand their mental model.


  • What information did they need, in what order, and what were they afraid of getting wrong?

  • I sat with stewards and asked them to narrate their merge workflow to understand their mental model.


  • What information did they need, in what order, and what were they afraid of getting wrong?

Working sessions with the data architects

  • Multiple sessions with data architects so they could walk me through the new layered schema, how survivorship rules were calculated, and how parent-child relationships would behave during a merge.

  • These conversations directly shaped design decisions.

  • Multiple sessions with data architects so they could walk me through the new layered schema, how survivorship rules were calculated, and how parent-child relationships would behave during a merge.

  • These conversations directly shaped design decisions.

Desk research and upskilling

  • I completed a MDM cert and spent time reading through data management documentation, papers on survivorship logic, and case studies.

  • It was important for me to reach a level of fluency where I could participate in technical conversations, push back on constraints, and make informed design decisions.

  • I completed a MDM cert and spent time reading through data management documentation, papers on survivorship logic, and case studies from comparable implementations.

  • It was important for me to reach a level of fluency where I could participate in technical conversations, push back on constraints, and make informed design decisions.

Weekly sessions with stakeholders and stewards

  • With the wider MDM programme constantly shifting scope and focus, I ran weekly sessions with both stakeholders and data stewards throughout the project.

  • Keeping both groups in the room so they were seeing the same designs, hearing the same decisions, meant fewer surprises, faster sign-off, and a process that felt collaborative.

  • With the wider MDM programme constantly shifting scope and focus, I ran weekly sessions with both stakeholders and data stewards throughout the project.

  • Keeping both groups in the room so they were seeing the same designs, hearing the same decisions, meant fewer surprises, faster sign-off, and a process that felt collaborative.

Process walkthrough sessions with data stewards

  • I sat with stewards and asked them to narrate their merge workflow to understand their mental model.


  • What information did they need, in what order, and what were they afraid of getting wrong?

Working sessions with the data architects

  • Multiple sessions with data architects so they could walk me through the new layered schema, how survivorship rules were calculated, and how parent-child relationships would behave during a merge.

  • These conversations directly shaped design decisions.

Desk research and upskilling

  • I completed a MDM cert and spent time reading through data management documentation, papers on survivorship logic, and case studies.

  • It was important for me to reach a level of fluency where I could participate in technical conversations, push back on constraints, and make informed design decisions.

Weekly sessions with stakeholders and stewards

  • With the wider MDM programme constantly shifting scope and focus, I ran weekly sessions with both stakeholders and data stewards throughout the project.

  • Keeping both groups in the room so they were seeing the same designs, hearing the same decisions, meant fewer surprises, faster sign-off, and a process that felt collaborative.

05 · The People

Voices from research

"I have four tabs open just to complete one merge. It shouldn't be this complicated."

"I have four tabs open just to complete one merge. It shouldn't be this complicated."

"I have four tabs open just to complete one merge. It shouldn't be this complicated."

Data Steward 1

"I'm never really sure if I'm picking the right record. I just go with my gut and hope someone doesn't call."

"I'm never really sure if I'm picking the right record. I just go with my gut and hope someone doesn't call."

"I'm never really sure if I'm picking the right record. I just go with my gut and hope someone doesn't call."

Data Steward 2

"The backlog keeps growing because the process is so slow. It feels like I'm falling further behind every day."

"The backlog keeps growing because the process is so slow. It feels like I'm falling further behind every day."

Data Steward 3

"I am kind of worried about this new system, What does "bringing chid records across" mean? Will it take longer to merge records?"

"I am kind of worried about this new system, What does "bringing chid records across" mean? Will it take longer to merge records?"

Data Steward 4

The data steward persona

The data steward persona was built from walkthrough sessions and used across the full MDM programme, not just the merge experience. It gave the wider team a shared reference point for steward needs, behaviours, and the points in the process we had to focus on when building the new experience.

The data steward persona built from walkthrough sessions and used across the full MDM programme.

06 · Design Principles

Taking my learnings and creating a strategy around them

Based on my discovery phase, watching stewards work and spending time with architects, I came up with the following principles to follow, so I addressed the stewards' concerns while sticking to the requirements.

Principle 01

Bring the right decision forward

A steward reviewing 200 fields doesn't need to see 200 fields. They need to see the fields where values actually differ. Everything else is noise. The interface had to allow for the filtering of content that doesn't need to be reviewed.

Principle 02

Make the system's logic visible

The MDM engine uses survivorship rules to calculate which field values are most likely to be correct based on source system priority, field completeness, and recency scores. Stewards should see WHY a suggestion was being made so they could choose confidently.

Principle 03

Keep them informed, not overwhelmed

A clear structure, visible progress, and the ability to step back without losing work. Stewards needed to know where they were and feel in control of where they were going, Aand what they were choosing.

Principle 04

Steward override is always the final word

Even with automated survivorship scoring, stewards bring contextual knowledge that no algorithm can replicate. The design had to make overriding the system's suggestion feel easy and show them that they are the ones in charge.

08 · The Solution

08 · The Solution

A custom portal, connected to the main experience but built for merges.

The decision to build a separate portal rather than extending ServiceNow's native capabilities was one of the most significant calls on the project. It was the right call, but it came with real constraints. The portal had to feel like a natural extension of the ServiceNow workflow where the stewards arrive from a task in Workspace, complete the merge, and return when done.

The new service blueprint mapping steward actions, system behaviour and the Merge Portal

Step 01

Present the recommended record upfront and provide an option to override.

The MDM engine has already calculated a survivorship score for every record and recommended the strongest candidate as the Surviving Record, this is the base from which the Golden Record will be built. The steward's job here is to verify that the right records are included before anything else begins.

Step 02

Building the Golden Record, attribute by attribute.

This is the core of the merge and the step that took the most design iterations. All records sit side by side, with the MDM engine pre-selecting a value for each field based on survivorship scoring. The steward reviews, confirms, or overrides each one.

The first version showed all fields at once, but stewards spent most of their time scrolling past rows where they didn't need to review. The conflict filter collapsed those rows and surfaced only the fields that actually needed a decision. In a typical merge, that reduced 26 visible rows to 11 or 12.

Step 03

Reviewing and selecting related child records.

This is where the new data schema had the most influence. Stewards had to actively choose which child records to come across. The related tables sidebar shows every child dataset in the merge. Stewards move between them, reviewing records from each source and deciding what to include in the Golden Record.

Step 04

Confirming the merge and creating the Golden Record.

Everything the steward has decided is laid out in one place before anything is committed. The master record, the selected attributes with their survivorship scores, the child records across every dataset, and a breakdown of system defaults versus steward overrides. If anything needs changing, they can step back without losing their other selections. When they're satisfied, they submit, and the Golden Record is created.