Knowledge · Business Operations

    Event-Driven vs Scheduled Automation

    Some automations react to something happening. Others run on a clock. How to choose, why 'nothing happened' needs a scheduler, and the trade-offs of each.

    What is the difference between event-driven and scheduled automation?

    Event-driven automation runs the moment something changes on a record. Scheduled automation runs on a clock, whether or not anything happened. You need both: events catch what did happen, and schedules catch what did not — the unassigned lead, the unsold estimate, the invoice nobody chased.

    Key takeaways

    • Events answer 'something changed'. Schedules answer 'nothing changed, and that is the problem'.
    • Absence of activity can only be detected by something that runs on a timer.
    • Scheduled sweeps need deduplication or they nag the same record every cycle.
    • Event automations are near-instant; scheduled ones are accurate to their interval, not the second.
    • A future-dated action is a queued run, not a rule waiting in memory.

    Event-driven: reacting to change

    An event automation is attached to something happening: a record created, a field changed, a message received, a stage advanced. It runs within moments and it is the right tool whenever the thing you care about is an action someone took.

    The limitation is structural. If nothing happens, no event fires, and the automation is silent. Silence is exactly the failure mode most service businesses lose money to.

    Scheduled: detecting absence

    A scheduled sweep runs at a fixed interval and asks a question about the current state of the world: which leads have sat unassigned longer than the threshold, which estimates are four days old with no reply, which invoices crossed thirty days. Nobody did anything; that is the point.

    Two things make a sweep safe. It must record what it already acted on, so the same record is not escalated on every cycle. And its interval must be honest — a sweep every five minutes means alerts are accurate to about five minutes, not to the second.

    Future-dated work is a third pattern

    'Send this the morning of the appointment' is neither an event nor a recurring sweep. It is a piece of work created now and executed later. The right implementation is a queued run with a scheduled time, picked up by a processor when the time arrives.

    Storing it as a queued record rather than a timer in memory is what makes it survive restarts, makes it visible before it runs, and makes it cancellable.

    Choosing the pattern

    CapabilityNeedPatternLatencyMain risk
    React to a status changeEvent-drivenSecondsEvent never emitted
    Chase inactivityScheduled sweepUp to one intervalRepeat nagging without dedupe
    Send at a specific future timeQueued runProcessor cycleQueue backlog delays it
    Periodic reportingScheduledIntervalRuns on stale data if upstream is late

    Where URBLD fits

    URBLD uses all three. Record events emit immediately from the workspace; sweeps run on an interval and keep state so the same record is not escalated twice; and future-dated work is stored as an automation run with a kind, payload and scheduled time, picked up by the queue processor when due.

    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