Quick answer
Before connecting two tools or building an automated flow, a business should write a short data agreement: which record is authoritative, which fields are required, who may edit them, when data is synchronised, and what happens when records disagree. That agreement turns an automation idea into a flow that can be checked, repaired, and handed over.
The problem is not whether systems can connect
A demo usually follows the happy path: a form is complete, a customer name is consistent, and two systems agree. Live operations have more variation. A contact may be created twice, a key field may be empty, a status may change in two places, or someone may edit data without realising a downstream flow relies on it.
The issue is often not a missing tool. It is that the team has not agreed what counts as the truth for a specific piece of data. In that situation, automation simply moves disagreement faster.
NocoBase describes Data Sources as a capability for connecting and managing internal or external sources in order to build a system data model. That does not mean every business should consolidate every datum in one place. Before connecting systems, the team needs to decide how each source will be used and managed.
Five decisions: Source — Identity — Status — Edit rights — Exceptions
This is an operating-design tool for one defined process, not legal advice or a mandatory architecture for every system.
1. Source: where does the authoritative record live?
For each important object—such as a customer, purchase request, contract, or task—choose one place that counts as the authoritative record. Other tools may display it, receive a copy, or send updates, but the team needs to know which one is checked when two values differ.
Settle this question: If a customer's phone number or status differs across two tools, whose record decides and which system holds it? One system may own customer data while another owns finance data. What matters is that the agreement is written for each data type rather than retained in people's memories.
2. Identity: how do we know two records refer to the same thing?
Person names, company names, and request titles are easy to write differently. Before matching records, choose a stable identifier: a customer number, request number, or a key created by the system. If no shared identifier exists, define how it is created and where it is stored. Do not use a display name as the only matching condition when it can change.
3. Status: what does each word mean in real work?
“Processing”, “complete”, and “approved” can mean different things to different functions. A status belongs in a workflow only when the team can describe:
- the condition that moves a record into it;
- who may change it;
- which work may start after it;
- which states cannot be reversed without approval.
For example, “approved” must point to a specific decision: approval of need, budget, or delivery. One word for three decisions makes reporting and automation less dependable.
4. Edit rights: who changes which field, and where?
Connecting systems does not mean everyone should edit every field everywhere. For each important field, record the role allowed to update it, the primary interface for that update, and how other tools receive the change.
NocoBase treats Users & Permissions as a distinct capability area, covering roles, permissions, and access controls. Whatever platform is used, access should reflect work responsibility and be tested in the real flow, not only inspected on a configuration screen.
5. Exceptions: who decides when synchronisation does not run?
A useful agreement does not only describe the normal path. It answers: when a required field is missing, where does the record stop; when a duplicate is found, who decides whether to merge it; when a system does not respond, does the flow retry, alert someone, or hand work back for manual handling; and who may correct the source record when bad data is found.
NIST describes its AI RMF as a voluntary framework intended to help organisations incorporate trustworthiness considerations into the design, development, use, and evaluation of AI systems. The mindset also helps with automation design: establish accountability and a way to handle risk before expanding a flow, rather than only testing whether it runs.
A 45-minute playbook for one first flow
Choose a narrow flow, such as an internal request created in a form and passed into a work-tracking tool. Bring together the process owner, one real user, and the configurator.
- List the five most important fields for a decision or work routing.
- Mark the source for each field when a conflict occurs.
- Choose an identifier and check how a duplicate can be created.
- Write the status table: entry condition, person who changes it, and next step.
- Assign update roles: who edits, where they edit, and who only views.
- Rehearse two failures: one empty field and one duplicate record.
- Configure only then, and keep the agreement next to the workflow.
The output is a readable one-page agreement, not a long technical document. If the team cannot answer a question, that is a signal to clarify the process first—not to add another rule inside a tool.
When should you pause before expanding?
Slow down if the same field can be edited in several places without a precedence rule; nobody owns a bad-data incident; statuses are only broad labels; or the team cannot explain recovery after a failure. These are not proof that a project has failed. They show that the flow needs another design pass before connecting more systems or assigning more steps to AI.
Where can OXMODE help?
OXMODE can work with a team to unpack a real operating flow, identify data sources, update responsibility, approval points, and exceptions before configuring a no-code/low-code platform, workflow, or AI assistant. The goal is an approach the team can inspect and maintain. If the team is defining role-based access, read the SME role-access framework next.
Frequently asked questions
Does every piece of data need one authoritative source?
No. Start with data that directly affects a decision or a cross-functional flow. For every important data type, the team needs to know which place takes precedence when records conflict.
Should we start with two-way synchronisation?
Only after the team has agreed which fields can be updated on each side and how conflicts are resolved. For a first flow, a controlled one-way connection is often easier to check and repair.
Can AI clean data automatically before it is synchronised?
AI can assist with suggestions or prepare a draft within its assigned scope. For data that affects decisions, set validation rules and a named human reviewer rather than treating a suggestion as an official record.
Sources
- NocoBase Documentation, Data Sources.
- NocoBase Documentation, Users & Permissions.
- NIST, AI Risk Management Framework.
