Workflow Versioning
Relevant source files
The following files were used as context for generating this wiki page:
- backend/src/workflows/domain/version_entities.py
- backend/src/workflows/application/use_cases/compare_versions.py
- frontend/src/components/version/version-history.tsx
- CHANGELOG.md
- DDD_IMPLEMENTATION_REPORT_SPEC_WFL_005.md
- FRONTEND_PHASES_4_7_IMPLEMENTATION_SUMMARY.md
- IMPLEMENTATION_REPORT_SPEC_WFL_003.md
Workflow Versioning is a critical system within the automation module designed to track, manage, and revert changes made to automation sequences. It ensures that every modification—whether to triggers, actions, or branching logic—is captured as a distinct snapshot, allowing developers and users to maintain a reliable audit trail and restore previous stable states of an automation.
This system works in tandem with the Workflow CRUD Implementation to manage the lifecycle of a workflow from its initial "draft" status to "active" or "paused" states. By maintaining a history of versions, the system provides a safety net for complex automation logic updates, ensuring that production workflows can be updated without losing historical configurations.
Sources: CHANGELOG.md:14, FRONTEND_PHASES_4_7_IMPLEMENTATION_SUMMARY.md:144, DDD_IMPLEMENTATION_REPORT_SPEC_WFL_005.md:7316
Core Architecture and Entities
The versioning system is built upon a Domain-Driven Design (DDD) approach, where versions are treated as immutable snapshots of a workflow's state at a specific point in time.
Version Entities and Value Objects
The backend defines version-specific entities that encapsulate the state of a workflow. Key components include:
- WorkflowVersion: An aggregate or entity representing a specific iteration of a workflow. It contains the complete configuration of triggers and actions at the time of creation.
- VersionSnapshot: A data structure containing the serialized state of the workflow's nodes and edges.
- VersionMetadata: Tracking data including who created the version, when it was created, and a description of the changes.
Sources: backend/src/workflows/domain/version_entities.py, CHANGELOG.md:46-50
Database Schema for Versioning
The infrastructure layer supports versioning through dedicated tables and relationships that link versions back to the parent workflow and the user who performed the change.
| Field | Type | Description |
|---|---|---|
id | UUID | Unique identifier for the version snapshot. |
workflow_id | UUID | Foreign key linking to the parent workflow. |
version_number | Integer | Incremental counter for versions within a specific workflow. |
snapshot | JSONB | The full serialized configuration of the workflow. |
created_by | UUID | The user ID of the person who committed the changes. |
change_summary | String | A brief description of the modifications made. |
Sources: CHANGELOG.md:46-55, IMPLEMENTATION_REPORT_SPEC_WFL_003.md:3849
Version Management Logic
The system facilitates complex operations such as comparing different versions to identify specific changes in automation logic.
Compare Versions Use Case
The CompareVersionsUseCase is responsible for identifying differences between two specific snapshots. This logic analyzes changes in:
- Triggers: Changes in trigger types or configurations (e.g., changing from "Form Submitted" to "Contact Tag Added").
- Actions: Additions, deletions, or configuration updates to communication or CRM steps.
- Flow Logic: Changes in the sequence or branching (If/Else) paths.
The comparison logic ensures that users can see exactly what changed before deciding to restore a previous version.
Sources: backend/src/workflows/application/use_cases/compare_versions.py, IMPLEMENTATION_REPORT_SPEC_WFL_003.md:3849
Restore and Rollback
Restoring a version involves replacing the current "active" or "draft" configuration with the snapshot stored in the version history. When a restore is triggered, the system creates a new version entry representing the restored state to maintain a continuous, linear history.
Sources: DDD_IMPLEMENTATION_REPORT_SPEC_WFL_005.md:140-145
Frontend Interface: Version History
The frontend provides a dedicated interface for users to interact with version history, typically accessed via the workflow detail page.
Version History Component
The version-history.tsx component renders a chronological list of changes. It allows users to:
- View History: See a list of all saved versions with timestamps and author names.
- Preview: Load a previous version into a read-only canvas to inspect its logic.
- Restore: Trigger the backend use case to revert the workflow to a selected snapshot.
Integration with Workflow Lifecycle
Versioning is tightly coupled with the status management of workflows. Changes are generally drafted and versioned before the workflow is transitioned to an "active" state.
Audit Logging and Snapshots
Every significant change triggers an entry in the workflow_audit_logs table. While audit logs track individual field changes (e.g., name updates), the versioning system captures the entire "snapshot" of the workflow logic (nodes and edges).
- Draft Tracking: While a user is editing in the Visual Builder, the system uses a 30-second auto-save interval to local storage.
- Commit/Version Creation: A formal version is typically created when the user manually saves or when a workflow is activated.
Sources: CHANGELOG.md:46-55, FRONTEND_PHASES_4_7_IMPLEMENTATION_SUMMARY.md:144-160
Summary
Workflow Versioning provides the necessary infrastructure to track the evolution of automation logic within the GoHighLevel Clone project. By combining backend snapshotting via DDD entities with a frontend version timeline, the system ensures high "Trackability" (one of the TRUST 5 quality standards) and allows for safe experimentation with complex CRM and communication automations.
Sources: CHANGELOG.md:110-120, DDD_IMPLEMENTATION_REPORT_SPEC_WFL_005.md:7316