Workflow Versioning

Every time you save a workflow, Thallus creates a new version snapshot. This gives you a complete history of changes with the ability to compare, restore, and track who modified what.

Automatic versioning

Versions are created automatically on every save — there is no manual "create version" action. Each version receives an incrementing version number and captures a full snapshot of the workflow at that point.

What's captured in each version:

Field Description
Name Workflow name at time of save
Description Workflow description
Nodes snapshot Complete JSON of all nodes with positions, configs, and settings
Edges snapshot Complete JSON of all edges with conditions and priorities
Trigger snapshot Trigger configuration (mode, cron, webhook source, etc.)
Delivery snapshot Delivery method configuration
Change summary Auto-generated or user-provided description of what changed
Changed by User ID of who made the change

Version numbers are unique per workflow. A workflow's version history is append-only — you cannot delete individual versions.

Browsing version history

The version history panel shows all versions in reverse chronological order. Each entry displays:

  • Version number
  • Change summary
  • Who made the change
  • When it was created

Comparing versions

You can compare any two versions to see what changed. The diff shows:

  • Nodes added — new nodes that didn't exist in the earlier version
  • Nodes removed — nodes that were deleted
  • Nodes modified — nodes whose configuration, title, instruction, or position changed
  • Edges added — new connections between nodes
  • Edges removed — deleted connections

This makes it straightforward to understand what was modified between any two points in the workflow's history, even if many versions have been created in between.

Restoring a version

Restoring a previous version is a non-destructive operation. Rather than overwriting the current workflow, a restore:

  1. Reads the snapshot from the selected version
  2. Applies those nodes, edges, trigger, and delivery settings to the current workflow
  3. Creates a new version with a change summary indicating it was restored from version N

This means the version you restored from and all intermediate versions remain in the history. You can always see the full chronological record and restore again if needed.

Breaking change detection

When a workflow is referenced as a subworkflow by other workflows, modifications can potentially break those parent workflows. The system tracks these dependencies and builds the full dependency graph to detect cross-workflow impacts.

Breaking changes that the system detects include:

  • Removing nodes that a parent workflow maps outputs from
  • Changing the trigger configuration in ways that affect input mapping
  • Deleting a workflow that is referenced as a subworkflow

When a breaking change is detected during validation, the system warns you before saving. This does not prevent the save, but ensures you are aware of the downstream impact.

Executions and versions

Each workflow execution records which version was active at the time of execution, creating a clear audit trail. You can always determine exactly which workflow configuration produced a given execution result, even if the workflow has been modified many times since.