OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow / Practical guide

ServiceNow Data Sources: Govern Authority and Conflicts

ServiceNow data-source governance makes clear which source is authoritative for a field, relationship, or lifecycle event, who owns the meaning, when updates arrive, and what happens when sources disagree. Without that decision, imports can overwrite useful information or preserve conflicting states.

For ServiceNow data owners deciding which source should be trusted for each field, relationship, and lifecycle event..

ServiceNow data sourcesauthoritative sourcesource-of-truth governance
Discuss this ServiceNow topic

Guide map

Deciding which source is authoritative for each field

Define the decision each source supports

When two systems disagree about a field, the source worth trusting is the one closest to the event that changed it.

Assign authority by field and event

When systems disagree about a field, the one with the clearest owner and the most recent update usually earns the right to win.

Manage conflicts and late updates

Decide in advance which source wins when two systems disagree, and what happens when the losing system updates the same field after the decision.

The practical framework

Govern ServiceNow data sources with field authority, ownership, update timing, reconciliation, conflicts, exceptions, evidence, and operational use.

Define the decision each source supports

State the record, field, relationship, process, service, and operational decision that depends on the data. A source can be authoritative for one attribute and merely informative for another. Scope should follow meaning and use.

The ServiceNow CMDB route is the relevant internal destination when configuration data and relationships are involved.

Assign authority by field and event

Record source, owner, update event, timing expectation, transformation, validation, and permitted override. Distinguish automated updates from approved manual corrections, and preserve evidence for both.

The ServiceNow integration route provides an internal path when source systems and transfers need design.

Manage conflicts and late updates

Define how to compare timestamps, authority, lifecycle, evidence, and service consequence. A newer value is not automatically better if it came from a less authoritative source. Record conflict, decision, owner, and correction.

The ServiceNow reconciliation route is relevant when data must be compared and corrected.

Record ownership and exception decisions

An exception should state why the normal source cannot be used, what risk remains, who accepts it, what compensating action exists, and when it will be reviewed. Do not let a temporary override become an unexplained permanent source.

The ServiceNow data-quality route supports evidence review.

Review source fitness when processes change

Revisit source authority after a system, supplier, service, integration, lifecycle, or ownership change. Check records that depend on the source and update rules, documentation, and monitoring where necessary.

For data source governance work, the ServiceNow continuous-improvement route provides the next internal path.

Common questions

Questions teams ask about data sources

Can one source be authoritative for everything?

Usually not. Authority depends on the field, relationship, lifecycle event, process, and decision. The governance record should state the boundary.

What should happen when sources disagree?

Capture both values and evidence, compare authority and timing, assign a decision owner, correct or accept the exception, and record the remaining risk.

The research-grounded boundary

For data source governance, the practical safeguard is to make each dependency visible before anyone treats a field or import as settled. Name the trigger that updates the value, the permitted change, the person who checks it, the signal that shows a failed or conflicting update, and the record that shows the decision was made. Without those five things, a source can look authoritative while nobody can say why it is.

Name the decision each source is trusted to support

Source authority is not a property of a system. It is a property of a field, a relationship or a lifecycle event, and it only means something once a decision depends on it. A hardware feed may be the right authority for the serial number of a laptop and the wrong authority for who currently uses it. An HR feed may decide when an employee leaves but should not decide which applications that person can reach. Begin by listing the decisions the platform makes from imported data, then ask which source each decision should trust. Where the answer is unclear, the field is not ready to be imported automatically.

Keep the list short enough that someone can maintain it. A matrix with a long list of rows that nobody reads is worse than a short matrix that the data owners check each quarter.

An authority matrix that can be checked

Field or eventAuthoritative sourcePermitted overrideTiming expectation
Serial number and model of a deviceAsset management feed from procurementCorrection by the asset custodian with a reason codeUpdated when the device is received or retired
Who uses a deviceDirectory or HR-driven assignmentTemporary assignment by the service desk, expiring after a set periodRefreshed at each directory synchronization
Business service a server supportsService owner’s approved mappingNone from discovery; discovery may propose onlyReviewed at each service change
Employee leaving dateHR system of recordNone by the platform teamSet when the leaving event is approved

The override column is the one that is often left blank. Without it, staff invent workarounds such as editing a field directly and leaving no trace. A permitted override with a reason code and an expiry makes the exception visible and gives the next reviewer something to act on.

A sequence for resolving a conflict between sources

  1. Capture both values, the source that wrote each one, and the time each write occurred.
  2. Check whether the sources have different authority for this field, or whether one is simply more recent. A newer value from a less authoritative source should not overwrite an older authoritative one without a decision.
  3. Confirm the lifecycle state of the record. A value written after a device was retired may be a stale feed rather than a real change.
  4. Assess the service consequence: which incident, change or report would be affected if the wrong value were kept for a week.
  5. Assign a decision owner, record the chosen value and the reason, and set a review point if the choice is provisional.
  6. Where the same conflict recurs, change the source rule, the transform or the timing, rather than resolving it by hand a second time.

How imports overwrite what the business needed

Import sets and transform maps are the usual place where authority is lost. A transform that maps a value on every run, with no check on whether the target was changed elsewhere, will quietly overwrite a correction an analyst made last week. Decide, for each mapped field, whether the import should create a value only when the field is empty, update it only when the source is authoritative, or always update it. Build that choice into the transform and document it, rather than leaving it to the default.

Coalesce keys deserve the same care. If two sources identify the same item by different keys, a poor key choice either merges distinct items or splits one item into two. Test the key with real duplicates before the first full load, and keep the list of rejected matches so a later reviewer can see what was decided and why.

Timing creates a second category of error. A feed that arrives after a decision window closes is not wrong, but it is late, and a decision made on the earlier value may now look like a mistake. Record the timing expectation for each source and check, after each load, whether the data arrived within it.

Where source governance quietly fails

The first failure is the temporary override that never expires. An analyst corrects a field and nobody removes the override when the source is repaired, so the platform keeps a value the authoritative system no longer holds. Give every override an expiry or a review date, and report overrides that have passed it.

The second is authority assumed rather than agreed. Two teams each believe they own the same attribute, and the last import to run wins. A simple test is to ask both owners to name the same authoritative source for one field. Disagreement at that point is cheaper to resolve than an incident later.

The third is reconciliation logic that nobody can explain. When a rule was built years ago by someone who has left, the team keeps running it because nobody dares to change it. Document each rule’s intent and the sources it compares, and review it when either source changes.

The fourth is governance that stops at the platform boundary. A source that is authoritative inside the platform may be fed by a system whose own controls are weak. Ask the custodian of each upstream source how the value is produced, not only whether the feed runs.

What healthy governance looks like

Good source governance shows as fewer manual corrections over time, and as corrections that are explained rather than repeated. Look at the overrides in use and check how many have passed their review point. Look at conflicts logged in the period and check whether the same pair of sources appears repeatedly. A recurring pair means a rule needs changing. Finally, sample a few records that were corrected and check whether a reviewer can see the source, the decision and the owner without asking anyone.

When a source does not need a governance record

A reference list used only to label a dropdown, with no effect on any decision or report, does not need a full authority record. Give it a simple owner and move on. Spending the same effort on every feed dilutes attention from the few sources that drive service decisions.

Frequently asked questions about data source authority

Can one source be authoritative for everything it sends?

Rarely. A source may be authoritative for some fields and only informative for others. Record authority at the level of field and event, not at the level of the feed.

Should the newest value always win?

No. Recency matters, but so does authority and lifecycle state. A newer value from a source with weaker authority should be held for review rather than applied automatically.

What review rhythm keeps the authority matrix accurate?

Trigger a review whenever a source system, supplier, integration or process owner changes, and check for stale entries at a regular interval. Trigger-based review catches most real changes; the interval catches the ones nobody announced.

What is the minimum record for a new feed?

The field list it writes, the authoritative owner for each field, the timing expectation, the permitted overrides and the decision owner for conflicts. A feed without those five items should not go live.

The CMDB ownership model is the companion to this matrix, and the migration reconciliation controls piece shows how a load is checked once authority has been decided.

If imports are overwriting corrections or two teams disagree about which source to trust, bring the fields and feeds in question. Talk through source authority with OBLYTECH. The data governance and source authority page covers which source is authoritative for a field, relationship or lifecycle event, and the data migration and integration page covers moving data from legacy systems into ServiceNow.

A practical next step

Need a clearer ServiceNow operating model?

OBLYTECH can discuss the questions raised by this guide and the next review step. See the ServiceNow consulting services page for the commercial route.

Useful starting pointBring the current question, scope, ownership concerns, and evidence needs into the first review conversation.

Review ServiceNow consulting

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

More from the blog

Related reading