Decide which system owns each workflow field

Start with the correction that must survive

A coordinator corrects a customer’s contact preference in an intake app. Later, a scheduling tool sends its older copy back, and the correction disappears. Both screens can now look reasonable while the team acts on the wrong preference. Before connecting them, write down which tool is allowed to author that value, which merely displays it and what a person should do when the copy is wrong.

“System of record” is useful shorthand, but a single label for the entire customer or job is often too broad. A booking tool may own the appointment slot while an intake app owns the approved scope of work. Microsoft’s data-architecture guidance asks teams to identify repositories, ownership and flows and describes different kinds of information being managed in different systems. Its Dataverse reference architecture illustrates one master source publishing selected updates to other applications; that is an example of a chosen arrangement, not a rule that every workflow needs one master application.

Separate the authoritative value from a useful copy

For each business field, ask where a valid change begins, who may approve it and what evidence shows the change was saved. That is the field’s authority decision. A destination can still hold a useful, possibly delayed copy. Label that copy as current only when the workflow can support the required freshness. If the destination cannot prevent a local edit, record how that edit becomes a proposed correction instead of silently sending it back over the authoritative value.

Classify fields by consequence. A display label used only inside scheduling can stay local. A consent or contact preference, approved work scope, appointment time or payment state needs a clearer rule because a wrong value can affect a person or an action. Record ownership at the smallest useful field group; splitting an inseparable decision into many independent cells can hide a conflict just as surely as saying “the CRM owns everything.”

A person is part of the rule. Name the business owner who can settle an exception and a deputy when time matters. A connector account or software vendor can carry a change but cannot decide whether a disputed value is correct for the business. Confirm the actual product plan, permissions and API behavior before treating a policy in this worksheet as technically enforceable.

Copy the field-authority matrix

Download the editable CSV above. It has the ten headings below, an empty template row and four completed rows for an invented equipment-repair business. Make one row per field or inseparable group of fields exchanged between tools. Keep real names, contact details, tokens and private record contents out of a publicly shared copy.

• Business record and field | Why the value is needed | Authoritative tool and human owner | Allowed writers | Copies and sync direction | Matching ID and version/evidence | Conflict rule and correction route | Maximum acceptable lag and reconciliation check | Privacy/retention boundary | Open decision or test.
• Authority and writers: name the one tool that can commit the value, the people or service accounts allowed to change it there, and any explicit exception. “Both tools” is an unresolved decision until a tested conflict rule exists.
• Copies and identity: list every receiving tool, direction of travel, stable record match and available source version. A timestamp alone does not prove that two records refer to the same person or request.
• Conflict and correction: say what happens when a copied value is edited, a stale update arrives or the authoritative value is challenged. Identify who reviews evidence and where the approved correction is made.
• Lag and evidence: choose the longest delay the business can tolerate for this field, either an elapsed time or an event gate such as “before confirmation”. Then define a comparison or exception check that exposes a missed update. Record the check owner and result, not only the sync job’s green status.
• Privacy and open decisions: copy only information needed for the receiving task, define who can see it and how long it is needed, and leave unsupported capabilities visibly unresolved.

Decide what happens when two values disagree

A conflict rule should match the field’s purpose. A scheduling-only label may accept a local edit. An appointment slot changed by a dispatcher should not be replaced by an older intake copy. A disputed approval should pause the next action for a named reviewer. If a tool supports record versions, compare the version used by the incoming change with the current version before accepting it. AWS AppSync documents one implementation: optimistic concurrency rejects an update carrying an old version and returns the current item so the client can resolve the difference. It also documents merge and custom strategies; those choices are product behavior, not a universal prescription.

Do not make “last update wins” an unstated policy for consequential values. Microsoft documents that a timestamp-based last-writer policy in one replication product depends on synchronized clocks and can choose an unexpected winner when clocks drift. Even accurate clocks cannot decide whether a later edit was an informed correction. For a high-impact disagreement, hold the proposed change, show both values and their sources to an authorized owner, and record the approved decision. Test what happens when the owner is absent and the next task is due.

A correction starts with the authoritative tool. Then identify every affected copy, downstream action and person who may have relied on the earlier value. Where UK data-protection rules apply, the ICO’s guidance says challenges to personal-data accuracy require reasonable consideration, and its rectification guidance covers notifying recipients of corrected data in relevant circumstances. The exact obligations depend on the actual data and jurisdiction. Operationally, a correction remains open until the intended copies reflect it or a named exception is visible.

Move values without creating a second authority

Send a change with a stable business-record reference, the originating tool and an available version or change identifier. Do not send the receiving tool’s copied value straight back as a fresh source update; that can create a loop that masks the original correction. When the destination must allow a person to suggest a change, route the suggestion to the authoritative owner for approval instead of applying it automatically.

A repeated delivery should not create a second business action. Stripe’s API documentation shows a concrete provider mechanism: a client-supplied idempotency key lets supported requests be retried without creating the same operation twice, subject to its documented retention and parameter rules. Stripe also warns against putting email addresses or personal identifiers in those keys. Other products have different guarantees, so verify the chosen destination’s actual behavior. The automation-failure-recovery guide covers retry limits and uncertain outcomes in detail; this matrix identifies which value should exist after recovery.

Compare source and destination by stable IDs and relevant versions or values. A daily comparison may be enough for a low-impact display value; a dispatch decision may need a check before assignment. These are business choices, not vendor or legal defaults. Record the acceptable delay, mismatches found, the owner and the correction outcome. The planned webhook-versus-polling guide will decide how changes are detected; this guide decides which changes may win and what agreement looks like.

Hypothetical example: an intake app and scheduling tool

Imagine a small equipment-repair business planning to connect an intake app to a scheduling tool. The business, tools, records and rules below are invented solely to demonstrate the matrix. They describe no Kinetivy client, live integration, measured result or universal best practice. Read each row in the column order shown above; the downloadable CSV contains the same four rows.

• Repair request: requester contact preference | Choose the agreed service-contact route | Intake app; service coordinator | Requester and coordinator in intake | Intake to scheduling only | Request ID and intake revision | A scheduling edit becomes a review request; the coordinator approves any correction in intake | Event gate: before each service message, compare by request ID; coordinator reviews mismatch | Copy the preference code only and apply a reviewed retention rule | Test whether scheduling can prevent a direct edit.
• Appointment: visit slot | Tell the technician and requester when the visit is planned | Scheduling tool; dispatcher | Dispatcher in scheduling | Scheduling to intake only | Appointment ID and scheduling revision | A stale intake value cannot overwrite a new slot; dispatcher checks a disputed change | Event gate: before confirmation and work assignment, compare slot and revision | Copy only the slot and necessary reference; limit access | Test reschedule and cancellation behavior.
• Repair request: work approval | Decide whether work may be assigned | Intake app; service manager | Service manager in intake | Intake to scheduling only | Approval ID and intake revision | Hold a stale or contradictory update; manager reviews and records a correction in intake | Event gate: before assignment, check approval against intake | Do not copy approval notes unless the task needs them | Decide what to show while approval is disputed.
• Appointment: internal display label | Help dispatchers find a visit | Scheduling tool; dispatcher | Dispatcher in scheduling | Stays in scheduling; no reverse sync | Appointment ID | Local edits remain local and never change requester or approval facts | No cross-tool value check; dispatcher reviews local quality | Avoid names or contact details in the label | Confirm the label has no downstream authority.
• Suppose the requester changes their contact preference in intake while a dispatcher edits the older copy in scheduling. The scheduling change is held as a proposed correction; it does not overwrite intake. The coordinator checks which request and revision each change belongs to, resolves the disagreement in intake, and verifies the scheduling copy before the next service message. If the scheduling product cannot express that hold or prevent its edit from being sent back, the team must redesign the handoff or keep it manual until a safe rule is proven.

Test the rule, then revisit it when work changes

Run the matrix with synthetic records: normal edit, stale edit, simultaneous conflicting edit, correction, repeated delivery, missing destination record and a delayed update. For each, write the authoritative stored value, visible copy, next permitted business action and exception owner. A passed test shows the business result, not just an accepted API response. Keep a way to compare records after a disruption.

Review a row when a new tool, field, team role, vendor plan, privacy purpose or workflow step changes. The workflow-readiness guide tests whether the process is stable enough to automate; the API-integration checklist tests whether the vendors can perform a proposed exchange; the state-model guide defines valid record transitions; the migration guide handles a bounded move of existing records. This guide remains the standing answer to which tool may change each value and how a later correction reaches its copies.