Every automation has three components: a trigger (what starts it), criteria (what qualifies it to run), and an outcome (what it does). Most business owners think through automations forwards but forget to think backwards, which is how "Scenario D" sneaks in and creates chaos.

Understanding this framework before you build anything is the difference between automations that save 10 hours a week and automations that delete your contact list.

Here's something I've learned after years of building automations across industries: the tool is rarely the problem. HubSpot, Salesforce, Zapier, Make—they all work. The problem is that most automations get built without understanding what an automation actually is.

And when you don't understand the components, you end up with automations that work perfectly for Scenarios A, B, and C... until surprise Scenario D shows up and everything breaks.

I'm going to empower you to make better decisions before that happens.

 A computer is just going to follow instructions; two plus two equals four. If it breaks down, it's usually the human element not thinking it all the way through.

Before you can design requirements or test anything, you need to understand what you're actually building. Every automation, whether it's a simple Zap or a complex Salesforce flow, has three components:

1. The Trigger
​
The trigger is the action that causes the automation to fire. Same as pulling the trigger on a gun, something has to cause the bullet to leave.

Triggers can be manual (someone clicks a button) or automated (a form is submitted, a deal is marked "closed won," a date arrives). The trigger is simply the starting point; the "go" signal.

2. The Criteria
​
This is where most automations get sloppy.

Criteria defines what qualifies or disqualifies the automation from running a specific path. It's the logic that says: "If this type of situation, do this. If that type, do something else. If another type, do nothing."

​For example, your trigger might be "opportunity marked closed won." But what happens next depends entirely on the criteria:

 Join the Winning Business Vault to get instant access to the full Building Bulletproof Automations mini‑course.

Before building any automation, write out your trigger, criteria, and outcome in plain English first. If you can't explain it simply, the automation won't work simply either. This 5-minute exercise saves hours of debugging later.

I used to call myself the "wizard behind the curtain," the person who made the magic happen in the background. But I realized the hardest part of my job isn't building the automation. It's that people fundamentally don't understand what I'm building.

This framework: trigger, criteria, outcome, is the foundation.

Once you understand these three components, you can look at any automation and actually see what's happening. You can spot gaps. You can ask better questions. You can avoid the disasters that come from "Scenario D."

​This is Part 1 of a three-part series. In Part 2, we'll cover how to define requirements for your automation, including my 95/5 Rule that helps you decide what should (and shouldn't) be automated in the first place.

Q: What's the most common mistake people make when building automations?

A: Not defining criteria clearly enough. They build for the obvious scenarios and forget that edge cases exist. The automation works great until it doesn't—and by then, it's usually caused damage.

Q: Can I build automations without technical skills?

A: Yes, tools like Zapier and Make are designed for non-technical users. But understanding this framework matters more than knowing how to use the tool. A well-designed automation in a simple tool beats a poorly-designed one in a sophisticated platform.

Q: How do I know if something should be automated?

A: Great question—that's exactly what we cover in Part 2 with the 95.5 Rule. The short answer: if more than 5% of cases are exceptions, automation might create more problems than it solves.

Q: What's the difference between a trigger and criteria?

A: The trigger is what starts the automation (the "go" signal). Criteria is what happens after the trigger, the logic that determines which path to take. Same trigger can lead to completely different outcomes based on criteria.

Q: How do I identify "Scenario D" before it causes problems?

A: Think backwards, not just forwards. Ask: "What situations would make this automation do the wrong thing?" We'll cover specific testing strategies in Part 3 of this series.