Business integrations: connect systems without creating fragile workflows

A useful integration moves the right information between systems at the right time and makes failures visible. It should reduce manual copying without removing the team's ability to understand what happened. Connecting two products is only the technical starting point. The important planning work is deciding which system owns each fact, which event triggers an action and how the business recovers when something goes wrong.

This guide explains how to scope integrations for websites, CRMs and online platforms. It covers field mapping, identifiers, permissions, retries, monitoring and handover. The examples are deliberately practical: a website enquiry becoming a CRM record, a booking creating a task, or a payment changing a subscription state. The same principles apply whether the connection uses a native connector, an automation service or a custom API implementation.

Define the business event before choosing tools

Describe the workflow in ordinary language. When a visitor submits a valid quote request, create one enquiry in the CRM and notify the assigned team. This is clearer than asking to connect the website with everything. It identifies the trigger, the expected record and the people who need to know. It also gives you a testable outcome independent of the technology used.

List the exceptions. What happens if the visitor is already a customer, if the same form is submitted twice, or if the CRM is temporarily unavailable? These are normal operating conditions, not rare curiosities. A design that only works for the first successful request may fail as soon as the business begins using it at scale.

Choose the simplest route that supports the required behaviour. A native integration may already handle authentication and common fields. An automation service can make a straightforward workflow easier to maintain. Custom code is useful when the logic, reliability or data handling requires it. Evaluate these choices against the workflow rather than assuming that custom code is always more capable or that a visual automation is always simpler.

Decide which system owns each fact

A source of truth is the system whose value should win when two copies disagree. Customer contact details might belong in the CRM, product availability in an inventory system and payment state in the payment provider. Ownership can differ by field. The important point is to make it explicit so an old copy does not overwrite a newer or more authoritative value.

Avoid two-way synchronisation unless there is a clear need and a conflict policy. If staff can change the same address in both systems, define how the latest valid change is identified. A timestamp alone may not be enough if clocks differ or one system sends updates late. Sometimes a one-way sync plus a link to edit the authoritative record is safer and easier to explain.

Document which information is copied and which is referenced. A CRM may store a payment provider's customer identifier without copying every payment detail. A booking record may link to a calendar event while retaining its own operational status. Copy only what the receiving system needs to perform its job, and avoid creating unnecessary stores of sensitive information.

Map fields and identifiers carefully

Field mapping is more than matching similar labels. A field called price may represent a total, a monthly amount or a value before tax. A date may include a timezone or only a calendar day. A status named active may mean something different in each product. Write down the intended meaning and conversion rules for fields that affect business decisions.

Use stable identifiers rather than names as the main link between records. People change names, companies share similar names and product titles are edited. External record IDs make updates more reliable. Preserve the original identifier when importing or synchronising so the team can trace a record back to its source and investigate a mismatch without guessing.

Decide how missing values behave. An empty field should not automatically erase a valid value in another system unless that is the intended rule. Distinguish not provided, unknown and intentionally cleared when the workflow requires it. Test punctuation, international phone formats and non-English characters. A workflow that succeeds only with a short English test name is not ready for ordinary business use.

Make repeated events safe

Many integrations deliver events more than once. A provider may retry because it did not receive a timely acknowledgement, even though the first request was processed successfully. Design the receiving action so repeating the same event does not create duplicate invoices, messages or customer records. This is often called idempotency, but the practical goal is simply safe repetition.

Store a unique event or operation identifier and record whether it has been handled. If an action involves several steps, track their states rather than treating the entire process as a single invisible operation. For example, a CRM record may have been created even if the notification failed. Retrying should send the missing notification, not create a second customer.

Consider the order of events as well. A cancellation may arrive before a delayed creation notification, or an older update may be retried after a newer one. Use the provider's documented sequence, version or current-state lookup when needed. Avoid assuming that the order of network delivery is always the order in which the business events occurred.

Design failure handling for real people

A failure should leave enough information for someone to understand the affected workflow and recover it. Record the event type, relevant non-sensitive identifiers, time and error category. Do not dump passwords, access tokens or full private customer messages into logs. Useful diagnostics should help investigation without turning the monitoring system into a second uncontrolled data store.

Separate temporary failures from permanent ones. A short service outage may justify a delayed retry, while an invalid customer identifier needs correction. Repeatedly retrying a malformed request wastes resources and can trigger service limits. Use bounded retries and a visible failed state that the team can review. Explain who owns that review and how urgent different failures are.

Plan the customer-facing response when part of a workflow is delayed. If a booking is saved but the confirmation email is late, the user should still see a reliable booking reference. If a payment is pending, do not present it as completed merely because the browser reached a success page. The interface should reflect the authoritative processing state rather than an optimistic assumption.

Keep access narrow and maintainable

Use service-specific access with the permissions required for the workflow. A connection that only creates enquiries usually does not need unrestricted access to delete customer records. Store credentials in the platform's secret-management system and keep them out of frontend code, repositories and public documents. The business should know who can rotate or revoke the connection.

Plan for credentials expiring or being revoked. A staff member leaving should not unexpectedly break an essential automation because it relied on their personal account. Where the provider supports it, use an appropriate business-owned integration identity. Record the account owner, connected systems and renewal responsibilities without exposing secret values in the handover guide.

Review access after the integration changes. A temporary permission granted during development may no longer be needed. Remove unused connections and test that the workflow still functions with the intended minimum scope. Include a clear way to stop the automation if it begins producing incorrect records, while preserving enough evidence to investigate and repair the affected data.

Test with realistic cases before launch

Build a test matrix around the business workflow. Include a normal event, a duplicate event, missing optional information, invalid required information, a temporary outage and an out-of-order update. Test the customer's visible result as well as the records in each connected system. A green response from one API does not prove that the whole workflow completed correctly.

Use test environments or clearly identified test records where available. Avoid sending real customer notifications while experimenting. Verify the exact destination account before enabling production writes. A connection can be technically correct and still send enquiries into an old workspace that nobody monitors. Names, ownership and routing deserve the same attention as field formats.

After launch, reconcile a small period of activity. Compare source events with destination records and investigate differences. This can reveal silent omissions, duplicates or misunderstood filters. Establish a simple ongoing check appropriate to the importance of the workflow. A critical payment or booking integration needs closer monitoring than a nonessential internal notification.

Integration brief checklist

• Name the triggering event and the desired business outcome.
• Identify the source of truth for each important field.
• List systems, accounts, owners and required permissions.
• Define stable record identifiers and field conversion rules.
• Specify duplicate handling and event-order assumptions.
• Explain temporary retries, permanent failures and manual recovery.
• Test customer-visible states and destination records together.
• Document monitoring, support ownership and a safe stop procedure.

Keep this brief understandable to the people who operate the business. Technical documentation is valuable, but a manager should still be able to explain what the integration does and who to contact when it stops working. A connection that only its original developer understands creates unnecessary operational risk and makes future improvements slower.

Frequently asked questions

Should every integration run instantly?

No. Some workflows need immediate updates, while others can safely run on a schedule. Choose the delay the business can tolerate. A daily reporting export has different requirements from confirming a booking or changing access after a payment event.

What is the difference between a webhook and a scheduled sync?

A webhook notifies another system when an event occurs. A scheduled sync checks for changes at intervals. Either approach can work well, but each needs duplicate handling, failure recovery and clear ownership of the information being transferred.

Can we connect any two platforms?

Only if their supported interfaces, permissions and product rules allow the required workflow. Some systems provide limited APIs or restrict access by plan. Confirm the available capabilities before promising a connection, and avoid brittle workarounds that depend on undocumented behaviour.

Why do duplicate records appear after an integration?

Common causes include repeated events, unstable matching fields and retries that repeat completed steps. Use persistent identifiers and record processing state. Diagnose the actual source before deleting duplicates so the same problem does not immediately recreate them.

What should we monitor after launch?

Track failed operations, processing delays, unexpected volume changes and reconciliation differences. Monitor the outcomes that matter to the business, not only whether a server is running. Assign someone to review alerts and provide a documented recovery path.