Version, publish, and monitor

Every workflow maintains a version history. Each time you publish, a new version is created.

Publish a workflow

1. Make your changes on the canvas while in Draft mode.

2. Click Validate to check for errors such as missing required fields and invalid connections.

3. If validation passes, click Publish (or Deploy). The draft becomes the new active version, and all future events use this version.

⚠️ Warning: Validation checks structure, not runtime behavior. It catches missing connections and unset required fields, but not an HTTP node missing its Method field, a variable referencing a deleted step, or a stale fragment version. Test with a sample event after publishing.

If saving or publishing a large workflow returns a 504 gateway timeout, reduce the node count or split the workflow.

Key behaviors of versioning:

• Changes stay in draft until you explicitly publish. The existing live version keeps running untouched while you edit.

• Workflow runs that are in a running or waiting state continue to use the version with which they started. New runs use the newly published version.

• Every version is preserved in the version history panel on the right side of the canvas, showing creation timestamps and the author of each change.

Roll back to an earlier version

When a published change causes a problem, restore a previous version instead of rebuilding it manually.

1. Open the workflow and select any past version from the versions side panel. The version is restored into a Draft.

2. Review the restored draft on the canvas, then click Validate and Publish.

The restored version becomes a new version on top of the history rather than erasing what came after it, so the version you rolled back from is still available if you need to return to it. The live version keeps running until you publish.

The button in the top-right panel reflects the workflow's state: Edit current version when a version is published, or Edit draft version when a draft already exists alongside it. The dropdown next to it holds the template actions described in the Importing and exporting workflows section, which you can use to publish a fresh version on top of an existing workflow from an uploaded JSON file, useful for promoting a workflow validated in a test workspace to the live one.

Pause and edit live workflows

To modify a live workflow:

1. Click Pause on the workflow. This stops new runs from starting, but in-flight runs continue to completion.

2. Make your edits on the canvas. The workflow enters Draft mode.

3. Click Validate, then Publish to reactivate the workflow with your changes.

You can also create a draft without pausing: click Edit Draft Version on an active workflow. The live version continues to run while you edit. When you publish the draft, it replaces the live version.

Access control and permissions

Access to the Workflow Builder is controlled by workspace membership and group membership.

• Every member of the workspace can view, open, and edit workflows to create drafts. Editing never affects the live version, drafts are isolated until they are published.

• 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 be configured for finer-grained access if the default group structure does not fit your workspace's needs.

• If you can see the Workflows section but cannot publish, ask an admin to either publish on your behalf or add you to the Agents and Automation Admins group (or a custom role with the appropriate permissions).

Monitor runs

The Runs tab provides an execution log for each workflow.

To access runs:

1. Go to Settings > Workflows.

2. Click on a workflow.

3. Click the Runs tab at the top of the canvas.

To filter runs:

• Use the Status filter to show only errored runs, only completed runs, and so on.

• Use the Trigger Object filter to narrow runs to a specific DevRev object, a ticket, issue, conversation, account, or any other native object that triggered the workflow. This is the fastest way to find the run that fired for a specific object when debugging unexpected behavior.

• For workflows triggered as agent skills, filter by the conversation the skill was invoked from, or by the user who invoked it. The Triggers column shows which object or user started each run.

• Click the refresh button at the top right of the runs table if the latest run is not yet visible.

📝 Note: Only admins can view the Runs tab.

Debug and troubleshoot

When a run fails or behaves unexpectedly, use the following approach:

1. Identify the failing run. Open the Runs tab and filter by Errored status. If you already know the object the workflow should have acted on, for example, a specific ticket or issue ID, use the Trigger Object filter to jump straight to the runs tied to that object, which is faster than scrolling through a long list.

2. Inspect the execution path. Click on a run to see the full execution path: which steps executed, which branches were taken, and which steps were skipped. Each step is highlighted with its status (success, error, or skipped).

3. Inspect individual nodes. Click on any step in the run to see:

   • Input values: the actual data passed into the step at runtime.

   • Output values: the data the step produced.

   • Error message: if the step failed, the error is displayed in the detail panel.

4. Use AI-generated error explanations. When inspecting a failed node, click the star button (✦) to generate a plain-language explanation of the error, what went wrong, why, and what to do about it.

Error handling

Error paths allow a workflow to recover gracefully when a step fails instead of stopping the entire run.

To set up an error path:

1. Click the three-dot menu (⋮) on an action node.

2. Select Set Error Path. An error output port appears on the node.

3. Connect the error port to one or more fallback steps.

When an error occurs:

• If the step has an error path, execution continues along the error path. The error details are available as output of the failed step.

• If the step does not have an error path, the run stops with an Errored status.

Recommended fallback actions include:

• Add Comment: log the error to the object's timeline for visibility.

• Send Notification: alert an admin or team.

• Update a field: for example, set a sync_status custom field to failed.

Import and export workflows

Workflows can be exported as JSON templates and imported into another workspace, shared with another team, or used to update an existing workflow to a new version. There are three entry points.

Export a workflow as a template

1. Open the workflow you want to export.

2. In the top-right toolbar of the canvas, click the download icon (Export current version of workflow as a template).

3. The browser downloads a JSON file containing the workflow's full definition: trigger, nodes, connections, and configuration.

The exported file represents the current published version of the workflow.

Import a workflow as a new workflow

1. On the workflows list page, click + Workflow in the top right.

2. In the Create workflow modal, choose Import Workflow — Start with a pre-configured workflow.

3. Select the JSON template file from your computer. The workflow loads into a new Draft with all steps, connections, and configuration pre-populated.

4. Edit and publish as usual.

Create a new version from a template

Use this when you want to replace the current version of an existing workflow with one defined by a template JSON, for example, to pull in an updated template from another workspace.

1. Open the workflow you want to update.

2. Click the + Create new version dropdown in the top-right toolbar.

3. Select Create from template.

4. In the Create version from template modal, upload the JSON file.

5. Click Create new version. The imported definition is created as a Draft. The existing active version continues running until you publish the new draft.

Workflow analytics

The Workflow Builder includes two analytics dashboards: one at the workspace level that summarizes every workflow in your workspace, and one scoped to an individual workflow. Both are built on the same underlying metrics and refresh on a schedule; the timestamp of the last refresh is shown in the top right of each page.

Workspace-level analytics

From the workflows list page, click Insights in the top-right header (next to + Workflow) to open the workspace-level dashboard. This dashboard gives you a cross-workflow view of execution activity:

• Step Analysis by Workflow: a table listing every workflow × operation combination with Total Executions, Failed Executions, and Error %. Sort any column to find the steps with the highest failure rate across the workspace.

• Filters: narrow the view by Operation ID or by trigger type (for example, Timer Trigger) using the filter chips at the top. Add more filters with the + button, or click Clear to reset.

• Customize: adjust which columns are shown in the Step Analysis table via the Customize dropdown on the right of the table.

• Save as: save the current filter and column configuration as a named view.

Use the workspace-level dashboard to identify which workflows are failing most often, which operations are the noisiest across all workflows, and whether any workflows have not run at all.

Workflow-level analytics

Open any workflow from the list and switch to the Analytics tab alongside View and Runs at the top of the page. The Analytics tab shows metrics scoped to that single workflow:

• Total Runs: total number of times this workflow has run in the selected period.

• Failed Runs: number of runs that ended in an error state.

• Success Rate: the percentage of runs that completed successfully.

• Runs Over Time: a time-series chart plotting Runs, Success Count, and Failed Count so you can spot spikes, drops, and failure clusters at a glance.

• Step Analysis: a per-operation breakdown showing Total Executions, Failed Executions, and Error % for each step in the workflow. Sort to find which specific step is responsible for most failures.

Use the workflow-level dashboard when you have already identified a workflow that needs attention and want to understand its recent performance, for example, when debugging a sudden drop in success rate or identifying which step is introducing the most errors.

The two dashboards work in tandem: start from the workspace-level Insights tab to find anomalies across workflows, then drill into the Analytics tab of a specific workflow for root-cause analysis. For inspecting individual runs and step-level input/output values, continue from Analytics into the Runs tab.