Workflow Triggers: What Starts Work and Why It Matters

A workflow trigger is the defined event that starts a workflow — the moment a piece of work enters the path and becomes something the workflow is responsible for. A form submission, an approved offer, an arriving invoice, a ticket opened, a date reached. Without a trigger, work doesn't enter a workflow; it accumulates somewhere and gets noticed eventually.

Of the five properties that make something a workflow — trigger, sequence, handoffs, ownership, completion — the trigger gets the least attention and determines the most. It decides what work the workflow knows about, when the clock starts, and whether any of your measurement means anything. Teams that structure their stages carefully and leave their trigger undefined end up with a well-organized path that only governs the work that happened to find it.

What a Trigger Actually Does

Three jobs, and they're easy to conflate.

It marks entry. The trigger is the boundary between "this exists somewhere" and "this is in the workflow." Before it, the request is a message in someone's inbox or a conversation in a hallway. After it, the work has a record, a position, and an owner.

It starts the clock. Lead time is measured from the trigger. This is why a vague trigger makes measurement meaningless: if the official trigger is "request logged" but requests routinely sit in an inbox for three days before logging, your lead time excludes the three days the requester experienced most acutely.

It determines what the workflow is accountable for. Work that never triggered the workflow is not the workflow's problem — which sounds like a technicality and is actually the main source of the "but I asked for that weeks ago" conversation. The request was made; it just never entered.

The Gap Between the Official Trigger and the Real One

Nearly every workflow has two triggers: the one that's documented, and the one that actually starts work. The distance between them is where most intake pathology lives.

The documented trigger is usually clean — a request is submitted through the intake form. The real trigger is often messier: someone mentions a need in a meeting, a colleague forwards an email, a manager asks in passing. Work begins. It may get logged later, retroactively, with a timestamp that bears no relationship to when it actually started.

This gap produces four effects, all bad:

• Measurement that flatters. Cycle time looks fine because the clock started after the hard part of the wait.

• Invisible work. Items that never got logged aren't in any count, so capacity and demand are both understated.

• Unpredictable priority. Work that enters informally is prioritized by who asked rather than by any rule, which erodes trust in the formal path and pushes more requesters toward informal channels.

• Surprise emergencies. The request made three weeks ago in a channel nobody tracks, surfacing as urgent.

The diagnostic is straightforward: take a sample of completed items and ask when someone first learned about each one, then compare to the recorded trigger timestamp. The difference is the size of your gap.

Types of Triggers

Event-based. Something happens: a form is submitted, a payment fails, a candidate accepts, a system raises an alert. The most common type and the easiest to make precise, because the event itself is a record.

Time-based. A date or interval arrives: month-end close, quarterly reviews, renewal windows, scheduled maintenance. Precise by nature, but worth watching for a specific failure — time-based triggers fire whether or not anyone is ready, so they tend to accumulate a backlog that the trigger itself doesn't acknowledge.

State-based. A condition becomes true: inventory drops below a threshold, an item ages past a limit, a metric crosses a boundary. Powerful, because state-based triggers catch things nobody would have thought to report. Also the type most likely to be missing — most "we should have caught that earlier" situations are a state-based trigger that doesn't exist.

Request-based. A person asks. The most common trigger in knowledge work and the hardest to make precise, because asking is a social act that can happen anywhere. Nearly all intake pathology lives here.

Upstream completion. Another workflow finishing triggers this one. Clean when the handoff between workflows is explicit, and a common place for work to vanish when it isn't — each workflow considers the item someone else's.

Making a Trigger Precise

Four questions. If you can answer all four, your trigger is defined.

1. What exactly is the event? Not "a request comes in" but "a submission is received through [channel]." The test: could two people independently look at the same situation and agree on whether the trigger fired?

2. Through which channels does it count? A trigger that fires through one channel and a request culture that uses five means four-fifths of your work enters informally. Either consolidate the channels or make the additional ones real triggers that create real records.

3. What information must accompany it? The trigger is the only moment you have the requester's attention. What's captured here determines whether every downstream stage can act or must first go back and ask. Capture what downstream stages actually need — determined by asking them what they most often have to request — and nothing beyond it, since long forms push people to informal channels and recreate the gap.

4. Who or what is responsible for firing it? Automatic triggers fire reliably. Human-dependent triggers fire when someone remembers, which means they sometimes don't. If a trigger depends on a person taking an action, that person needs to know it's their job.

Common Trigger Problems

Multiple undocumented entry points. The most common. Work arrives through form, email, chat, meetings, and hallway, and only the first produces a record. Fix: either consolidate or formalize — a shared inbox that auto-creates records turns an informal channel into a legitimate trigger.

The trigger that requires a human to notice. State-based conditions monitored by attention rather than by rule. "We'll see when inventory gets low" works until the week everyone is busy. Fix: automate the detection, even if the response stays human.

Triggers that fire too late. The workflow starts at approval, but the real work — scoping, negotiating, clarifying — happened for two weeks before approval, unowned and unmeasured. Fix: move the trigger earlier, or acknowledge the pre-trigger period as its own workflow with its own owner.

Triggers that fire too early. The opposite: the workflow accepts work before it's actionable, and items enter and immediately stall waiting for information or decisions. This inflates WIP with work that can't move and makes the first stage look like a bottleneck when it's really an intake quality problem. Fix: add entry criteria — not more approval, just a minimum of what must be known for work to start.

No trigger at all. Some work genuinely has no defined entry: ongoing responsibilities, improvement work, maintenance. These tend to be squeezed out by triggered work, because triggered work announces itself and untriggered work doesn't. Fix: give it a time-based trigger, which is often the only way standing work competes for attention.

Why This Is Worth the Attention

Everything downstream inherits the trigger's quality. Clean triggers make lead time real, give prioritization a basis, and let the workflow account for all of its work. Vague triggers produce a workflow that governs the subset of work that happened to enter it properly, measures that subset flatteringly, and leaves everyone with the sense that the real work happens somewhere outside the system.

That's also the fix order worth noting. If you're improving a workflow and the trigger is undefined, start there — before stages, before automation, before measurement. A path with a precise entry point and rough stages is manageable. A path with immaculate stages and an ambiguous entry point isn't, because you can't manage work you don't know you have.

FAQ

What is a workflow trigger? The defined event that starts a workflow and brings a piece of work under its control — a form submission, an approved request, a threshold being crossed, a date arriving. It marks entry, starts the clock for measurement, and determines what work the workflow is accountable for.

What are the types of workflow triggers? Event-based (something happens), time-based (a date or interval arrives), state-based (a condition becomes true), request-based (a person asks), and upstream completion (another workflow finishes). Request-based triggers are the most common in knowledge work and the hardest to make precise, which is why most intake problems originate there.

Why do workflow triggers matter for measurement? Lead time is measured from the trigger, so an imprecise trigger makes the number meaningless. If work routinely begins informally and is logged days later, the recorded timeline excludes the portion of the wait the requester actually experienced — which is how cycle times can look healthy while requesters are frustrated.

What happens when a workflow has multiple entry points? Only the formal one produces records, so work entering elsewhere is invisible to counts, capacity planning, and prioritization — surfacing later as surprise emergencies. The fix is to consolidate channels or formalize the additional ones so they create records too.

Should a workflow trigger be automated? Where possible, yes — automatic triggers fire reliably, while human-dependent ones fire when someone remembers. The clearest case is state-based conditions: monitoring thresholds by attention rather than by rule works until the week everyone is busy. The detection can be automated even when the response stays human.