Skip to content
English
Do you need help? Customer portal
neowit.io
  • There are no suggestions because the search field is empty.

Publishing and versions

Save your workflow, flip the Enabled toggle to send real triggers to it, and use version history to go back to an earlier version if something breaks. For workflow authors shipping a workflow to production, or cleaning up after a bad save.

Save the workflow

  1. Click the Save icon in the top toolbar.
  2. The Save Workflow dialog opens. Fill in or adjust:
    • Name — required, shown everywhere the workflow is referenced.
    • Description — optional; use it to tell teammates what this workflow is for.
    • Enabled — the live-trigger switch. See the next section.
  3. If you changed the DAG (added, removed, or reconnected nodes), a Commit message field appears below the helper line "You have unsaved changes. Add a commit message to save this version." Describe what you changed — this is the label future-you will see in version history. It's required whenever a DAG change is being saved.
  4. Click Save.

[SCREENSHOT] The Save Workflow dialog. Name and Description are filled in, Enabled is on, and the Commit message field is visible below the "You have unsaved changes. Add a commit message to save this version." helper line. The Save button is highlighted at the bottom.

Enable (or disable) real triggers

  • The Enabled toggle is the only gate for real trigger delivery. When it's off, no events and no schedules reach the workflow — it's effectively paused.
  • Disabling doesn't erase anything. The definition, all past versions, and the full execution history stay intact. Flip it back on whenever you're ready.
  • Executions that were already running when you disable will finish. New triggers are dropped until you re-enable.
  • You can still test a disabled workflow from the editor — see Testing your workflow. Testing never depends on the Enabled state.

How versions work

Every save that changes the DAG creates a new version — an immutable snapshot of all nodes, edges, and the commit message you wrote. Metadata-only saves (rename, description, Enabled) update the workflow in place without creating a version.

At any moment, exactly one version is the active version — the one real triggers execute against. By default, that's the version you saved most recently.

There is no separate "draft" pointer: when you save a DAG change, the new version becomes active immediately. If you need to keep a workflow out of production while you iterate, turn Enabled off until you're confident.

Look at past versions

  1. Click Version history in the top toolbar (clock icon).
  2. The Version History dialog opens with the newest version first. Each row shows the commit message, when it was saved, and up to two chips:
    • Active — the version real triggers are running against. Only one row has this at a time.
    • Current — the version currently loaded in the editor.
  3. Click a row to select it. Two buttons appear when applicable:
    • Load brings that version into the editor for viewing or further editing. It doesn't change which version is active. The caption at the top reminds you: "Active = deployed version. Current = loaded in editor."
    • Make active points the workflow at that version. It takes effect immediately — a "Successfully reverted" toast confirms.

[SCREENSHOT] The Version History dialog with three version rows. The newest row carries the Active chip; an older row is selected and shows the Load and Make active buttons.

Revert a bad save

If a new version broke things in production:

  1. Open Version history.
  2. Click the last known-good version (usually the row just below the one currently marked Active).
  3. Click Make active. The workflow swaps over immediately; the next trigger runs against the old version.

The broken version isn't lost — it stays in history, just no longer Active. Load it later to study what went wrong and prepare a fix.

Tip: If the broken version was never actually enabled, skip the revert — just disable the workflow and save a fix as the next version. Use Make active when real executions ran against the broken version and you need to get production back on the previous definition right now.

What we don't do (yet)

  • No side-by-side diff. Version history lists each snapshot but doesn't highlight what changed between two versions. Lean on your commit messages.
  • No author tracking per version. Rows show when a version was saved, not who saved it. For regulated environments, log changes externally.
  • No separate staging version. Make active is instant — there's no "promote after review" step. On a shared workflow, coordinate with teammates before hitting Make active.

Related