Knowledge · Business Operations

    Trigger, Condition, Action and Outcome

    Every automation has four parts and they fail differently. How to separate what starts a rule, what filters it, what it does, and what actually happened.

    What are the parts of an automation rule?

    An automation has four parts: a trigger (the event that starts it), conditions (filters that decide whether it applies), actions (the ordered steps it performs), and outcomes (what actually happened to each step). Configuring the first three is design. Reading the fourth is operations, and most teams skip it.

    Key takeaways

    • The trigger is an event, not a state — 'status changed to X', not 'status is X'.
    • Conditions exist to stop a rule firing on records you never meant to touch.
    • Actions are ordered, and one failing does not undo the ones before it.
    • The outcome is a separate fact from the action being attempted.
    • Configured intent and verified result are different things and must be stored separately.

    The trigger: what starts the rule

    A trigger is a discrete event: a lead was created, a status changed, a message arrived, a stage was reached, a timer elapsed. It fires once, at a moment in time, against one record. This matters because a rule triggered by an event will not retroactively apply to records that were already in that state before the rule existed.

    The most common design mistake is confusing an event with a condition. 'Lead is unassigned' is not a trigger; it is a state. 'Lead has been unassigned for thirty minutes' is a trigger, because something has to check the clock and emit an event.

    Conditions: the filter that keeps it sane

    Conditions decide whether the triggered event deserves the actions. Good conditions are typed and specific — a particular pipeline, a particular assignee, a defined status list, a keyword match, a numeric threshold — because a vague condition is how a rule ends up texting a customer who called to complain.

    Every condition you add reduces the blast radius. Every condition you omit widens it. Write conditions as if the rule is going to fire ten thousand times, because eventually it will.

    Actions: ordered, independent, and not transactional

    Actions run in order. Each one either succeeds, fails, or is skipped. What they do not do is roll back: if action three fails, actions one and two already happened. A task was created; an email left the building. There is no undo for a message a customer has already read.

    That has a direct design consequence — put internal, reversible actions first and external, irreversible actions last. Create the task and update the record before you send anything outside the company.

    Outcomes: eight facts people collapse into one

    • Configured intent: the rule exists and is enabled.
    • Trigger detection: the event was actually observed.
    • Queued work: the run was created and is waiting.
    • Attempted execution: the system tried to perform the action.
    • Accepted request: a provider took the request from us.
    • Persisted result: the outcome was written to the record.
    • Verified outcome: the real-world effect was confirmed.
    • Downstream side effects: other rules and notifications this one set off.

    Where each part fails

    Different parts of a rule fail in different ways, and the fix is never the same.

    CapabilityPartTypical failureWhat you seeWhere to fix it
    TriggerThe event was never emittedNo run at allThe process that should emit the event
    ConditionToo broad or too narrowFires on the wrong records, or neverThe rule configuration
    ActionThe step errored mid-listPartial completionAction order and the failing integration
    OutcomeAttempt recorded as successFalse confidenceReading the persisted result, not the attempt

    Where URBLD fits

    URBLD rules store the trigger event, typed conditions and an ordered action list separately from the execution record. Each run persists per-action results — success, failure or skipped — alongside the automation name, trigger event, status and duration, so a partially completed run is visible as exactly that.

    Principles reinforced

    This page rests on the following foundational ideas.

    FAQ

    Frequently Asked Questions

    Straight answers about how URBLD runs the business end-to-end.

    More in Business Operations

    The daily mechanics: workflows, checklists, scheduling and handoffs.

    Browse Business Operations
    Share this page