Define what should pass between your everyday business systems, who is responsible for it and what happens when a connection fails.
Start with the handover, not the connector
Mapping detail
Choose one repeated handover that currently involves retyping, copying from an email or checking two systems. A sensible first connection might create a customer record from an accepted website enquiry, rather than attempting to synchronise every contact in both directions. Write down the business event, the receiving system and the useful outcome before comparing integration products. This keeps the decision tied to work that staff actually do.
Name the system that owns each field
Mapping detail
Decide where each fact is maintained. A CRM might own contact status, while the accounts package owns invoice and payment status. Avoid allowing two systems to overwrite the same field unless there is a clear conflict rule. Required fields also need agreement: if the job system needs a postcode but the enquiry form does not collect one, the connection should pause for completion rather than creating an unusable job.
Use a narrow trigger and explicit conditions
Mapping detail
Define precisely when the flow runs. ‘Form submitted’ may be too broad if the website has recruitment, supplier and sales forms. Conditions such as form name, consent choice, service area or an approved pipeline stage prevent unrelated records travelling to the wrong place. Include a duplicate check based on a stable identifier such as email address plus business name, while recognising that shared inboxes and repeat customers may still need human judgement.
Plan for failed and partial transfers
Mapping detail
Connections fail because passwords expire, fields change, services reach usage limits or supplied data is invalid. Choose an alert destination that somebody checks during working hours and include enough detail to recover the record without exposing unnecessary personal data. Keep the original submission available until transfer is confirmed. A retry should not create a second contact, task or invoice, so record a source reference in the destination.
Test with ordinary and awkward records
Mapping detail
Use test entries covering a normal enquiry, a missing optional field, an existing customer, a long company name and a deliberate error. Check not only that a record appears, but that ownership, notes, dates, consent and follow-up tasks are correct. Run the connection quietly with a small scope first, review its log after several real cases, and document how to disable it without losing incoming work.
Practical template
Business app connection specification
Complete one copy for each proposed connection before anyone builds it.
Business handoverState the manual handover being replaced and the person or role currently doing it.
Trigger eventName the exact event and any qualifying conditions, for example an enquiry marked ‘sales qualified’.
Source and destinationRecord both systems, the relevant form, list or pipeline, and which system is authoritative.
Field mapList every source field beside its destination field, including format changes and required values.
Duplicate ruleDefine how an existing person or company is recognised and whether to update, append or stop.
Permission basisRecord who may access the connection and whether personal data is appropriate for the destination.
Failure responseName the alert recipient, retry rule, manual recovery route and maximum acceptable delay.
Acceptance testsList normal, duplicate, incomplete and failed examples, plus the expected result for each.
Owner and review dateAssign one operational owner and a date to check logs, credentials, fields and continued usefulness.
