If someone repeats the same administrative task each day, automation can sound like an obvious improvement. Sometimes it is. But a manual process often contains decisions and exceptions that are easy to overlook when describing only the happy path.
Before connecting systems, understand what the person doing the work actually checks.
Map one real example
Choose a recent instance of the task and follow it from beginning to end. Record what starts the process, where information comes from, which fields are copied and what the person does when something is missing.
Ask what would make them stop and seek approval. A changed customer address may be straightforward. A changed bank account should not be treated as an ordinary data update.
This exercise often exposes a simpler improvement before any custom code is needed: a clearer form, a shared record or an existing integration that has not been configured.
Decide which system owns each record
Two-way synchronisation sounds convenient, but it needs rules. If a customer’s details change in two systems, which version should win?
Define a source of truth for each type of information. Record identifiers are more dependable than matching by a person’s name, and updates should be traceable without storing unnecessary personal data in logs.
Consider deletion and retention too. Removing a record in one tool should not accidentally recreate it from another.
Expect failures and repeated events
APIs have limits. Networks fail. A service can accept an action even when the caller never receives confirmation.
An integration should account for:
- Authentication and permissions.
- Request limits and temporary outages.
- Repeated events or retries.
- Missing, invalid or unexpected data.
- Changes to the connected service.
Repeating a failed request without understanding what happened can create duplicate records or actions. Where possible, use a stable event identifier and a design that can safely recognise work already completed.
Do not blindly retry irreversible actions. Financial and other sensitive workflows may need an explicit review step.
Keep human decisions where they help
Automation need not mean removing all checks. Preparing a draft invoice and asking someone to approve it can be more appropriate than issuing it automatically.
Make the handover clear: who is asked to approve, what information they see and what happens if nobody responds? An approval step without an owner can become a new bottleneck.
An illustrative example is a quote-to-project workflow. An accepted quote could create a project record and prepare an invoice draft. The design still needs rules for revised quotes, duplicated notifications and cancellations. This is a possible workflow, not a claim about a completed client project.
Make failures visible
Someone needs to know when work is waiting or has failed. A useful notification explains the affected operation and the next action without exposing confidential data.
Monitoring should distinguish a temporary problem from a task that needs intervention. Agree who receives alerts and who maintains the integration when a third-party API changes.
Document how to pause the workflow and how to recover safely. A manual fallback is worth planning before an outage.
Assess whether the investment makes sense
Estimate the frequency of the task, its current effort and the consequences of mistakes. Compare those with implementation, subscription and maintenance costs.
These are estimates, not guaranteed savings. Start with a bounded workflow and review whether it improves the process in practice.
If you are considering business automation or integrations, bring a real example of the current process. Understanding the awkward cases is usually the most valuable place to begin.