Which system should own a field that appears in two tools?
Format: Article.
Give each field a home where the right person can approve changes. That is what it means for a system to own the field. Do not pick a tool just because it wrote last or is easy to connect. Both tools may show a phone number while only one can approve a change to it.
Make this choice for each field, not just each customer record. The record may hold a service phone number, a task's status and payment terms. Different teams may approve each of those facts. Giving one tool control over the whole record can hide the checks each team needs.
Distinguish a suggestion from an approved fact
A support worker may hear that a contact number changed. That gives the team a proposed correction. It does not necessarily authorize a system to replace the billing contact or legal notice address.
Write down who may propose a value, who may approve it and where the approved value lives. A connected tool can display the proposal beside the current fact. If its interface shows both as the same kind of truth, staff may use an unverified change without realizing it.
Some fields are copies. Others combine facts to make a label, such as an account name plus its ID. That label is not a new source of truth. Write down how the tool builds it and which source edits should make it change.
Fill a field ownership matrix
Use the following examples to start a discussion, not as a rule for every company. Replace each owner with the actual role and tool in your operation.
| Field | Approval home | Other tool's role | Conflict route | Clearing or deletion rule |
|---|---|---|---|---|
| Service contact phone | Account system after contact check | Submit a proposed correction | Account owner verifies the caller's update | Blank does not erase a verified number |
| Followup task state | Work queue with assigned operator | Show the current queue state | Queue owner checks completion evidence | Archived tasks keep their history |
| Approved payment terms | Finance's controlled record | Display terms without editing | Finance reviews any mismatch | No default terms inserted on missing data |
| Combined account label | Derived from approved name and ID | Render a readable label | Fix source fields, then rebuild display | Do not write display text back as an ID |
For each row, show which way the value may move. “Account system to queue” is clearer than “two-way sync.” If staff in both tools can suggest edits, show where those edits go for approval. Then show how the approved value gets back to both screens.
A hypothetical contact conflict
A maintenance business has an account system and a custom followup queue. A service coordinator updates a callback number in the queue after speaking with a site contact. Meanwhile, the account manager corrects the main contact number in the account system.
If both fields are named “phone,” the connector may copy one over the other. But they serve different needs. In this hypothetical case, name one “callback number for this request” and the other “approved account contact number.” The newest entry does not tell you which number belongs in each place.
Keep the callback number with the request and its source. Let the account manager decide whether the approved account record also needs an update. The two values can differ without either being a data error.
Now consider task state. A service worker marks a followup complete, but the account system still shows it open from an earlier copy. If the queue owns task state, the older copy must not reopen the task. A review may still find that completion was wrong, but that is a business correction in the owning process, not an automatic overwrite.
Field authority is not a version check
A version check can prevent an old edit from replacing newer data. Microsoft documents an Azure Blob mechanism that rejects an update with status 412 when the supplied version identifier no longer matches.[4] That is a technical control for a specific storage service, not a business ownership rule.
Once the system finds a conflict, someone still needs to decide which value to keep. A newer value can come from a person who had no right to approve it. Ask the builder to show the warning, who receives it and how that person records a decision.
Test the awkward values
Use a short test set: an empty field, an explicit request to clear a field, an old copied value and an approved correction. Each should have a defined result. A blank caused by missing access must not erase a known value. A deleted account must not be recreated just because another tool still holds a copy.
Retain the source reference and reason when resolving a conflict. Review the matrix when a department changes its process, not just when the API changes.
Core Agentic can scope software around these real authority boundaries. Bring one field that causes repeat disputes. Book a Demo to discuss a custom design that separates proposed changes from approved facts.
Sources
These sources describe the named provider or framework. They do not establish a Core Agentic integration, customer result or certification.