Automation with a plan for failures.

Start with a task that repeats

A useful automation has a clear trigger, a defined action and a way to confirm the result. For example: when a request is approved, create the delivery record and record the response.

Before building, we check the volume, how much work the handoff creates and the cost of getting it wrong. Low-volume tasks that change every time may be better handled manually.

Use the connection that fits

If a native integration supports the required fields, permissions and behaviour, we can configure and test it. An existing automation platform may cover the missing steps.

Custom code is useful when you need logic, access controls or behaviour that those options cannot support. The decision includes ongoing costs, provider limits and who will maintain it.

For each record, we establish which system is authoritative. Two-way synchronisation needs explicit rules for conflicting changes; adding a connection does not settle that question.

Define what happens when a run fails

A timeout does not always mean nothing happened. If the receiving system accepted a request before the connection failed, sending it again could create a duplicate.

The implementation should distinguish temporary failures from invalid data or missing permissions. Where the receiving system supports it, a stable operation identifier can help prevent duplicate actions. Otherwise, the design needs an appropriate check or a manual review.

We agree how failures become visible, how long to retry and when someone takes over. A manual fallback matters when a missed deadline has consequences.

Test the work beyond the successful example

Acceptance checks should cover repeated events, incomplete records, unavailable services, expired credentials and a partial update. We also confirm that a successful response means the intended record or action exists.

Logging should provide enough context to diagnose a run without unnecessarily copying sensitive information. Access, retention and notification recipients belong in the scope.

Hand over the operating instructions

The team needs to know what runs, when it runs, what can be retried and who receives an alert. Handover should identify the connected accounts, dependencies, recurring costs and recovery steps.

The 21Goals case study describes football-data integration and administration in a product setting. Your own workflow may need a much smaller connection.