Automate work that continues beyond a single request.

01 / AUTOMATION

Start from a business event or a scheduled occurrence

Event-driven automation starts in response to a defined business event, such as a supported record change. Scheduled workflow automation starts from a configured time or recurrence. The distinction is the source of the work; both need clear conditions, permissions and operational handling.

Event triggers connect a supported business change to configured automation. Scheduled automation defines recurring work and produces occurrences that can be processed by the runtime. A schedule is a source of work; its occurrence is the concrete item that must be tracked and handled.

Durable queued work separates the request that identifies an event from the execution that follows. This allows the platform to retain execution state across worker boundaries. Timers provide a different kind of wait inside a process, preserving the point from which it should resume.

02 / AUTOMATION

Apply explicit rules and structured actions

Rules evaluate supported conditions against business context. Actions perform defined operations, and process decisions use those conditions to select the next route. External service work uses configured integrations rather than embedding credentials in a workflow definition.

Choose the smallest useful automation for evaluation: a record event that starts a process, or a recurring schedule that creates work. Add a timer or decision where the business actually needs one. Inspect the resulting history to establish what was initiated and which step is waiting or complete.

03 / AUTOMATION

Design for retries and uncertain outcomes

A worker can fail or an external system can respond too late. Bounded retries and operational incidents provide controlled handling for supported failure cases. Idempotent command handling and occurrence identity help prevent duplicate platform work when requests or deliveries repeat.

Idempotency is not a blanket guarantee that every external side effect happens exactly once. When integrating another service, evaluate its behavior on duplicate requests and timeouts. Resolve the cause of an incident before retrying, and use execution history to understand what the platform already knows about the attempt.

• Define the event or recurrence and its business context.
• Review rule conditions and action configuration.
• Test a delayed or failed step as well as the successful path.
• Inspect incidents, retry outcomes and recorded history.

Which condition should start the work?

Use the educational guide to frame the design decision before comparing product capabilities.

• Event-Driven vs Scheduled Workflow Automation