What is the difference between a workflow trigger and a precondition?

A trigger is the event that asks the workflow to evaluate a record. A precondition decides whether the record is eligible to proceed. A status change can trigger a check; consent, ownership, and a complete decision can still block the work.

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.
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.

In Salesforce, keep the trigger thin

When Apex is the right implementation layer, the trigger should identify the transaction event and hand work to a testable service or handler. It should not become the place where every routing rule, integration call, recursion guard, and exception is embedded.

A durable pattern separates five concerns:

1
Trigger identifies relevant record changes
2
Handler collects records and transaction context
3
Eligibility service evaluates business predicates
4
Domain/service layer performs bounded work
5
Job history records outcome + reason

The trigger starts evaluation. The business contract lives behind it where it can be tested and reused.

This matters for more than code cleanliness. Salesforce processes records in bulk, multiple automations can participate in the same transaction, and one write can cause another automation to write again. A design that only works for one record in an isolated UI edit is not production-safe.

Bulk safety is part of the business contract

Design handlers around collections from the beginning. Gather IDs first, query related data once per logical operation, evaluate records in memory, and perform writes in collections. Do not hide per-record queries or DML inside a helper method and call it from a loop; moving the line of code does not change the transaction cost.

The same principle applies to integrations. Decide which work must complete inside the originating transaction and which work can move to an asynchronous boundary. A user save should not become dependent on an unrelated external service unless that dependency is genuinely required for the save to be valid.

Recursion protection should describe the work, not just say “already ran”

A transaction-wide static boolean is tempting because it stops obvious loops. It can also suppress legitimate work when several records or automation paths are processed in the same transaction.

Prefer an idempotent operation or a guard keyed to the meaningful unit of work: record + action, record + rule version, or another explicit run key. Then a second invocation can determine whether it is a duplicate of completed work rather than assuming every second invocation is wrong.

Bypass is an operating control

Large migrations, repair jobs, integrations, and emergency remediation sometimes need a governed way around normal automation. If bypass exists, make it explicit and auditable. Scope it to the narrow capability being bypassed, restrict who can invoke it, record why it was used, and make the default path enforce normal behavior.

A bypass that means “turn automation off” is difficult to reason about. A bypass that means “skip this named rule for this governed operation” can be reviewed and tested.

Test the transaction, not only the method

A useful Salesforce automation test matrix includes single-record and bulk updates, mixed eligible/ineligible records, repeated invocation in one transaction, missing related data, permission failures where relevant, asynchronous handoff, and bypass behavior. Also test that an irrelevant field update produces no business work.

The goal is not merely code coverage. It is proving that the automation still implements the same trigger and eligibility contract under the transaction shapes production will actually create.

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.