Week 5 of 8

Workflows, Automations, and Triggers

Only now do you build automations. With pipelines, tags, communication, and calendars in place, workflows have something to stand on.

A trigger is the event that starts a workflow. An action is what the workflow does. A stop condition is what makes the workflow release the contact.

Every workflow should have one clear trigger, a clear job, a clear end, and a name that a future team member can read and understand without opening it.

This is the week where most people want to move fast. Do not. A workflow is not the place to invent your business process. A workflow should only connect the pipeline, tags, communication points, calendars, and timing rules that were already planned in Weeks 1 through 4.

Why This Matters

Workflows built without structure fire against each other, tag contacts wrong, and cause the exact chaos automation was supposed to solve.

What Usually Goes Wrong

Multiple workflows triggered by the same event with conflicting actions
No test contact used before going live
Wait steps with no stop condition, so contacts loop forever
Vague names like 'Follow Up 2' that no one can maintain
Duplicate workflows created because no one searched first
A single 'do everything' workflow that no one can safely edit

Trigger Types to Know

Form or survey submitted

Best for capturing new leads from a specific form.

Appointment booked / status changed

Best for confirmations, reminders, and no-show follow-up.

Pipeline stage changed

Best for stage-driven follow-up (proposal sent, won, lost).

Tag added or removed

Best for cross-workflow handoffs and manual triggers.

Contact created

Use sparingly. Fires on every import. Almost always needs a filter.

Inbound message received

Best for auto-replies and routing.

Customer replied

Best for stopping follow-up, routing replies, creating tasks, or notifying the team.

Order form submitted or payment received

Best for post-purchase onboarding, receipts, fulfillment, or internal handoff.

Document signed

Best for contract follow-up, onboarding, or client-start workflows.

Missed call

Best for missed-call text-back, internal alerts, and urgent follow-up.

Manual trigger

Best for team-controlled actions when automation should not decide by itself.

Note

Do not use broad triggers just because they are easy. The broader the trigger, the more carefully it needs filters, stop conditions, and testing.

Trigger Safety Rules

A trigger decides who enters a workflow. That makes it one of the most important decisions in the build.

Use specific triggers whenever possible. A form-submitted trigger with the correct form selected is safer than a broad contact-created trigger.

Use filters when the trigger could apply to more than one situation.

Be careful with triggers that fire from imports, bulk edits, tag changes, or stage changes. These can accidentally add many contacts to a workflow at once.

Before publishing any workflow, ask:

?What exactly causes this workflow to start?
?Could this trigger fire from an import?
?Could this trigger fire from a manual team action?
?Could another workflow apply the same tag or stage and accidentally trigger this one?
?Could the contact enter this workflow more than once?
?Should the contact be allowed to re-enter?
?What should prevent the contact from entering?

Workflow Naming Convention

A readable name tells you the trigger, the job, and the audience without opening the workflow.

Good examples

sales - new-lead form - confirmation + nurture
appointments - booked - reminders
appointments - no-show - 2h follow-up
onboarding - client-won - kickoff sequence

Bad examples

Follow Up 2
New Workflow (1)
Test
Copy of Copy of Nurture

Workflow Folder and Status Rules

As the account grows, workflow organization matters.

Use folders to group workflows by purpose, such as:

Lead Capture
Appointment Follow-Up
Sales Pipeline
Onboarding
Client Communication
Reactivation
Internal Notifications
Testing / Drafts
Archived / Disabled

Note

Keep draft and testing workflows clearly separated from live workflows. Avoid leaving temporary workflows active. If a workflow is no longer used, archive it, disable it, or move it into a clear cleanup folder. A future team member should be able to open the workflow list and understand what is live, what is being tested, and what should not be touched.

Stop Conditions and Exits

A stop condition protects the contact experience. It prevents the CRM from continuing a sequence after the goal has already been reached.

Baseline rules:

If the goal was 'book a call', stop the workflow the moment the contact books.
If the goal was 'get a reply', stop the workflow when the contact replies.
If the goal was 'move to next stage', stop the workflow on stage change.
Always allow unsubscribe and STOP to remove the contact from every marketing workflow.
If the contact books an appointment, stop the pre-booking nurture.
If the contact replies, stop the unanswered-lead follow-up.
If the opportunity moves to Won, stop sales follow-up.
If the opportunity moves to Lost / Not a Fit, stop sales follow-up and move to the appropriate nurture or archive path.
If the contact unsubscribes, stop marketing communication.
If the contact is marked do-not-contact, stop outbound messaging.

Note

Every workflow should answer two questions: What is the goal of this workflow? What event proves that goal has been met or is no longer relevant?

Workflow Ownership Rules

Every workflow should have a clear owner and a clear purpose.

Before a workflow goes live, define:

?Who owns this workflow?
?What business process does it support?
?What trigger starts it?
?What contact type should enter it?
?What contact type should not enter it?
?What does the workflow change?
?What messages does it send?
?What internal notifications does it send?
?What pipeline stage, tag, or field does it depend on?
?What stops it?
?When should it be reviewed?

Note

If no one owns a workflow, no one maintains it. That is how workflow chaos starts.

Simple Core Workflow Example

Here is a clean new-lead workflow example:

Trigger: Specific form submitted

Filter: Form is Consultation Request

Actions:

Apply source tag
Create or update opportunity in New Lead stage
Send immediate confirmation email
Send internal notification to assigned user
Wait 1 day
If appointment booked, remove from this workflow
If not booked, send follow-up email
Wait 1 day
If customer replied, create task for team follow-up
If no reply and no booking, send short SMS reminder if consent exists
After immediate follow-up ends, hand off to long-term nurture

Note

This workflow works because the pieces already exist: the pipeline, tags, communication map, calendar, and timing rules.

Testing Before You Turn It On

Test the exact trigger the real contact will use. If the workflow starts from a form, submit the form. If it starts from a calendar booking, book the calendar. If it starts from a tag, apply the tag exactly the way it will be applied in real use.

Test both success paths and failure paths.

Use a dedicated test contact you own.
Walk the contact through the full trigger, not a manual add if the real trigger is a form.
Confirm tags, opportunity, notification, and every message land as expected.
Check the workflow history log for skipped or errored steps.
Only then publish to real leads.

Success paths to verify

The contact receives the right message
The internal team receives the right notification
The opportunity moves correctly
Tags and fields update correctly
The contact exits when the goal is met

Failure paths to verify

The contact does not book
The contact replies
The contact unsubscribes
The contact no-shows
The message fails
The contact already exists
The contact enters twice
Another workflow also fires

Do not trust a workflow until the history log proves it works.

What to Build

A short list of core workflows the business needs
One clear purpose for each workflow
One clear trigger per workflow
Filters for broad triggers
Clear actions in the correct order
If/else branches for common paths
Stop conditions and exit logic
Unsubscribe and STOP handling
A workflow naming convention
Workflow folders or organization rules
A test contact used for every launch
A workflow owner or reviewer
A documented review schedule

Before You Build in the CRM

Plan the workflow before opening the workflow builder. A workflow should not be built by dragging actions around until it “looks right.” Write the logic first.

Start outside the CRM. Use a document, spreadsheet, whiteboard, Figma board, or your preferred AI assistant to map the workflow. Put the trigger at the top, then map each action, wait step, condition, stop point, and handoff.

Your workflow plan should answer:

?What is the purpose of this workflow?
?What exact trigger starts it?
?What filters are required?
?Who should enter this workflow?
?Who should not enter this workflow?
?Can a contact enter more than once?
?Should re-entry be allowed?
?What tags, fields, or pipeline stages does this workflow depend on?
?What message is sent first?
?What internal notification is sent first?
?What wait steps are needed?
?What if/else branches are needed?
?What stops the workflow?
?What happens if the contact replies?
?What happens if the contact books?
?What happens if the contact becomes a client?
?What happens if the contact unsubscribes?
?What happens if an action fails?
?Who owns reviewing this workflow later?

Note

Suggested AI prompt: “I am planning a CRM workflow before building it. Help me map the trigger, filters, actions, wait steps, if/else branches, messages, internal notifications, pipeline updates, tags, fields, stop conditions, unsubscribe handling, reply handling, and testing steps. Point out any duplicate triggers, missing stop conditions, risky broad triggers, or places where a human handoff is better than automation. Keep the workflow simple enough for a team to maintain.” If the workflow cannot be explained outside the CRM, it is not ready to be built inside the CRM.

Step-by-Step Training

1
List the core workflows your business needs.
2
For each workflow, define the business purpose.
3
Choose the exact trigger.
4
Add filters if the trigger is broad.
5
Decide who should enter and who should not enter.
6
Draft the actions in order.
7
Add tags, fields, opportunity updates, internal notifications, and tasks.
8
Add wait steps only where timing is intentional.
9
Add if/else branches for booked vs not booked, replied vs not replied, won vs lost, or showed vs no-show.
10
Add stop conditions and remove-from-workflow steps.
11
Add unsubscribe, STOP, and do-not-contact safeguards where needed.
12
Name the workflow using the naming convention.
13
Place the workflow in the correct folder.
14
Test with a dedicated test contact using the real trigger.
15
Check the workflow history log.
16
Test success paths and failure paths.
17
Confirm no duplicate workflow fires at the same time.
18
Publish only after the test is clean.
19
Document the workflow purpose, owner, and review date.

Practical Exercise

Part 1: Audit Existing Workflows

Open the workflow list and look for:

1
Duplicate workflows firing on the same trigger
2
Workflows with no stop condition
3
Workflows with generic names
4
Workflows that were temporary and never turned off
5
Contacts stuck in wait steps for weeks
6
Workflows using contact-created as a broad trigger without filters
7
Workflows that send messages but do not update pipeline stages
8
Workflows that update tags but no one knows why
9
Workflows with no owner
10
Workflows that no one has tested recently

Part 2: Build One Core Workflow Cleanly

Build a new-lead workflow using this structure:

1
Set the specific trigger and filters
2
Apply the correct source tag
3
Create or update the opportunity
4
Send the confirmation email
5
Send the internal notification
6
Add the wait step
7
Add if/else for booked vs not booked
8
Add if/else for replied vs not replied if needed
9
Add stop conditions
10
Add unsubscribe and do-not-contact safeguards
11
Name it using the convention
12
Place it in the correct folder
13
Run a full test with a test contact
14
Review the history log

Part 3: Test the Workflow Like a Real Contact

Test what happens when:

1
The contact submits the form
2
The contact books
3
The contact does not book
4
The contact replies
5
The contact unsubscribes
6
The contact already exists
7
The contact enters twice
8
Another workflow might also trigger
9
The internal notification needs to reach the team
10
The opportunity needs to move stages

Done Means Done Checklist

✓The workflow has one clear purpose
✓The workflow has one clear trigger
✓Broad triggers have filters
✓The workflow is named using the convention
✓The workflow is in the correct folder
✓The workflow owner is documented
✓A test contact has been used end to end
✓The real trigger was tested
✓Tags apply correctly
✓Fields update correctly where needed
✓The opportunity is created or updated correctly
✓Internal notifications are tested
✓Emails and SMS are tested on desktop and mobile
✓Wait steps are intentional
✓If/else branches are tested
✓Stop conditions are included
✓Unsubscribe and STOP behavior is respected
✓Do-not-contact logic is respected where applicable
✓No duplicate workflows are firing on the same trigger
✓The workflow history log has been reviewed
✓The workflow purpose and review date are documented

Common Mistakes

Watch for these

Turning a workflow live without testing
Using 'contact created' as a trigger for everything
Forgetting to remove a contact from a nurture after they book
Stacking three welcome emails from three different workflows
Editing a live workflow instead of duplicating and testing
Using broad triggers without filters
Creating a workflow to fix another broken workflow
Forgetting to test the real trigger
Forgetting to test re-entry behavior
Letting contacts stay in wait steps forever
Not checking the workflow history log
No workflow owner or review schedule
Adding too many jobs to one workflow
Using automation when a human handoff is safer
Publishing before testing failure paths

Related SOPs

Workflows
Pipelines and Opportunities
Tags and Custom Fields
Calendars
Conversations
Cleanup and Audit

Next lesson

Week 6: Contact Importing and Data Hygiene

Start Week 6