Skip to main content

​
Overview

Workflows evolve over time. You might tweak an action, experiment with a new trigger, or roll back to an earlier definition while troubleshooting. Overcut keeps every edit safe by auto-saving your changes as drafts and guiding you through a lightweight review and publish flow. This page explains how drafts move from your Workflow Builder to production, where to spot unpublished work, and when to publish or discard it.

Auto-saved drafts

Every edit in the Workflow Builder is saved immediately, so you never lose work if you close the tab or switch tasks.

Clear status chips

A colored chip in the workspace header shows the number of workflows with unpublished changes and links straight to a consolidated review page.

Unified review page

Compare the working draft to the last published version, publish or discard in one place, and jump back to the builder with a click.

Version History

Side-by-side diffs let you inspect any past version and restore it into your working copy when you need to roll back.

​
Draft lifecycle

1

Edit in the Workflow Builder

Open any workflow in the Workflow Builder. The moment you change a field or update YAML, Overcut creates a draft of your workflow. Your browser does not need to stay open — drafts are saved server-side every few seconds.
2

Unpublished draft detected

As soon as at least one draft exists in the workspace, an Unpublished Changes chip appears in the workspace header. The chip’s counter shows how many workflows contain drafts.
3

Review unpublished changes

Click the chip to open the Unpublished Changes review page. Here you can inspect every draft, compare it to the last published version, and decide what to do next.
4

Publish or discard

  • Publish finalizes the draft and promotes it to the latest published version. You will be prompted for a commit message so teammates understand what changed.
  • Discard removes the draft and reverts the working copy to the last published version. Nothing is deleted from Version History — you can always restore discarded changes later.
5

Automation uses published versions

Automated triggers always execute the most recent published version. If no version has ever been published, automation is paused until you publish at least once.

​
Finding unpublished changes

The moment a draft exists, Overcut surfaces it in multiple places:
  • Workspace header chip — A colored Unpublished Changes chip appears beside the workspace name. Its badge shows the number of workflows with drafts. Clicking the chip opens the review page.
  • Version History — Drafts show up at the top of the history list, labeled Draft so you can compare them against any earlier version.
The header chip disappears automatically when all drafts are either published or discarded.

​
Reviewing and publishing drafts

On the Unpublished Changes page you will find:
  • A filterable list of workflows with drafts, including last-updated timestamps and author avatars.
  • An inline side-by-side YAML diff viewer to highlight exactly what changed.
  • Edit buttons that reopen the draft in the Workflow Builder when you need to make further tweaks.
  • Publish and Discard controls that act on the currently selected workflow.
When you click Publish:
  1. Enter a short commit message that summarizes why you are publishing the changes.
  2. Overcut saves the draft as a new version and removes it from the “Unpublished Changes” list.
  3. Any future manual or automated executions will use the newly published version by default.
When you click Discard:
  1. The draft is deleted.
  2. The working copy reverts to the last published version.
  3. The workflow disappears from the “Unpublished Changes” list.
Publishing is lightweight — think of it as committing code. Publish frequently to keep your workspace predictable.

​
Manual executions and drafts

When you click Run from either the workflow list or the Workflow Builder, Overcut asks which definition you want to execute:
  1. Last published version (default) — Overcut automatically selects the most recent published version because it is the same definition your triggers and schedules rely on.
  2. Working draft — Choose this option to test your unpublished edits without promoting them.
If a workflow has never been published and you leave the default selection, the run is blocked because no committed version exists. Either publish the draft first or change the selector to Working draft to continue. Selecting Working draft executes the current auto-saved definition immediately, even if no published version exists, so you can validate changes before promoting them.
Running a draft is perfect for quick experiments, but only published versions power automation. Publish once you are satisfied with the results.

​
Best practices

  • Review before you run manually. Manual runs can target your working draft, but use the diff viewer to confirm changes before executing.
  • Discard stale drafts. If a draft lingers for days, it can confuse collaborators. Delete drafts you no longer plan to finish — Version History keeps a record if you need it later.
  • Use commit messages wisely. Clear messages make it easier for teammates (and future you) to understand why a change was made.
Workflows without a published version cannot run automatically. Make sure you publish at least once before enabling triggers or schedules.