Trigger-Based Workflows

Everything Starts With "When"

Every workflow needs a starting gun. That's the trigger — the moment that sets everything in motion. Without a trigger, you still have a checklist. With one, you have automation. The question isn't "what do I need to do?" It's "when does this need to happen?"

Triggers turn passive processes into reactive systems. Instead of you checking for new orders every hour, the system watches and acts the instant one arrives.

Choosing Your Trigger

Triggers in Practice

A freelance designer gets a new inquiry through their website form. That form submission is an event trigger. It kicks off a workflow: AI categorizes the project type, checks the designer's availability in their calendar, drafts a personalized response with estimated timeline and pricing, and sends it — all within 60 seconds of the inquiry landing.

The designer didn't check their inbox. Didn't draft a reply. Didn't look at their calendar. The trigger handled the first response, and the designer steps in only when it's time for the creative conversation.

Webhooks: The Backbone of Event Triggers

Most modern tools communicate through webhooks — small HTTP requests that fire when something happens. A payment processor sends a webhook when a charge succeeds. A CRM sends one when a deal moves stages. Your workflow platform listens for these signals and springs into action.

You don't need to understand the deep technical layer yet. Just know this: if a tool has webhooks, it can trigger a workflow. And almost every modern tool has webhooks.

Compound Triggers and Trigger Chains

Real-world workflows often need more than a single trigger. A compound trigger requires multiple conditions to be true simultaneously: "When a new order arrives AND the order value is above $500 AND the customer is new." All three conditions must be met before the workflow fires.

A trigger chain is when one workflow's completion triggers another workflow. The customer signs up (Workflow A triggers), onboarding completes (Workflow B triggers), and 7 days later a feedback request fires (Workflow C triggers). Each workflow is independent but connected through a chain of events.

Preventing Runaway Triggers

A trigger without guardrails is dangerous. What happens when your webhook fires 10,000 times in a minute because of a duplicate event bug? Or when a condition-based trigger gets stuck in a loop — the workflow updates a database field, which triggers the same workflow again, which updates the field again, forever?

Deduplication: Track event IDs and skip duplicates. If you've already processed event evt_abc123, ignore the second delivery.

Rate limiting: Cap how many times a workflow can fire per minute. If your customer signup workflow fires more than 100 times per minute, something is probably wrong — pause and alert.

Loop detection: If a workflow modifies the same data that triggers it, add a "processed" flag. Only fire on records where processed = false, and set it to true as the first step.

Kill switch: Every production workflow should have a way to instantly disable its trigger without deleting the workflow. A simple boolean flag in your config — workflow_enabled: true/false — can prevent catastrophic runaway scenarios.

Triggers Across Popular Platforms

Different platforms offer different trigger capabilities. Knowing what's available helps you choose the right tool:

When Your Workflow Doesn't Fire

The most frustrating debugging experience: you set up a workflow, the trigger should have fired, but nothing happened. Here's a systematic approach to diagnosing trigger failures:

Check 1: Did the event actually occur? Verify in the source system that the event happened. Check the webhook delivery logs (most platforms show recent webhook deliveries and their HTTP status codes). If the event didn't fire, the problem is upstream.

Check 2: Did the webhook arrive? Check your endpoint's request logs. If you're using a custom server, add logging to the webhook handler. If using a platform like Make or Zapier, check their execution history. No request means a network or URL issue.

Check 3: Did the payload match your expectations? Even if the webhook arrives, the data might be structured differently than your workflow expects. Log the raw payload and compare it to your code's expectations. A field named customer_email vs. email will silently break everything.

Check 4: Did a filter block it? If you have conditions on your trigger (only fire for orders over $50), verify that the event data actually meets those conditions. Often the data is there but doesn't pass the filter.

Pro tip: during development, always start with the simplest possible trigger — no filters, no conditions. Verify the basic connection works first. Then add complexity one condition at a time. Debugging a simple trigger is trivial. Debugging a compound trigger with three conditions and a filter is a nightmare.

When Timing Matters More Than Events

Some workflows depend heavily on when they run, not just what triggers them. A weekly report generated at 9am Monday has a different value than one generated at 5pm Friday. Time-based triggers need careful consideration of timezone, business hours, and recipient expectations.

Always specify timezone. "Every Monday at 9am" means nothing without a timezone. Is that 9am EST? PST? UTC? If your team spans multiple timezones, decide whether the workflow fires once (in the company's primary timezone) or multiple times (once per timezone).

Consider business calendars. A workflow that runs "every business day" needs to know about holidays. Most scheduling libraries support calendar exclusions — add your company's holiday schedule so workflows don't fire on Christmas morning.

Avoid the top of the hour. Everyone schedules cron jobs at :00. This creates traffic spikes on APIs and databases. Schedule your time-based triggers at odd minutes (:07, :23, :41) to avoid congestion.

Trigger Design Checklist

Before deploying any trigger to production, verify these five things:

1. Idempotency: If the same event fires twice, does your workflow handle it gracefully? Or does it create duplicate records, send duplicate emails, or charge a customer twice? Design every workflow to be safely re-runnable.

2. Failure mode: If the trigger fires but the workflow fails mid-execution, what happens to the data? Is it lost, or can you retry from where it left off?

3. Volume expectations: How many times per day/hour/minute will this trigger fire? Does your downstream processing handle that volume?

4. Monitoring: How will you know if the trigger stops firing? A trigger that silently fails is worse than one that fails loudly.

Triggers in real code.

Here are all four trigger types as actual Python code you can run:

from fastapi import FastAPI, Request

app = FastAPI()

@app.post("/webhook/new-customer")
async def handle_signup(request: Request):
    """Event trigger: fires when a customer signs up."""
    data = await request.json()
    customer_email = data["email"]
    customer_name = data["name"]

    # Workflow starts here
    send_welcome_email(customer_email, customer_name)
    add_to_crm(customer_email, customer_name)
    notify_sales_team(customer_name)

    return {"status": "workflow triggered"}

from apscheduler.schedulers.blocking import BlockingScheduler

scheduler = BlockingScheduler()

@scheduler.scheduled_job("cron", day_of_week="mon", hour=9)
def weekly_report():
    """Time trigger: every Monday at 9am."""
    data = fetch_weekly_metrics()
    report = generate_report_with_ai(data)
    send_to_slack("#team-updates", report)

@scheduler.scheduled_job("interval", minutes=5)
def check_inventory():
    """Condition trigger: check every 5 min, act when threshold hit."""
    stock = get_inventory_levels()
    low_items = [i for i in stock if i["quantity"] < 50]
    if low_items:
        alert_purchasing_team(low_items)

scheduler.start()

Event triggers react instantly via webhooks. Time triggers run on a schedule. Condition triggers combine scheduled checking with threshold logic. Manual triggers are just API endpoints you call when you choose.

Lesson 3 Quiz