Define the Trigger and Preconditions

There are two ways to start a workflow, and one of them is a trap.

The trap is to make the trigger an instruction. Move the record to this stage so the sequence starts. Check this box to enrol them. Add them to this list when you get off the call. Each of those asks a person to operate the machine, which means the workflow now depends on someone remembering a step that produces no visible value to them. It will be skipped. Not maliciously, and not always, just often enough that the numbers stop meaning anything and nobody can tell you when it started.

The other way is to make the trigger a report of what happened. The rep logs the outcome of the call, honestly, because logging call outcomes is already their job. The system reads it.

The callback commitment

A prospect says “call me back next week.” The rep logs that outcome, and that is the entire ask. Everything else follows: the person is flagged for callback, they leave the cold outreach they were in, they enter a higher-priority follow-up, and a suppression flag that would have blocked calling them gets cleared, because the request to be called back is itself the consent.

Notice what the rep was not asked to do. Not to move the record between lists. Not to remember which sequence outranks which. Not to clear the flag themselves, which they might not even have permission to do. Their job was to describe reality.

That last part deserves saying plainly, because it looks like a shortcut and is not: a workflow event can legitimately change consent state. Consent is not a permanent verdict recorded once and frozen. It is state, and events update it. Someone who asked not to be called and then asked to be called back has told you two things in order, and the second one is more recent.

Eligibility belongs outside the workflow

The common pattern is to put eligibility inside: the workflow starts, and its first step checks whether the person qualifies, and bails out if not. This works, and it makes eligibility invisible. Nobody can see the rule without opening the workflow. Nobody can argue with it. Nobody can tell you how many people it excluded last month.

Put eligibility outside instead, as a stated set. In CRM terms it is usually a list or a saved view with a filter, and the filter is the rule. The workflow enrols whoever is in the set and decides nothing about who belongs there. Now the rule is auditable, arguable, and changeable without touching the automation, and you can look at the set and see who is in it.

Both halves

Write the eligible set, then write the excluded set. Not as the logical complement, which is useless, but as the specific cases somebody will ask about. The decision returned unknown rather than qualified. The person has no email. The person is disqualified. The account has no owner. And the one that surprises people the first time: the workflow has already finished with this person before.

The excluded list is where the arguments live. Writing it is how you have them before launch instead of in the third week, in a thread, with numbers on the line. Chapter 5 settles that last one properly, because it turns out to be a policy question rather than a data one.

The near misses

The last thing a good trigger definition carries is a list of what looks like the trigger and is not. “Remove me, I am not interested” is a suppression, not a callback: same conversation, opposite meaning, and logging it as a callback is worse than logging nothing. “They booked a meeting” is a meeting, and pulling them into a follow-up cadence walks them backwards. “I want to move this person by hand” is not a trigger at all, and if the manual move is happening often enough to matter, the eligibility rule is wrong and should be fixed where it lives.

Naming the adjacent-but-wrong cases is as valuable as naming the trigger, and it costs one paragraph.