Workflow Builder

DevRev's native automation engine, the Workflow Builder, lets you design, build, and deploy event-driven automations that run in the background—handling repetitive tasks, enforcing business rules, and routing work without manual intervention.

A workflow is a series of triggers, conditions, and actions designed to achieve a specific outcome. The mental model is: if this happens, check that, then do this. A workflow can be as simple as one trigger and one action, or as complex as a multi-branch, multi-day automation with delays, loops, AI classification, and external API calls.

No-code, drag-and-drop interface

Build automations visually on a canvas by connecting steps in sequence. No third-party tools, middleware, or code are required, though a Code node is available for advanced use cases.

Event-driven execution

Every workflow starts with a trigger: an event in DevRev such as a ticket being created, an issue being updated, or a timer firing, or an event from an external source such as an API call. The workflow executes automatically each time that event occurs.

Deterministic and AI-capable logic

Workflows support both rigid rule-based logic such as if/else and routing, and AI-powered decision-making such as sentiment analysis, spam detection, and AI-generated responses. You can combine both in a single workflow.

Native integration

The workflow engine operates directly on DevRev objects—including tickets, issues, conversations, and accounts—with full access to their fields and relationships.

The rest of the Workflow Builder documentation is split across these articles:

• Workflow triggers: the trigger catalog, trigger output, and filter conditions.

• Workflow node reference: every node type, the complete action library, and field types.

• Workflow how-to guides: task-based walkthroughs for common automation patterns.

• Manage workflows: versioning, publishing, rollback, permissions, run monitoring, and analytics.

• Workflow Builder limits: hard limits and known functional limitations.

• Workflow Builder troubleshooting: symptoms and resolutions.

Workflow execution

Execution follows this sequence:

1. Event occurs: Something happens in DevRev (a ticket is created, a field is updated, a timer fires) or outside of DevRev.

2. Trigger evaluates: The workflow engine checks whether the event matches the trigger's filter conditions. If the conditions are met, a new run begins.

3. Steps execute in sequence: Starting from the trigger, the engine follows connections to execute each step in order. Each step receives input from configuration and upstream outputs, performs its operation, and produces output.

4. Branching: Control nodes (If/Else, Router) evaluate conditions and direct execution to one or more branches. In a Router, multiple branches can execute in parallel if their conditions all match.

5. Looping: For Each and While nodes iterate over collections or repeat until a condition is met. Actions inside the loop execute once per iteration.

6. Delays: Blocking nodes (Sleep For, Sleep Until) pause the run. The run resumes automatically when the delay period ends; it is paused, not cancelled.

7. Completion: The run ends when all branches reach their final step or an unhandled error occurs.

📝 Note: A single workflow can have at most 100 nodes, and the total workflow definition size cannot exceed 8 MB. During a single run, the engine allows a maximum of 10,000 node executions across all branches—relevant for loops and high-branching routers. Workflow runs are rate-limited to 2,000 runs per 5-minute window per workspace.

Data flow between steps

Each step's output is available to all downstream steps, not just the immediately following one. Variables are scoped to what is available upstream: you can only reference data from steps that have already executed before the current one. Output data is accessed using the variable selector ({{) or by clicking Insert variable in any text field.

Version pinning

When a run starts, it uses the workflow version that was active at that moment. If you publish a new version while runs are in progress, those in-flight runs continue on the old version; only future events use the new version.

Access the Workflow Builder

1. Go to Settings > Automation > Workflows. The workflows list page opens, showing all workflows in your workspace grouped by status: Published, Paused, and Draft.

2. To create a new workflow, click + Workflow in the top right. A fresh canvas opens in Draft mode.

Permissions

• Any member of the workspace can view the workflows list page, open a workflow, and edit it to create a draft.

• Only members of the Agents and Automation Admins group can deploy workflows and view workflow runs.

• Custom roles with Create, Read, Update, and Delete permissions can also be configured for finer-grained access.

The workflow canvas

The canvas is the visual editor where you build workflows. It consists of the following elements:

• Steps (nodes): Displayed as cards on the canvas. Each step represents one operation. Steps are color-coded by type: Trigger (green, starting point), Action (green, lightning icon), Control (orange, arrows icon), and Delay (blue, clock icon).

• Connections: Lines between steps that define execution order. Data travels along these connections. To create a connection, drag from one step's output handle to another step's input handle.

• Toolbar: Located at the bottom of the canvas. Controls include adding a new step (which opens the operation picker with Trigger, Control, Action, and Delay categories), zooming in and out, fitting to screen, and aligning nodes.

To build a workflow:

1. Add a trigger step as the starting point. Every workflow requires exactly one trigger.

2. Add action, control, or delay steps from the + Step menu.

3. Connect steps in sequence by dragging connection handles.

4. Click each step to open the configuration panel on the right, then fill in the required fields.

The canvas is non-destructive while in Draft mode. You can freely add, delete, and rearrange steps without affecting anything live. Only when you click Publish does the workflow go active.

Copy and paste steps

Rather than rebuilding a configured step by hand, select a step and press Cmd/Ctrl+C, then Cmd/Ctrl+V to paste, or use the right-click menu. The full configuration carries over—conditions, action fields, field mappings, and integration settings—eliminating a common source of silent misconfiguration. You can also select several connected steps to copy them as a group; the connections between them are preserved. Steps can be pasted within the same workflow or into another workflow open in a different browser tab. This is the fastest way to reuse a pattern you have already built—an enrichment sequence, a guarded update, or an error-handling path—across multiple workflows.

Glossary

• Trigger: The event that starts a workflow. Every workflow has exactly one trigger (for example, Ticket Created, API Trigger, or Timer Trigger).

• Node (step): A single operation on the canvas. Each node receives input, performs its operation, and produces output for downstream nodes.

• Run: A single execution of a workflow, started by a trigger event. Runs are inspected in the Runs tab.

• Canvas: The visual editor where you build and edit workflows by placing and connecting nodes.

• Draft / Active / Paused: The three states a workflow can be in. Draft is an unpublished work-in-progress. Active is a published, live workflow. Paused is a published workflow that has been temporarily disabled.

• Filter condition: A rule configured on a trigger that narrows when the workflow fires. Without filters, the trigger fires on every matching event.

• Fields to watch: On Update triggers, the list of fields whose changes cause the trigger to fire. If none of the watched fields change, the trigger does not fire.

• Scope variable: A variable scoped to a specific block (for example, the break variable inside a While loop). Scope variables reset at the start of each iteration.

• Workflow variable: A variable created by Init Variable and available to all downstream steps in a workflow. Used to accumulate or carry state across branches and loops.

• Branch: A parallel execution path created by a control node (If/Else, Router). Each branch runs independently; data does not flow between parallel branches.

• Port: The input or output connection point of a node. Most nodes have one input and one output, but control nodes have multiple output ports (for example, If/Else has on_true and on_false).

• Composite field: A nested object with its own fields, referencing a named schema (for example, owned_by, tags).

• Version pinning: When a run starts, it is pinned to the workflow version that was active at that moment. In-flight runs continue on the old version even if you publish a new one.

• Release stage: The availability of an operation: General Availability (public), Beta (testing), or Internal (not user-visible).

• API Trigger: A trigger that fires when an external system calls a workflow's endpoint, letting external events start DevRev workflows.