Operational Workflows

An Operational Workflow is a recipe Ragtime runs for your organization. It starts when something happens, moves data through connected steps, and records what happened at each stage.

Unlike an action or a conversation stage, a workflow does not live inside one chat session. It runs on the server and can continue after the conversation ends, wait safely, retry external work, and resume without repeating completed steps.

Workflows are configured in Dashboard -> Workflows.

A workflow in plain language

Every workflow answers three questions:

1. When should this start? This is the trigger.
2. What should happen next? These are the connected steps.
3. What counts as done or failed? These are the final outcomes.

For example:

1. Start when a Ragtime conversation ends.
2. Ask a published assistant snapshot to produce a structured support summary.
3. Check whether the summary needs follow-up.
4. Add a public reply to a support ticket and set its status to pending.
5. Finish and store the output, or follow an error path if the ticket update fails.

Each time the recipe starts, Ragtime creates a run. The run records its status, current step, output, errors, and event history.

Ways to start a workflow

A trigger can start a run:

• manually or through the workflow run API;
• from a signed webhook sent by another system;
• when a supported Ragtime event occurs, such as a session ending or an action completing;
• on a five-field cron schedule in a chosen timezone;
• from an event reported by a configured connector.

Use idempotency keys when an external caller may send the same event more than once. This prevents duplicate requests from creating duplicate work.

Building blocks

After its trigger, a workflow can use these node types:

Map prepares or reshapes values for later steps.

Condition chooses a true or false path from the current data.

AI task sends focused instructions and structured input to a pinned, published assistant snapshot. Its output follows the schema you define.

Connector operation performs a supported action through an organization integration, such as posting to Slack or updating a Zendesk ticket.

HTTP request calls an endpoint that your organization has configured and approved. Methods, timeouts, and retry behavior are explicit.

Wait pauses for seconds, minutes, hours, or days. Ragtime stores a checkpoint and resumes from the next node rather than replaying earlier effects.

Complete returns the run’s output. Fail ends it with an intentional error. Fallible operations expose success and error paths so failure handling is part of the graph rather than an afterthought.

Drafts, publishing, and runs

Editing changes the draft only. Publishing validates the graph and creates an immutable version with pinned resources, so a live run cannot silently change halfway through because someone edited an assistant, endpoint, or connection.

Enable the workflow when its published version is ready to receive automatic triggers. Use the run history to inspect queued, running, waiting, completed, failed, or cancelled runs.

What makes a workflow durable?

Ragtime stores workflow state in PostgreSQL rather than treating the queue as the source of truth. Timed waits have persisted continuation checkpoints. Running jobs renew an execution lease, and an abandoned run can be recovered after that lease expires. A stale worker cannot finish a run after another worker has taken ownership.

In practical terms, a worker restart should delay work rather than erase it or repeat steps that already changed another system.

When to use something else

Use an Action for anything that happens inside the chat: a tool the model calls, questions for the visitor, or an event sent to your page.

Use conversation stages for conversational phases, instructions, and action scoping.

Use n8n when automation should be owned by your external n8n environment or needs connectors that are not available natively.