Perspective
Decide Which System Owns Each Fact, and Every Connection You Build Becomes Simpler
Connecting two systems is the easy part. Deciding which one is right when they disagree comes first, and we settle ownership of each fact before we build anything.
4-minute read4 November 2026
In Brief
- When the CRM, the billing system and a spreadsheet each hold a different address, a connector moves the disagreement around faster. Staff spend skilled time retyping, and one absence slows the business.
- We see four actions: name an owner for each shared field, make one-way flow the default, choose how records are identified, and plan what happens to rejected records.
- Thinqmesh maps every system and which one owns each fact, builds the connection, and makes every failure raise an alert. Your first connection runs unattended in four weeks.
A customer's address sits in the CRM, in the billing system and in a spreadsheet kept by the dispatch team, and the three do not agree. The usual request is to connect them. It is commissioned as a technical project, yet the difficulty lies elsewhere: someone has to decide which of the three is right.
A Connector Moves a Disagreement Faster
Integration exposes that gap without closing it. A connection between two systems that each believe they hold the truth carries errors in both directions, with less trace than a person retyping them ever left. In most companies the integration is a person, who knows that the order goes into the stock system before the invoice and that the export is wrong on Mondays.
The decision that matters comes first and belongs to the business. We map every system, name which one owns each fact, and check which connections are worth building before we build any. Everything we connect then reports its failures and carries documentation your own developer can use.
Four Actions That Settle Ownership Before the Build
A one-page table does more for an integration than the choice of platform, and each action below adds a column to it.
Name an Owner for Each Shared Field
Ownership attaches to fields, and a whole record can have several owners.
Sales may own the contact details, finance the credit limit and tax registration, and operations the delivery instructions. The owner is the one place where the field may be changed, and every other system holds a copy it may display but may not correct on its own.
Get started
- List the ten fields that appear in more than one system.
- Write the owning system and team beside each.
Make One-Way Flow the Default
Two-way synchronisation is usually a sign that ownership has not been settled.
When both sides edit a field between runs, one change overwrites the other and the loss is found weeks later. Let each two-way field justify itself, and give teams that need to change data they do not own a route to do so in the owning system.
Get started
- Mark every field currently synchronised in both directions.
- For each, ask who actually needs to edit it, and where.
Agree How One Customer or Product Is Identified
Matching on names and email addresses is where duplicates begin.
Choose an identifier that every system holds, and record it in the table. Where none exists, create one in the owning system and pass it on to the others, so a record means the same thing wherever it appears.
Get started
- Pick the identifier for customers, and check each system stores it.
- Count the records that lack one.
Decide Where Rejected Records Go
A receiving system will refuse some records, and someone has to own the queue.
Name the person who clears rejected records and the time within which they must act. Assume that a message may arrive twice, and make sure the second arrival cannot create a second invoice.
Get started
- Name an owner for failed records for each connection.
- Test what happens when the same order is sent twice.
How Thinqmesh Solves This
We first establish which system owns each fact, and which connections are worth building, since a bridge to software due for replacement is money spent twice.
- Week 1
A Map of Your Systems
We map every system and which one owns each fact, and agree with you the one connection to build first.
- Week 2
Connection Design
We design the connection on a defined scope, running on a schedule or on an event, and settle how records are matched.
- Week 3
Build, With Alerts
The connection is built, and any failure raises an alert naming what failed and what it was doing.
- Week 4
Running Unattended
The connection runs without anyone watching it, with documentation your own developer can pick up.
You finish with a map of ownership, your first connection running unattended, and an interface that lets software and assistants use it too. Multi-system work follows its own plan.
