Triggers, preconditions, and eligibility

“When a lead becomes qualified, send an email” hides two separate contracts. What event counts as becoming qualified? What must be true before the email is allowed? Split them.

Trigger versus precondition

Concept	Example	What happens when it changes
Trigger	decision.final_outcome changes to route-to-seller	Evaluate the workflow
Preconditions	Consent is active and an owner exists	Continue or stop
Step condition	The handoff has been accepted	Run the next step
Exit condition	The seller records a completed outcome	Finish the workflow

Avoid using a broad “record updated” trigger and filtering inside a script. It creates repeated runs and makes the real start event invisible.

Eligibility checklist

Before the first action, check:

• the subject record still exists and is the expected object;
• the decision is complete and its version is recorded;
• required identity and ownership fields are present;
• consent, suppression, and permission checks pass;
• no active run already owns the same work;
• the action is inside its volume, time, and risk limits; and
• the source values have not changed since the decision was made, or a rerun is required.

Record the first failed condition. Operators need to know whether a run was suppressed, deferred, or broken.

Make re-entry explicit

An update can satisfy a trigger more than once. Choose one policy per workflow:

Policy	Use when	Required record
Once per subject	A single handoff is enough	started_at, completed_at
Once per decision version	The work restarts after a contract change	decision_version
Re-enter after exit	A new event represents a new business need	run_key and exit timestamp

Never rely on the platform's default re-enrollment behavior as the business rule. Write the rule, then configure the platform to match it.

Test the boundary cases

Use records where one condition changes at a time: owner missing, consent withdrawn, duplicate active run, decision version changed, and source updated after evaluation. The expected result for each should be one of continue, suppress, defer, or fail. A successful no-op is a result worth reporting.

Record the eligibility decision

Store more than a boolean. A useful eligibility event includes the subject, trigger, policy version, evaluation time, outcome, and reason code. ineligible_missing_owner is actionable; false is not. The reason code lets operations see whether a workflow is quiet because demand fell or because a prerequisite broke.

Re-evaluate only for a named reason. A meaningful source change, an expired decision, or a manual retry can justify a new evaluation. A background save that changed nothing relevant should not. This prevents duplicate work and makes volume forecasts defensible.

Launch review

Before activation, have the business owner walk through one record that should run, one that should wait, one that should never run, and one that may re-enter later. Confirm the same outcomes in the configured platform. Then monitor eligibility reasons during rollout. An unexpected rise in suppression is often the earliest sign of a field, ownership, or integration problem.

Related: GTM workflow specification template, Exit, suppression, and completion rules, and Consent and DNC architecture.