OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow data governance practice

ServiceNow data governance and source authority for fewer conflicts

ServiceNow data governance and source authority 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.

Discuss ServiceNow data governance and source authority

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 rather than the name of the source system.

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. Authority is a decision about meaning, not simply a technical connection.

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. Capture competing values, decision owner, correction and remaining uncertainty.

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.

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. A source decision remains useful only while its operational meaning remains true.

For configuration relationships, see ServiceNow CMDB, CSDM and ITAM. For integration decisions, review ServiceNow IntegrationHub and API Automation. For control evidence, see ServiceNow risk assessment and control testing.

Discuss ServiceNow data governance and source authority

Bring one field, relationship or integration where ownership, timing or conflicting values are unclear. OBLYTECH can help define authority, exception handling, evidence and review.

Start the conversation

Choosing the decision a source must support

Authority is easiest to define working backwards from the decision that depends on a value. A value used to route an incident, one used to calculate a license position and one shown to a service owner on a dashboard may come from the same field, yet each deserves different authority because a wrong answer has a different consequence. Begin with a short list of the decisions the platform must support, rank them by consequence, and then assign authority for the fields each decision needs. This avoids a common outcome in which one discovery tool is declared authoritative for everything simply because it is the most connected system in the estate.

An authority matrix for the fields that matter

Field or relationshipDecision it supportsAuthoritative sourcePermitted override
Owning group of a serviceWho receives escalation during an outageThe service owner recorded through the service governance processOnly the service owner, with a dated reason
Installed software version on a serverWhether a reported vulnerability appliesDiscovery observation, confirmed against the deployment record where the two disagreeA patch team correction that cites the deployment record
Contract end date for a supplierRenewal timing and license positionThe contract register held by the procurement functionProcurement only, through its own change control
Employee managerApproval routing and periodic access reviewsThe HR system of record, synchronized on an agreed scheduleNone inside the platform; corrections return to the source

The matrix shows the shape a working document should take. The real rows come from the platform’s own data model and from the decisions the business has agreed to support, so they should not be copied from a template.

What to do when two sources disagree about one field

A disagreement is not a data defect until someone has decided which value governs. The working method is to compare the candidate values on four points: which source is authoritative for this field, when each value was last confirmed, whether each value passed the validation the field requires, and what the service consequence would be if the chosen value were wrong. A newer value from a less authoritative source should not win by default. The decision, its owner and the remaining uncertainty belong in the record, so the next reviewer does not reopen the question from the beginning. The ServiceNow CMDB ownership model page covers ownership of configuration data.

Some disagreements cannot be settled by rules at all. Two teams may legitimately describe the same application differently, one by the business capability it supports and one by the technical components it runs on. In those cases the right output is often two correctly named relationships, not one forced value.

A worked pattern: the owner who has left the organization

Consider a configuration item whose named owner no longer works in the organization, while discovery continues to report activity on it. The owner field is stale, the activity is real, and the escalation route points at nobody. A sound response has four parts. The item is flagged as lacking a valid owner rather than quietly reassigned. The team that depends on it nominates a successor with a stated reason. Discovery activity is treated as evidence that the item is alive, not as proof of who is responsible for it. The exception is recorded with a review date, so the gap stays visible until someone accepts it. A temporary owner assigned without that record tends to become permanent without anyone deciding so.

Relationships need authority too

Authority is usually discussed for fields, but relationships carry as much operational meaning. A link between a service and the hosts that run it can be correct for one purpose and misleading for another. A useful habit is to record, for each relationship type, what the link is claimed to mean, which source may create it, which source may delete it, and what a reader should conclude when the link is missing. A missing link is often more dangerous than a wrong one, because it removes the service from impact analysis without raising any alarm. Recording the meaning of an absent relationship is therefore part of the authority decision, not an afterthought.

Stewardship roles and their limits

Source authority depends on people willing to refuse changes that would damage the meaning of a field. Stewardship usually takes three forms. A business owner decides what a field means and which values are permitted. A technical owner controls how values enter and leave the platform. A steward checks quality against the source on a regular cycle and raises exceptions. The three roles should be named for each important field, even where one person holds two of them. Without that naming, a validation rule added during a build can change the meaning of a field that a finance report depends on, and nobody with authority over the report hears about it.

  • Business owner: accepts the definition, the permitted values and the consequence of error.
  • Technical owner: controls the mapping, the update schedule and the rules that reject or transform incoming values.
  • Steward: samples the field against its source on the agreed cycle and logs the exceptions.

Reviewing authority when the operating situation changes

A source decision describes an operating situation, and when that situation changes the decision can stop being true without anyone noticing. A reorganization, a supplier change, a new integration that writes to a field previously read-only, and a retired system that still sends updates are the common triggers. A review should check the records that depend on the field, the rules that protect it and the monitoring that would show drift. It should also retire any exception accepted for a reason that no longer applies, and close the gap between what the matrix says and what the platform actually does.

Questions a buyer should ask about source authority

Can one system be authoritative for everything?

Rarely. A provider who proposes it should explain how the values in other systems would be handled when they legitimately differ. A single authoritative system can be the right answer for a narrow set of fields, but it is seldom right for ownership, usage or financial attributes.

How often should authority be reviewed?

On a fixed cycle for the fields that drive high-consequence decisions, and on any change event for the rest. A cycle without change triggers misses the reorganization that happens between two scheduled reviews.

What should an exception leave behind?

The reason the normal source could not be used, the residual risk, the person who accepted it, the compensating check and the date it will be reviewed. An exception missing any of those becomes a silent override.

What this section leaves out

This section does not select a master data tool, define a full enterprise data model or set quality thresholds for a particular estate. Those depend on the data the organization already holds, the systems feeding the platform and the decisions it supports.

If a field keeps changing without a named owner, the useful unit of work is one field, the decision that relies on it and the names of the people who currently disagree about its value. That can be described through the contact page.

ServiceNow guides on this topic

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

Related guides

More in this section