Start with one complete workflow.
List the people involved and follow one record from start to finish. Where does it begin? Who changes it? What has to happen before someone else can act?
A link between two applications does not fix unclear responsibilities or inconsistent information. Agree the workflow and record ownership before choosing the connection.
Illustrative workflow, not a client result
Service request → review → job record → team workspace → customer update.
A request might create a draft job, but a person still reviews it before confirming the work. The workspace can show progress without becoming a second place to edit the original customer record.
Check how the systems let information move.
A supported API, webhook or export/import process may provide a route. Check the vendor’s current documentation and subscription terms for access, restrictions and ongoing fees. Some tools expose information but do not permit every action your workflow needs.
Decide how quickly information needs to move. A scheduled update can be sufficient for a daily report; a time-sensitive handoff may need a different approach. Do not promise real-time behaviour before checking the systems and operational need.
Choose a source of truth for each record.
Decide which system owns customer details, stock, job status and other important records. Define identifiers, field mapping, validation and who is allowed to change information.
If both systems can edit the same field, agree how conflicts are resolved. Also decide what happens to duplicates, missing values and corrections. A dashboard may read information from a system without becoming the owner of that information.
Plan for a connection that stops working.
Services can be unavailable, credentials can expire and vendor behaviour can change. Scope how errors are recorded, who is alerted, whether an action can be retried safely and how people can see an incomplete handoff.
For an action such as creating an order, retrying must not create a duplicate. Keep a record of what happened and provide an agreed recovery path. The connection needs a responsible owner and a maintenance arrangement.
Compare the smallest useful options.
| Approach | When to consider it | What to check |
|---|---|---|
| Improve the current setup | A feature already covers the need. | Configuration, training, access and process ownership. |
| Use an existing connector | The supported actions match the workflow. | Limits, fees, reliability and who maintains it. |
| Build a custom connection or layer | Specific rules or views are missing. | APIs, record ownership, failure handling and ongoing responsibility. |
| Replace a system | The current tool cannot support an essential requirement. | Migration, disruption, training and long-term fit. |
What to bring to a scoping conversation.
- The systems involved and an example of the work.
- The information that is copied or moved.
- Who owns it and who needs access.
- How quickly the next step needs to happen.
- The consequences of a missing or incorrect handoff.
MindLabs can help map this and identify a useful first scope. See the custom-systems approach. If the need is a clearer shared view, start with dashboard requirements and explore the Atlas interface concept. Atlas does not establish that these example integrations have already been built.