Skip to content

Automation & Orchestration

Event-driven automation: nobody should have to notice

A finished job, a signed quote, an approval: each one should start the work that depends on it. When people have to notice the change first, the noticing becomes part of the process. Events announce what happened, and everything waiting on it starts by itself.
Discuss your systemCompare checking hourly with an event ↓
Schedulingjob.completedJ-418 · 15:40evt_8f2cEvent intakevalidate · storeevt_8f2c · already processedClose-out workflowreceivedCustomer surveyreceivedTeam statsreceived

The delay is part of the process

In most businesses, the next step starts when someone sees that the last one happened. The office checks the scheduling board for finished jobs; finance looks for new invoices; someone remembers to send the survey. Every check is a delay, and every forgotten check is a step that didn't happen.

An event turns the change into a signal. Scheduling announces that a job was completed; the workflows that care about it start straight away. Scheduling still owns the job; the event only says what changed, and each consumer decides what to do about it.

Found in an hour, or now

The same finished job, discovered two ways.
Checked every hourEvent58 minjob completed 15:02found 16:00handled 15:0214:0015:0016:0017:00

Hourly checking also costs something when nothing has changed: four checks, one of them useful. Events arrive once, when there's something to say.

What a good event carries

  1. Meaning

    One thing that happened

    Named in the past tense, about one change: job.completed, approval.given. Not “job updated”.

  2. Record

    Which thing it's about

    The ID of the job, customer or invoice, owned by the system that sent it.

  3. Facts

    What consumers need

    Enough for most consumers to act without asking again: location, team, time, whether photos were attached.

  4. Unique ID

    So twice isn't twice

    Every event has its own ID. Deliveries can repeat; the consumer checks the ID and does the work once.

One event, written down

The same names are used by automation and reporting. When the report counts completed jobs and the workflow invoices them, they're counting the same event, so the numbers agree.

job.completed

Means
a technician marked the job finished on site
Record
job ID, owned by scheduling
Carries
job ID, location, team, completed at, photos attached
ID
one per event, used to ignore repeats
Sent by
scheduling
Read by
close-out workflow, customer survey, team stats, reporting

Coordinate, or let them react

Some work needs one workflow in charge; some is better left to each consumer.
Fits whenSteps depend on each other, and failures need a decisionConsumers are independent and failures are simple
ExampleClose-out: approval, then invoice, then sendSurvey and team stats after job.completed
Who knows the stateThe workflow, in one placeEach consumer, for its own part

What event handling hands off

In

Events
webhook, database, application
Contracts
meaning, record, fields
IDs
one per event
Event intake
validate · store · deliver once

Out

Workflow runs
started by the event
Processing record
what was handled, when
Exceptions
events that couldn't be

Worth building when work waits on a change

Good fit

  • Several workflows need to react to the same change.
  • Waiting for someone to notice, or checking on a schedule, creates real delay.
  • The source system can send a trustworthy signal: a webhook or a database change.

Not the right fit

  • A scheduled batch already meets the timing, such as a nightly report.
  • The source can't say reliably that something changed.

Where events do their work

Next to event-driven automation

Questions about event-driven automation

What's the difference between a webhook and an event?

A webhook is one way to deliver an event: the sending system calls a web address when something happens. The event is the meaning: job.completed, with its contract. We verify each webhook, then treat it as an event like any other.

What if our system can't send webhooks?

Then a database change or a frequent, cheap check can produce the event instead. The workflows downstream don't need to know which.

What happens if an event is delivered twice?

Nothing extra. Every event has an ID, and the intake records which IDs it has processed. The second delivery is logged and ignored.

Doesn't this make the system harder to follow?

It can, if every system reacts to everything. We keep an agreed list of events, record what each one triggered, and use a coordinating workflow where steps depend on each other.