The Integration Problems That Break Automated Workflows

Before approving a workflow automation, ask the implementation team to explain what happens if its trigger is delivered twice.

The question is deliberately ordinary. A system may repeat a message because it did not receive a clear acknowledgement. A person may resubmit a request because the interface appeared to stall. A support colleague may retry an action without knowing that the first attempt partly succeeded.

If the result is two customer records, two notifications or an unintended second charge, the workflow needs more than a faster connection between applications.

An automation performs work across assumptions: what an event means, whether the data is current, which system has authority and how completion is established. Those assumptions become business rules even when they are hidden inside a no-code connector.

For an SME, the aim should be a process the team can explain and recover. That may mean keeping part of the work manual until the connected systems can provide reliable evidence. It may also mean automating a smaller sequence first.

The decision is easier when the brief describes the business outcome and the failure conditions. “When this form arrives, create that record” is an instruction. It is not yet a complete account of how the workflow should behave.

A customer can appear in a CRM, billing application, support platform and operational database. It is tempting to describe one of these as the single source of truth. That label is insufficient if different systems legitimately control different facts.

The CRM may maintain a sales contact. Billing may establish whether an invoice has been paid. The operational system may maintain a service entitlement. The automation needs to respect those boundaries.

Document which system controls each consequential field or state. Define how an update reaches other systems and what should happen when they disagree. An old CRM value should not automatically overwrite a verified billing change merely because a sync job runs later.

The UK Government's Data Quality Framework treats quality in relation to purpose and the data lifecycle. Applied here, information must be suitable for the action it is about to trigger, not simply present in a field.

Preserve stable identifiers between records. Matching by name alone can be ambiguous, and an email address may change or be shared in some business contexts. The correct identity design depends on the workflow and the records available.

Also establish who can correct a conflict. A technical integration can flag that two systems disagree. It cannot always decide which commercial fact is correct. The relevant business owner needs a usable route to inspect the evidence and record the resolution.

Stripe's webhook documentation describes retries, duplicate deliveries and events that may arrive out of order. These behaviours are specific to Stripe, but they provide a concrete reason to examine the delivery contract of every connected provider.

The important business question is whether repeating an event repeats its effect. A notification might be inconvenient twice; creating a second fulfilment request could be more serious. The integration should distinguish the event it received from the action it has already completed.

Stripe's idempotent request documentation explains one supported mechanism: an idempotency key can allow a request to be retried without performing the same operation again. This protection applies within the API's defined behaviour. It does not automatically make a multi-system workflow safe.

Partial completion is a separate problem. Imagine an illustrative workflow that creates a service record, sends a welcome message and assigns onboarding work. If the final step fails, repeating the whole sequence may create duplicates in the steps that succeeded.

The design needs to record enough progress to recover deliberately. It may retry only the failed action, check an existing result or route the situation for review. Where a compensating action is proposed, such as cancelling a newly created record, establish whether the business actually permits it.

Require a plain explanation of these choices. A buyer should be able to understand the operational consequence without becoming an integration engineer.

Reliable delivery cannot repair a poorly chosen business rule. If an automation routes every request to an overloaded specialist, better integration will simply make the queue more dependable.

Microsoft's overview of business process management recommends examining the people, activities and bottlenecks in a process before implementing and monitoring changes. The useful step is to understand the work that the automation will preserve.

Review the trigger and the exit condition. What must be true before an action is allowed? What result means the work is complete? What happens to a request that does not satisfy the normal conditions?

Keep human decisions visible. An approval should identify what is being approved, the information used and the scope of the person's authority. Moving a vague approval into a workflow tool does not make it clearer.

There is also a maintenance trade-off. A tightly connected sequence can reduce repeated entry while making the business more dependent on several providers being available and compatible. A looser process may tolerate delay but require reconciliation. The right choice depends on the consequence of waiting and the team's ability to manage exceptions.

This review can lead to a smaller automation than initially proposed. That is a useful result if it leaves the business with work it can understand and support.

A workflow that fails silently creates uncertainty for both staff and customers. Define how an unresolved action is detected, where it appears and who is responsible for handling it.

An exception should include the relevant business reference, the last known completed action, the failure and the permitted next steps. Staff should not need to rerun the entire workflow blindly to discover what happened.

Avoid sending every technical event to the same inbox. Decide which conditions require prompt attention, which can wait for routine review and which are safely handled by a supported retry. The distinction should follow business consequences, not the volume of alerts the tool can produce.

Keep logs useful and proportionate. They should help investigate the workflow without becoming an uncontrolled copy of personal data or credentials. Access and retention need the same thought as the main application records.

The team also needs a way to pause an automation when its behaviour becomes unreliable. Establish who can do that, what work will accumulate while it is paused and how processing resumes. A manual fallback is useful only if someone knows how to perform it.

These responsibilities are part of the automation's operating cost. Include them when comparing a custom integration, a managed connector and a continued manual process.

Select a workflow and define the outcomes the business must be able to trust. Then ask for evidence under conditions that could occur in normal operation.

Repeat a supported trigger in a safe test environment. Delay a response. Supply a record that already exists. Interrupt a downstream step after an earlier one succeeds. Check an update that arrives late and a request that requires manual judgement.

For each case, inspect the resulting records, the customer message and the staff action. The outcome should be coherent across all three. A successful connector run does not prove that the business result is correct.

The brief for automation and software integration should record the authority rules, identifiers, recovery behaviour and operating owners. Recheck those assumptions when a provider changes its interface or the business changes its process.

The useful result is a workflow that completes routine work and exposes uncertainty clearly when it cannot. Faster movement is valuable when the information and responsibilities can keep up with it.