Skip to content
CanAutomate

What we automate

Systems integration for business workflows

Making the tools you already pay for talk to each other, so the same information stops being entered twice.

The short answer

Systems integration means getting the software you already run to pass information to each other, so a fact entered once appears everywhere it is needed and your systems stop disagreeing about what is true. A booking made in the scheduler should reach the CRM, the invoicing tool and the job sheet without a person carrying it across. We work with whatever route the systems actually support — a documented API where one exists, events, a scheduled export, a database view, and browser-level automation only as a genuine last resort. We tell you which one we are proposing and how likely it is to break when a vendor ships an update.
Book a workflow auditSee how we work

How you know you have an integration problem

Integration problems rarely announce themselves. They show up as duplicated effort and quiet mistrust of your own numbers.
Two systems, one truth, no agreement
The CRM and the accounting system hold different versions of the same customer, and which one is right depends on who updated it last.
Copy-paste as a job function
Someone's role includes moving the same information from one screen to another, several times a day.
Exports as the integration
The connection between two tools is a spreadsheet somebody downloads on Fridays, and everything downstream is stale by Wednesday.
Nobody trusts the report
Before anyone acts on a number, they check it against the source system, which means the report is not really doing its job.

Five ways two systems can be connected

Listed from most durable to most fragile. Which one is available is decided by your software, not by preference — but you should know which one you are getting and what it costs you later.
  1. 01

    Supported API

    The best case. Stable, documented, versioned, and unlikely to break without notice. If both systems offer one, this is what we use and there is little to debate.

    Most durable

  2. 02

    Webhooks and events

    Where a system can tell us something happened rather than being asked every few minutes, we let it. Less load, faster reaction, fewer polling gaps.

    Near real time

  3. 03

    Scheduled export or file drop

    Common with older line-of-business software. Reliable within its cadence; the honest limitation is that the data is only as fresh as the schedule.

    Predictable lag

  4. 04

    Database or reporting view

    Where read access can be granted safely, this is often cleaner than scraping a UI. It needs care around permissions and around what happens when the vendor changes a schema.

    Read-only, usually

  5. 05

    Browser-level automation

    The last resort, used only when there is genuinely no other route. It works, and it is the most fragile option on this list. We will say so plainly before proposing it.

    Fragile by nature

Building for the day something is down

An integration is judged on how it behaves when a system it depends on stops answering. That is designed before the working path is.
Retry with backoff
Transient failures are retried on a widening interval instead of hammering a system that is already struggling.
Queue, do not drop
Work waits in a queue while a system is unavailable and resumes when it returns. Nothing is silently lost.
Alert a person, not a dashboard
When something is genuinely stuck, a named person is told, with enough detail to act. Nobody is expected to watch a screen.
Idempotent by design
Running the same message twice does not create the customer twice. This is the failure mode that costs the most to clean up afterwards.

Platform or custom code?

There is no single right answer, and anyone who gives you one without asking about your team is selling something.

A platform like n8n, Make or Zapier

Right when the logic is moderate, the volume is manageable, and you want to be able to see what is running without reading code. Faster to build and easier to hand over. The trade-off is per-run cost at volume, and awkwardness once the logic outgrows what the interface can express clearly.

Custom code in your own environment

Right when the logic is genuinely complex, the volume is high, or the data cannot leave a particular environment. Cheaper to run and unlimited in what it can express. The trade-off is that changing it needs a developer, so we only choose it when the platform route would hit a wall you can already see.

Whichever we pick, it runs in your accounts with credentials you control, and it is documented well enough that another developer could take it over. Nothing we build should only work while we are involved.

Questions we get asked

What does systems integration mean here?
Making the tools you already pay for pass information to each other, so the same fact is not entered twice and the systems stop disagreeing. A booking that appears in the scheduler should reach the CRM, the invoice tool and the job sheet without a person copying it across. Integration is often the least glamorous work we do and the most immediately felt.
What if our software has no API?
It is common, and it is not automatically a dead end. Depending on the system, the options are a supported export, a database view, a file drop, or browser-level automation as a last resort. Each of those carries different fragility, and we will tell you which one we are proposing and how likely it is to break when the vendor ships an update.
Do you build on n8n, Make, Zapier or custom code?
Whichever fits the problem and the people who will live with it. A platform like n8n or Make is often right when the logic is moderate and you want visibility into what is running. Custom code is right when the logic is genuinely complex, the volume is high, or the platform's limits would be reached quickly. We explain the trade-off, including what it costs you to leave, before we pick.
Who owns and maintains what you build?
You do. The work runs in your accounts, on your infrastructure, with credentials you control, and it is documented so another developer could pick it up. We will happily keep improving it, but you are not meant to be locked in, and nothing is built in a way that only works while we are involved.
What happens when one of the connected systems goes down?
The automation should fail loudly and safely rather than quietly losing work. In practice that means retries with backoff for transient failures, a queue that holds work until the system returns, an alert to a named person when something is stuck, and no silent data loss. We design this before we design the happy path.

Related

Workflow audit

A written map of what connects to what, and where it breaks.

Which two systems disagree with each other?

That answer is usually the fastest route to a first automation worth building.

Book a workflow audit