The mechanism, made concrete

Rules, events and workflows

Think Visual Basic events, applied to a whole business. Something happens, it has a name, and you can hang your own checklist off it — as data, not code, scoped to everybody or to one customer.

This is the page that answers “but how does it actually know to do that?” It is also the page that explains why the same engine can run a technician’s job, a parts counter’s queue and an estimator’s review without any of them being a special case.

Events on everything

If you ever wired up a button in Visual Basic, you already know this model. Something happens, it has a name, and you can hang your own behaviour off it. We took that idea and applied it to a whole field service business.

The things that happen have names

Not a vague “automation trigger” list of six popular moments. The events follow the shape of the work:

The record lifecycle — OnCreate, OnOpen, OnClose, OnDelete, on customers, sites, equipment, jobs, purchase orders and the rest.
The assignment lifecycle — OnAssign, OnAssignTo, OnUnassign, OnChangeAssignment. This is the one that turns a board column into a queue that does something.
Every status a visit passes through — dispatched, traveling, arrived, working, complete. Each transition is an event, and the statuses themselves are extensible, so a status you invent can be bound to like any other.

They are discoverable, too: the catalogue is something you can list — and so can an agent, which is how an agent can be asked to set a rule up rather than told exactly which one to use.

Zapier waits for your software to do something. We wait for your people to do something.

That is the real difference, and it is why this list is shaped the way it is. A technician taps arrived. A photo lands. A reading comes back out of tolerance. A job is handed to Parts. Those are the moments a service business actually turns on, and none of them is a row changing in a database somewhere.

The technician's job screen showing the travel, work and complete status controls.

A binding is data, not code

A binding says: when this event happens, start that workflow. That is the whole mechanism. An admin adds one from a screen, an integration adds one over the API, and an agent adds one through the matching MCP tool. None of the three involves us.

The rules screen: each row is an event, a scope, and the published workflow it starts, with warnings on rules whose event nothing raises.

No release to wait for

The rule your shop needs on Thursday is a row, not a feature request. You are not in a queue behind somebody else’s roadmap.

Bindings are switched off, never deleted

So the history stays readable. A run that started last March still says which rule started it, even if that rule is no longer active.

Loops are structurally impossible

A workflow that completes, raises a completion event and starts itself would take a system down on the first Friday. A depth limit plus the causation chain is the guard, and it is in the engine rather than in your hands.

A broken rule cannot break the board

The event is recorded in the same transaction as the business change, so it cannot be lost. The handlers run after. A failing workflow never fails the assignment that raised it.

Scope decides who it applies to

“On assign, for the Houston board” and “on assign, everywhere” are different rules, and a system that only has the second one is a system nobody switches on.

Scope	What it is for
Global	The rules that are true of your whole company. Safety, intake, the things a regulator asks about.
Department	Commercial plumbing does not run the residential checklist. Same company, different line of business.
Zone	The P&L centre and its team. A zone can run its own intake without imposing it on the next one.
Board	Inspections work differently from install. A board is a named set of filters, and a rule can follow it.
Customer	CBRE wants photographs of every panel. The dive bar wants you gone by opening. Both are satisfied by the same workflow, scoped.

Contextually alive checklists

Here is the test we hold this to: the difference between two customers must be expressible as data — a scope, a condition, a branch, a custom field — and never as a different version of the software. The moment a trade needs its own code path, the model has failed.

The practical version of that, and the reason it matters on a Tuesday: you do not maintain forty versions of an inspection. You state the rule once over your own data and each job assembles the steps it is owed. Public Storage and Dollar General under the same program want different things, and the job already knows — so nobody keeps a spreadsheet of which form goes with which customer, and nobody discovers on site that they brought the wrong one.

The checklist knows where it is

It reads the job, the site, the customer and the equipment through tokens, so the same SOP renders one way at a CBRE-managed property and another at a restaurant chain, without anyone maintaining two of them.

Custom fields, because every shop is different

“Backflow device serial” on a site is a plumbing field an HVAC shop never sees. Declare it once and it shows up in the checklist, in the tokens that fill your paperwork, and in your reporting.

In real columns, not a blob

Captured answers land in typed fields you can sort, filter by range and total. A field you cannot reach from a spreadsheet is a field we are hiding from you.

What was resolved is kept

A finished run records what its tokens actually resolved to. A document rendered last year still reads the same after the site changes hands — because it was never going to be re-resolved.

By who is holding the phone

Their crew, their role, what they are allowed to sign off. The same job reaches a twenty-year foreman and a first-week apprentice correctly, without two versions of it existing.

By season and by date

The spring maintenance asks what spring asks. Change it once and every future job follows — no ticket, no release, no waiting two quarters for somebody else’s roadmap.

Branch on the answer

Found a leak? The leak questions appear. Nothing wrong? The tech is not marched through twenty irrelevant steps to prove it — which is the thing that teaches a crew to tap through a checklist without reading it.

Finishing hands the job on

The most useful rule most shops write is also the simplest one: when this is done, it goes to them — and their list starts.

The tech completes on the phone

The field workflow closes out with whatever it captured attached to the job.
The job transfers to a column

Parts, Estimate, Billing, Schedule — or nowhere, because do not transfer is a first-class answer. A job that is simply finished must not fall into a default column because nobody said otherwise.
That raises a change-of-assignment event

And the binding on the destination column starts that column’s workflow.
The next person’s checklist is already open

With the field evidence on it. Nobody rang anybody, and nobody had to remember.

Who decides where it goes — and it is not a free-for-all The obvious design is most-specific-wins: the tech’s choice beats the workflow beats a setting. That quietly makes your SOP advisory, because the person the check exists to check can route around it. So instead the workflow declares whether the destination is fixed or a choice. Fixed means it goes there and the handset is told. A choice means the workflow supplies the candidate list and the tech picks from it — which is how a tech’s real knowledge reaches the system without anybody bypassing the rule. A setting supplies the default only where the workflow declines to speak.

The lock is opt-in

A workflow can be marked locking, which means the edits it governs cannot happen outside it. Creating a commercial customer requires running the intake SOP. Changing a tax code requires the change-control SOP.

With no workflows, there are no locks. The system is fully usable on day one and gets stricter exactly as fast as you encode real process. Nobody is handed a locked product and told to configure their way out of it.
It is enforced in the executor, not in the screen. A rule a screen enforces is bypassed by one API call, and then your SOP silently stops applying to precisely the callers that matter most — your integrations and your agents. There is one executor and everything goes through it.
There is a break-glass, and it is audited. A badly-designed lock can wedge a business at four o’clock on a Friday, and a system with no escape hatch gets its locks switched off entirely inside a month. So: audited, reason required, visible.
The field always wins. An office rule that stops a technician recording what is in front of him does not change what happened — it only stops you knowing it, and then the record you sell as proof has a hole in it nobody can see. A run can always record what its own published checklist says it captures.

The why becomes structural

This is the quiet benefit and it is the one people appreciate a year later, in a room with a customer or an insurer.

An ordinary audit trail	An audit trail with a run behind it
Dave changed the tax code at 14:02.	Dave changed the tax code at 14:02, under run 4471, step 3 of New Commercial Customer.
A photo was added to job 40219.	A photo was added satisfying step 6, photograph the failed component, of Found on PM — captured on site, hashed on arrival.
The job was reassigned.	The job transferred to Parts on completion, which is what started the parts checklist — so “why did that workflow run?” has an answer.

The Found on PM workflow in the builder: the steps a technician walks when they find work outside the scope of a maintenance visit, ending in the capture that hands the job to the estimating queue.

Causation is recorded at the moment it happens. It is free at write time and impossible to reconstruct afterwards, which is exactly why most systems do not have it.

See it on your own data What the office gets →