Skip to content

Automation & Orchestration

Workflow automation: save first, then act

A finished job needs an invoice, an approval, an email and a note to the office. Workflow automation runs that sequence across your systems, but the important part is what it writes down: the trigger, the saved state, and the outcome of every step. That record is what lets a run wait for a person, survive a failure and ignore a duplicate.
Discuss your systemSee three runs of the same workflow ↓
job.completedValidateSave stateCheck totalRequest approvalCreate invoiceSend invoiceNotify officeRun r-2291 · J-41815:40triggerjob.completed received15:40validatephotos ✓ parts ✓15:40savestate: Checked15:40check$3,180 > $2,50015:41approvalwaiting · operations manager17:33approvalapproved17:34invoiceINV-2207 created17:35sendemailed to customer17:35notifyoffice told

Steps that depend on someone remembering

A finished job should lead to an invoice, a check, an email and an update. When those steps depend on people copying information and remembering the order, work stalls between systems and nobody can say where a job has got to.

Workflow automation coordinates the sequence. It starts from a trigger, saves the case's state before acting, and records what each step did. Business records stay where they belong, in the CRM or accounting; the workflow coordinates the work around them and keeps the history.

What every run records

  1. Trigger

    What started it

    The event, schedule or request, with its own ID, so the same trigger can be recognised if it arrives again.

  2. Saved state

    Where the case stands

    Written before any action, so a failure halfway through never loses the case.

  3. Step outcomes

    What each step did

    Done, waiting, retrying or failed, with the time and the result, such as the invoice number.

  4. Exceptions

    What needs a person

    Anything outside the rules, with the context and a named owner.

Three runs of the same workflow

The normal path is the easy part. The design is in what happens when it isn't normal.

Run r-2291

  1. Validate

    done

  2. Save state

    done

  3. Request approval

    approved 17:33

    done

  4. Create invoice

    INV-2207

    done

  5. Send invoice

    done

  6. Notify office

    done

Invoice INV-2207 sent at 17:35. Run r-2291 complete.

The brief every workflow answers

Before anything is built, each workflow answers the same seven questions. Here are the answers for the job close-out.
What triggers it?job.completed from scheduling
What identifies one run?The job ID and the event ID
Can it run twice safely?Yes. The invoice is keyed to the job, so a second run finds it instead of creating another
What is saved?The job's close-out state and each step's outcome
What can retry, and what can't?Reads and the keyed invoice can retry; the customer email only if the send record shows it didn't go
What happens after a partial failure?The run stops at the failed step; earlier steps stay done
Who is told, and how is it repaired?The office lead; fix the cause and resume from the failed step

What workflow automation hands off

In

Trigger
event, schedule or request
Record IDs
job, customer, invoice
Rules
limits, approvals, owners
Workflow
save · act · record

Out

Run history
every step's outcome
Updated records
in their own systems
Exceptions
with context and an owner

Worth building when the sequence repeats

Good fit

  • A stable sequence runs repeatedly across systems and people.
  • Each run has an identifiable trigger and owner.
  • A half-finished run would cost something: a missed invoice, a double email.

Not the right fit

  • The process changes constantly or its ownership is disputed. Agree the intended workflow before encoding it.
  • One person, one system, a few times a year.

Where workflows do their work

Next to workflow automation

Questions about workflow automation

Do you build workflows in n8n or in code?

n8n is our usual default for visible business workflows, with business state kept in a database or your system of record. When logic gets code-heavy, volume grows, or long-running reliability becomes critical, we move to Trigger.dev, workers and queues, or Temporal.

What happens if a workflow fails halfway through?

It stops at the failed step with everything before it recorded as done. Someone is alerted, fixes the cause, and resumes from that step, so nothing runs twice.

Can a workflow wait for a person?

Yes. An approval is a state the run waits in, with a named approver and a reminder. When the decision is recorded, the run continues from there.

How is this different from Zapier-style automations?

The tools overlap. The difference is in the design: saved state before acting, a record of every step, rules for retries and duplicates, and monitoring. Without those, a multi-step automation is hard to trust.