Someone once asked me, "So what is your approach to data mapping?"
The honest answer is this: it feels a bit like being a translator on a safari. You are surrounded by systems that do not speak the same language, everyone is convinced they are right, and your job is to get them all safely to the same destination without losing anyone along the way.
At its heart, data mapping is not just a technical exercise. It is about structure, communication, and trust. You are taking data from a source system and making it fit cleanly into another platform, often ServiceNow. On paper that sounds simple. In reality, both systems have very strong opinions about what something as simple as "Name" should look like.
Over the years, here is how I have learned to approach it with clients.
1. Start with the terrain: understand the source data structure
Before I touch a single integration, I want to understand the "terrain" of the source system.
For each important field, I ask very basic but critical questions:
- What is the field name?
- What type of field is it: text, number, date, selection list, etc.?
- Are there constraints: 25 characters max, required vs optional, specific format?
- If it is a selection field, what are the allowed values?
If a client tells me they have a "Name" field, that could mean:
- A simple text field with 50 characters
- A code that represents a person or location
- A concatenated value that includes multiple pieces of information
I also ask whether the target ServiceNow table already has an appropriate field. If it does, great. If it does not, we may need to extend the table and create a custom field, so the mapping is clean and sustainable.
Good data mapping starts with respect for the source structure. If you skip this step, you are guessing, not designing.
2. Decode the mysteries in the data
Real data rarely comes in neat columns. One of my favorite examples is a client who had a field they called "description long field."
Inside that single field were three different values separated by commas. For example:
ABC123,NYC01,PRIORITY2
To that client, those codes meant something very specific: maybe a location, an internal identifier, and a priority. ServiceNow users, however, should not have to decode that every time they look at a record.
So we had two choices:
- Keep it as one field and simply copy it into ServiceNow, or
- Break that one field into three separate, clearly named fields in ServiceNow so it reads like real information, not a puzzle.
Most of the time, the right answer is the second one. But that decision has to come from the client. My job is to ask:
- What do these values actually mean?
- How do your users need to see this in ServiceNow?
- Do we keep the original code for audit, or do we transform it into something friendlier?
A big part of data mapping is acting as the interpreter who turns comma-delimited chaos into fields that a front line user can trust and understand.
3. Direction and timing: how and when data will move
Once we know what the data looks like, we decide how it will move.
There are two big questions here:
- Is this unidirectional or bidirectional? Unidirectional: the source system sends data into ServiceNow, and ServiceNow does not write back. Bidirectional: ServiceNow is allowed to update records back in the source system.
- Is it real time or batch? Real time: updates flow as soon as they happen. Batch: data moves on a schedule, for example nightly or every few hours.
These decisions are not just technical, they are governance decisions.
If we choose bidirectional, that opens up questions like:
- What happens if someone updates the same field in both systems at nearly the same time?
- Who wins if the values conflict?
- If ServiceNow tries to write back and the source system rejects the update, how do we detect that and who gets notified?
If we choose batch, we then ask:
- How fresh does the data need to be for your business to operate?
- Is once a day enough, or do your teams need something closer to real time?
These conversations prevent painful surprises later.
4. Design the plumbing the right way
Once the business rules are clear, we get into the plumbing.
Typical questions I walk clients through:
- Do we need a MID Server so ServiceNow can securely talk to systems inside your network, instead of opening everything directly to the internet?
- Is there an existing ServiceNow Integration Spoke for this system that we can leverage, or do we need to build a custom integration using REST or SOAP APIs?
- Are we using direct API calls, webhooks, or a web server that brokers access and limits what ServiceNow can see?
- What are the authentication and security requirements on the client side, and how do those map to ServiceNow connection and credential records?
Security is not a bolt-on. It touches everything:
- Credentials need to be stored and rotated correctly.
- Calls from ServiceNow need to obey firewall and network policies.
- The integration must only see and update the data it is actually supposed to touch.
Good plumbing is invisible when it works, but it is critical for both security and reliability.
5. Decide the source of truth and plan for conflict
This is where many integrations either succeed or quietly create chaos.
If data can be changed in more than one place, you must answer:
- Which system is the system of record for each field?
- Under what conditions is ServiceNow allowed to overwrite the source system, or vice versa?
- How do we handle simultaneous changes?
For example, imagine your name exists in both systems.
- A user in ServiceNow updates your record to add your middle name.
- At nearly the same time, someone in the source system edits your name and removes the middle name.
- The integration runs and both systems send updates.
If we do not define the source of truth, the last update that "wins" is essentially random. Someone will feel like they did the right thing and then watch their change disappear on the next sync.
So in my designs we explicitly document:
- For this field, System A is the source of truth.
- For that field, ServiceNow is allowed to overwrite the source.
- In case of conflict, here is the rule we apply.
Then we build those rules into the integration so it behaves predictably.
6. Plan for errors, not perfection
No matter how well you design an integration, something will eventually go wrong:
- The source system is down.
- An update fails validation on the other side.
- A new value appears that no one planned for.
Part of a mature data mapping approach is deciding:
- How do we detect integration failures?
- Where do we log them?
- Who gets notified?
- What is the process to correct bad data or rerun the integration?
Data mapping is not just about the happy path. It is about making sure that when something breaks, you know it, you understand why, and you can fix it without destroying trust in the data.
Bringing it all together
To me, data mapping is not about moving data from Point A to Point B.
It is about designing trust between systems and the people who depend on them.
You start by respecting the structure of the source. You translate that into a clean, usable model in ServiceNow. You decide how data will flow, who gets the final say when values conflict, and how you will keep the integration secure and reliable over time.
Tim Berners-Lee once said, "Data is a precious thing and will last longer than the systems themselves." I agree. The systems will change. The platforms will be upgraded, swapped, or replaced. But if you design your data mapping thoughtfully, the integrity of that data can carry forward.
Without good data mapping, you are not really integrating. You are just rearranging confusion.
If you are looking at a new ServiceNow integration and wondering how to tame your own data safari, I am always happy to compare maps.
Join the conversation
Share a question, experience, or perspective on this article.