Chapters · 2 of 8

About 16 min · Lesson and activity

Chapter 2 of 80 complete

Define the Trigger and Preconditions

Write a trigger a person can satisfy honestly, and both halves of the eligibility rule.

See the situation

Start with the situation below. Next, we will work through an example together before you try the activity.

Samir · Workflow operator

The case

A prospect asks to be called back next week

Separate the event that starts work from the eligibility conditions that decide whether it may start.

What the rep does: Logs the call outcome, and nothing else
What follows in this workflow: The scoped callback request is recorded for owner review
Existing restrictions: Preserved unless an authorized, channel- and purpose-specific review changes them
What the rep was not asked to do: Clear unrelated restrictions or infer permission for other outreach
Why it holds: The request, its scope, and authority to change a restriction are recorded separately

Your task

Route the three requests. Then set the scope and repair request for the callback on hold.

Need a little guidance?

You’re done when: The trigger is separate from eligibility and held records remain visible.

Starting a workflow and being allowed to continue are different questions.

Need a reminder? Reopen the worked example

Watch one example first

Logging a callback request is the trigger. Eligibility still checks the callback’s purpose, restrictions, and authority. A request for one call is not permission for every future message.

Why this follows from the evidence

The trigger says when to evaluate; preconditions say whether work may start. Keep the event even when a precondition holds the action.

GTM Lab

Saved locally

Workflow Specification · 0 of 8 sections started

Saved locally to your browser.

Case evidence

A prospect asks to be called back next week

What the rep does: Logs the call outcome, and nothing else
What follows in this workflow: The scoped callback request is recorded for owner review
Existing restrictions: Preserved unless an authorized, channel- and purpose-specific review changes them
What the rep was not asked to do: Clear unrelated restrictions or infer permission for other outreach
Why it holds: The request, its scope, and authority to change a restriction are recorded separately

In the situation above the rep did one thing: described what happened on the call. Build a trigger that asks no more than that, then write both halves of who it applies to.

Workflow workbench

Sort a small eligibility inbox

Put each case into start now, wait for evidence, or exclude. Then preview a callback-only proposal without clearing an unrelated email restriction.

Route the requests

The callback record also has no assigned account owner. Both authorization scope and routing ownership need resolution before this workflow can accept it.

Three records, three different meaningsCompare each statement with its source. The labels show the state of this example.

Qualified request

Usable email · not disqualified · assigned seller

Source: Decision event and CRM record

Not checked

Callback requested

“Call next week about the proposal” · permission scope/owner not yet confirmed

Source: Rep-entered call outcome

Not checked

Removal request

“Please stop emailing me”

Source: Person's recorded request

Not checked

Qualified request · all stated eligibility evidence is present

Callback request · an email opt-out is also on the record; authority/scope review is pending

Removal request · how should it affect eligibility?

If the designated owner confirms the policy, how narrow is the proposed update?

What happens to the unrelated email opt-out?

Who resolves whether the requested scope can be accepted?

Specific repair request while it is on hold

Callback update · proposed only after owner reviewCompare the original state with the proposed change. This preview does not change live records.

Callback update · proposed only after owner review
Item	Before	Proposed	Why
Callback purpose	Request recorded; scope not confirmed	Choose a scope	A request about one purpose should not silently expand.
Email opt-out	Active	Choose what remains unchanged	Unrelated restrictions remain in force unless the designated owner changes them under policy.
Owner	Not confirmed	Name the authority	A schedule or manual trigger can be valid when authorized and auditable.

Callback purpose: BeforeRequest recorded; scope not confirmed; ProposedChoose a scope; WhyA request about one purpose should not silently expand.
Email opt-out: BeforeActive; ProposedChoose what remains unchanged; WhyUnrelated restrictions remain in force unless the designated owner changes them under policy.
Owner: BeforeNot confirmed; ProposedName the authority; WhyA schedule or manual trigger can be valid when authorized and auditable.

Step 1 of 2. You can revisit any step.

Changes save in this browser as you work.

Inspect the example policy saved by this activity

These are the supplied example-plan entries, not another test. Complete the workbench above to save its result.

Which of these should start the inbound follow-through workflow?: A system event with a recorded time, rather than an unlogged manual action.
Eligibility lives outside the workflow, as a stated set. Which conditions belong in it?: A set you can look at and count. Auditable, arguable, and changeable without touching the automation.
Now the half that surfaces the arguments. Which of these belongs in the excluded set?: The already-finished condition is a policy choice rather than a data condition. Chapter 5 defines how this example handles re-entry.
These three look like the trigger. Which handling is right for all three?: Each near miss gets its own handling, decided in advance. Naming them costs one paragraph and prevents the three most likely misuses.

Your place saves as you go.

Chapter 2 of 80 complete