Let work move without chasing the next person.

No, and this is unusual enough in the category to be worth stating flatly: there is no automation tier here. Building workflows on record events, scheduling them, writing ticket automations with conditions and branching, pausing a run for a day, routing something through a human approver and testing the whole thing with a dry run are all available on every plan including the free one. We are not describing a generous trial — there is no entitlement check on any automation route in the product, so there is nothing to unlock. The one thing that does vary by plan is the pool of AI credits your workspace gets each month, because a step that calls a model has a real cost attached to it. That pool is shared with every other AI feature in Oneop rather than being an automation allowance, so a month of heavy chatbot use and a month of heavy automation use draw on the same number.

The wait survives, because it is not a timer. When a run reaches a wait step, the remaining steps — which step it stopped at, the variables it had collected, the trace so far and a copy of the flow as it was when the run started — are written to a database row with a time to resume at. A separate process looks for rows that are due. If the server restarts, the row is still there and is picked up on the next pass, so a twenty-four hour wait set on Monday still runs on Tuesday even if nothing was running in between. This is the strongest reliability property automation has here and it is the one we would want you to test. The narrower and more important thing it does not claim is exactly-once execution, which is answered in the next question rather than glossed over in this one.

Yes, in one specific place, and you should design around it rather than be surprised by it. A resumed run restarts the step it was interrupted in. If a run wakes up after a wait, posts a reply to the customer, and then the process handling it stops before the run is recorded as finished, the row becomes due again and the resumed run begins from that same step — so that reply can be posted a second time. The same is true of a notification, an escalation, or an AI step, which would also be charged again. What is guaranteed is that two processes cannot pick up the same waiting run at once: it is claimed before it executes, and claiming it hides it from everything else. That is a real guarantee and it is a different one from "the action cannot happen twice", and we would rather draw the distinction than let you assume the stronger one. In practice: after a wait, prefer steps that are safe to repeat, and keep an irreversible one as early in the flow as you can.

Yes. Point it at a real ticket and run it as a simulation, and you get the full execution trace — which conditions matched, which branch it took, which steps ran, in order — with nothing written and nothing sent. Two details are worth having in advance so the trace reads correctly. Field changes are computed exactly as they would be live and then discarded, so what you see is the real decision. The three steps that reach outside the ticket — assigning to an agent, notifying someone, and replying to the customer — report what they would have done instead of doing it, which means a dry run tells you that it would assign but not which agent the picker would have chosen. And AI steps derive the same fields without calling a model, so a dry run is free no matter how many times you run it.

Four things: read the tone of a ticket, classify it into a category with a priority and tags, summarise it, or draft text. Whatever it produces becomes variables the rest of your flow can branch on, so the model informs a decision your rules then make, rather than making the decision itself. Every one of those calls is metered against your workspace credits exactly like every other model call in Oneop, so automation shows up in your usage rather than being free and untracked, and a single run is capped at eight model calls however many branches it contains. Prompts pass through the same guardrail layer as the rest of the product, which will refuse a call outright rather than pass a manipulated instruction through. How models are constrained, metered and governed across Oneop is one page: AI governance.

It depends which engine you are in, and the two genuinely differ. A workflow on a record event runs inside a single transaction, so a failure at step four undoes the field updates made at steps one to three — with the honest exception that an email or a webhook already delivered earlier in the run cannot be recalled, and stays delivered. A ticket automation is not transactional in that way: if a step throws, the run stops there and is recorded as failed with the error, but nothing earlier is undone and nothing is retried. A reply already posted stays posted. Ticket field changes are collected and applied at the end of a run rather than one at a time, which means a run that fails part-way generally does not leave the ticket half-updated — it leaves it untouched, with a failed run in the history explaining where it stopped.

Yes, deliberately, and the limits are low enough to be worth knowing before you design something around them. A single run may take forty-eight steps and make eight model calls, both counted across the whole run rather than per branch — so a branch inside a branch cannot smuggle in extra work. A flow may have twelve top-level steps, branches may nest four deep, a branching step may have four paths, and each path may hold six steps. A webhook step gives up rather than holding a run open indefinitely. These are not performance tuning; they are what stops an automation you wrote at four in the afternoon from becoming an unbounded loop against your own data at four in the morning.