Most automation tools present a screen with a “when” box and a list of things to do. Underneath that identical-looking interface sit three genuinely different mechanisms, and which one your automation uses decides what it can promise you.
The mechanisms are events, schedules and polling. They differ in how the automation finds out that work is needed, and that single difference drives delay, cost, and what happens when the system is busy.
Event, schedule and poll are three different answers to one question
The question is: how does the automation learn that something needs doing?
An event means the change announces itself. A deal moves to won, and the act of saving that change notifies the automation. The automation did not ask. It was told.
A schedule means the automation runs at fixed times whether or not anything happened. Every Monday at nine. On the first of the month. Nothing needs to have changed for a scheduled run to occur.
Polling means the automation asks, repeatedly, whether anything has changed since it last looked. Every minute, a query. Almost every one of those queries finds nothing.
| Mechanism | Starts because | Typical delay | Work done when nothing happened | Can it miss a change? |
|---|---|---|---|---|
| Event | The change itself | Immediate | None | Only if the notification is lost |
| Schedule | The clock | Up to one interval | A full run | Yes, if it looks at current state rather than history |
| Polling | The clock, then a query | Up to one interval | A query per check | Yes, if two changes happen between checks |
The last column is the one that decides architectures. A scheduled or polled check sees the state at the moment it looks. If a ticket was opened and closed between two checks, the check sees nothing, and the automation that should have run never learns that it should have. An event cannot have that problem, because the event is the change, not a later observation of it.
Triggers, conditions, actions
Every automation, whatever mechanism starts it, has the same three parts. Separating them is the single most useful mental model for building automations that behave.
The trigger is when. It is the thing that starts the run: a record created, a status changed, a target breached, a time arriving. A trigger is not a question you can make more specific. It either fired or it did not.
The condition is whether. Conditions are tested after the trigger fires and decide whether the run continues. “Only if the value is over ten thousand.” “Only if the customer is on a paid plan.” A condition that fails is not an error. It is a decision, and it should be recorded as one.
That recording matters more than it sounds. In Oneop’s automation, a rule that does not match is recorded as skipped rather than producing silence, so “why didn’t that fire” has an answer rather than a theory. Silence is the worst possible output of an automation, because silence is what success looks like too.
The action is what. Update a field, create a task, open a project, send an email, call a webhook, ask a person. Actions are where the reversibility question lives, and it is worth ordering a flow so that irreversible actions come as early as possible, for reasons that become clear when a run is interrupted.
The failure case: the follow-up that ran at the wrong hour
Here is what a scheduled design costs, in a shape that recurs in every operations team.
A company wants to text a customer when their order ships. The system that knows about shipments and the system that sends messages are different, so someone writes a job that runs hourly, finds orders shipped in the past hour, and sends a message for each.
For three months it works. Then a shipment posts at 09:58 and the hourly job runs at 10:00, so the customer is notified two minutes later. The next day a shipment posts at 10:01 and the customer waits fifty-nine minutes. Support fields a “where is my order” call in the gap, which is the exact call the automation existed to prevent.
The second failure is worse and arrives quietly. The job runs, the query fails on a deploy, and the hour’s window closes. The next run asks for the past hour, which no longer includes the lost one. Nothing errored in a way anyone saw. A day’s shipments were simply never notified, and the only symptom is a handful of customers who were mildly annoyed a week ago.
The event-driven version of this has neither failure. The shipment fires the automation as part of the shipment, so the delay is not a function of when in the hour the event landed, and there is no window that can close over missed work.
Why “when X happens” is a stronger model
Three properties follow from using the change itself as the starting point, and each one is a reason to prefer events by default.
Delay stops being arbitrary. With a schedule, the time between the event and the response depends on where in the interval the event landed. That is a variable nobody chose and nobody can explain to a customer.
Nothing is done when nothing happened. A polling loop performs the same query all day to catch a handful of changes. An event-driven rule does exactly as much work as there were changes.
The trigger names the cause. An event carries what happened and to which record. A scheduled job has to reconstruct that by comparing state, which is where “changed in the last hour” logic comes from, and that logic is where the missed windows hide.
In Oneop, twelve distinct events can start an automation, spanning the CRM, projects and the help desk, plus a schedule for the work that genuinely belongs on a clock. The product is deliberate about not averaging them: the events behave differently from each other, and a page that flattens them into one promise is describing a demo rather than a system you can plan against.
Two of those behaviours are worth knowing as a buyer. A raised ticket waits for its automations to finish before the response comes back, so nothing races the reply. And an SLA breach is claimed before it fires, which makes it fire exactly once even if two sweeps overlap, because a breach is a condition rather than an event and firing it twice would escalate the same ticket twice.
Ordering, and the thing beginners assume
Inside one automation, steps run in the order you wrote them. Across two automations watching the same trigger, order is not something to rely on. If step B needs step A to have finished, put both in the same automation. Two rules racing over one record is a bug that reproduces once a month and never while you are watching.
The second ordering question is what happens when a run stops part way. Long automations pause: wait a day, then follow up; or hold until a manager approves. A pause is where the engineering actually is, because a pause that lives in memory is erased by the next restart and the work never happens, with nothing logged, because nothing went wrong.
Oneop handles a pause by writing it down: the step it stopped at, the variables gathered so far, the trace, and a copy of the flow as it was when the run began, with a time to come back. A restart cannot lose it because no process was holding it. The limit is stated plainly on the product page rather than hidden: a run interrupted mid-step restarts that step, so an action after a wait can happen twice. That is why irreversible actions belong early in a flow.
Where to start, and where to stop
A practical first build is one event, one condition, one action, watched for a week. Resist the instinct to chain six steps on day one, because a six-step automation that misbehaves is six hypotheses.
Then keep two limits in mind. Ceilings exist for a reason: an Oneop run stops itself at forty-eight steps and eight model calls, counted across every branch, so a loop written by accident cannot run against your own data overnight. And some work should not be automated at all, which is the argument in when not to automate. Where a model is involved in a decision, the level of independence it gets is a separate choice, described in autonomy levels: suggest, approve, autonomous.
The reason to learn this distinction as a business person rather than leaving it to engineering is simple. When you say “notify the customer when the order ships”, you are specifying a mechanism, whether you meant to or not. Saying it precisely gets you the version that fires in a second. Saying it loosely gets you the version that checks every hour and occasionally forgets.
Automation in Oneop is on every plan including the free one, with no entitlement check on any automation route, so testing the difference on your own records costs nothing but an afternoon. The pricing page has the plan detail; the mechanism above is the part worth getting right first.