Versioning

Versioning enables you to manage changes, track progress, and collaborate effectively by capturing snapshots of your project’s state at any point in time. The versioning system ensures that resources are grouped and tracked as part of the project, providing a comprehensive and structured approach to development.

​

Project version

A Project Version is an editable snapshot of your project at a specific moment. It contains all resources (e.g., processes, integrations, templates) and configurations grouped under the project.

The tab above provides a summary of all accessible project versions and branches available in the current environment.

---

​

Interface overview

​

Left panel: version details

• State: Displays the current state of the version (e.g., draft, committed).
• Branch: Indicates the currently selected branch (e.g., main).
• Last Saved By: Shows the username of the person who last saved changes (e.g., “JS”).
• Last Saved At: Displays the timestamp of the most recent save (e.g., “23 Jan 2025 at 10:11 AM”).
• ID: A unique identifier for the version, with a copy button for convenience.

​

Center panel: branch and commit graph

The graph visually organizes the project’s versioning structure, showing relationships between branches and commits.

• Graph View:
  • Provides a visual representation of branches and commits.
  • Main Branch (blue): The main development branch.
  • Secondary Branches (yellow): Feature or development branches such as branch3, branch4, and secondary_branch.
  • Markers:
    • Dotted Circles: Represent draft versions.
    • Solid Circles: Represent submitted versions.

​

Right panel: submit messages

• Displays a chronological list of commit messages for the selected branch.
• Details:
  • Commit messages (e.g., v1, commit_secondary_branch) are aligned with their respective branches.
  • Each commit shows:
    • The user responsible (e.g., “JS”).
    • The state of the commit (e.g., draft, commited).

​

Top bar: global controls

• Project Name: Displays the current project name (Docs_customer_onboarding).
• Branch Selector: Dropdown to navigate between branches.
• State Indicator: Highlights the state of the current branch (e.g., draft for main).
• Submit Changes to Version: Button for submitting draft changes globally.
• Config/Runtime Tabs:
  • Config: Likely for managing version configuration.
  • Runtime: Likely for runtime options or monitoring.

---

​

Core versioning operations

The table below summarizes key versioning operations and their functions:

Operation	Description
Create Project	Creates a project and its initial draft version.
Create Resource	Adds a new resource in draft status to the current project version.
Edit Resource	Creates a deep copy of a resource for editing if the original is COMMITTED.
Commit Project	Updates the statuses of the project, its manifest, and resources to COMMITTED.
Discard draft	Deletes draft resources and the draft project version.
Start New draft	Creates a new draft version by copying the last COMMITTED project version.
Create Branch	Creates a new branch and a corresponding draft project version from the selected commit.

​

Detailed steps for operations

---

​

Lifecycle of a project version

1. Create Project: Automatically starts with a draft (work-in-progress) project version.
2. Modify Resources: Draft (WIP) resources can be edited directly, while COMMITTED resources are cloned into draft (WIP) before editing.
3. Commit Changes: Promotes the project version and its resources to COMMITTED status.
4. Start New WIP: Allows iterative development by creating a new draft version.
5. Create Branch: Enables parallel development with isolated draft versions.

---

​

Starting a new version (draft)

You can initiate a new draft (work-in-progress) version while keeping the submitted version intact. A draft version is automatically created under the following circumstances:

• New Project: When you create a new project, a corresponding draft version is initiated. This ensures that ongoing changes are tracked separately from the submitted version.

• New Branch Creation: The creation of a new branch in the system also triggers the creation of a draft version (from a committed version only). This streamlines the process of branching and development, allowing for parallel progress without impacting the main submitted version.

• Manual Draft Version Creation: You have the flexibility to initiate a new draft version manually. This is particularly useful when building upon the latest version available on a branch.

---

​

Advanced features

​

Submitting changes

You can submit changes exclusively on work-in-progress (WIP) versions. Changes can be submitted using the designated action within the version menu. Upon triggering the submission action, a modal window appears, prompting you to provide a commit message.

The placeholder indicating work-in-progress is replaced with a “submitted” state within the graph view.

​

Updating submit messages

You have the flexibility to modify submit messages after changes are submitted. This can be accomplished using the action available in the version menu.

​

Creating a new branch

Using versioning you can work on a stable copy of the project, isolated from ongoing updates by other users. You can create a new branch starting from a specific submit point. The initiation of new branches is achieved using the dedicated action located in the left menu of the chosen submit point (used as the starting point for the branch).

​

Merging changes

You can incorporate updates made on a secondary branch into the main branch or another secondary branch. To ensure successful merging of changes, adhere to the following criteria:

• You can merge the latest version from a secondary branch into either its direct or indirect parent branch.

• Upon triggering the merge action, a modal window appears, giving the possibility to make the following selection:
  • Branch: Displays the branches to which the current branch is a child (direct or indirect).
  • Message: A string of maximum 50 characters (limited to letters), numbers and the following characters: [] () . _ - /.

The graph representation is updated to display the new version on the selected parent branch and the merged version is automatically selected, facilitating further development and tracking.

​

Managing conflicts

The Conflict Resolution and Version Comparison feature provides a mechanism to identify and address conflicts between two process versions that, if merged, could potentially disrupt the integrity of a project.

The system displays both the version to be merged and the current version on a single screen, providing a clear visual representation of the differences. Conflicts and variations between the two versions are highlighted, enabling users to readily identify areas requiring attention.

​

Merging without conflicts

Easily merge secondary branches into the main branch or other branches when no conflicts are detected. The updated merge modal includes:

• A clean, streamlined interface for branch selection.
• A mandatory, validated commit message field (max 50 characters).
• Real-time feedback for successful merges and updates to the branching graph.

​

Advanced conflict detection

The new Conflicts Detected Modal provides a detailed overview of conflicting changes, with features such as:

• Clear grouping by resource type (e.g., Processes, Enumerations, Media Library).
• Scrollable lists and clickable entries to resolve conflicts efficiently.
• A comprehensive comparison of source and target branch differences for context.

​

Resource-level conflict resolution

Resolve conflicts directly at the resource level with an intuitive interface:

• JSON Comparisons: Visualize differences with color-coded highlights (source: yellow, target: blue).
• Navigation Support: Quickly jump between differences for efficient resolution.
• Progress Tracking: Mark resources as “Reviewed” or “Seen” to monitor resolution progress.

​

Flexible merge overrides

Handle unresolved conflicts with the Merge Anyway option, which provides flexibility while maintaining control over outcomes:

• A confirmation modal explains how unresolved conflicts will be handled (e.g., prioritizing source branch changes).
• Allows merging to continue even when some conflicts remain unresolved.

​

Read-only state

The Read-Only State feature allows you to access and view submitted versions of your projects while safeguarding the configuration from unintended modifications. By recognizing the visual indicators of the read-only state, you can confidently work within a controlled environment, ensuring the integrity of project’s process definitions.

---

​

Builds

• You can create multiple versions of a project committed before creating a build. You can create a build for any of the committed app versions;
• Once you create a build, you can’t edit the contents of the build (enumerations, substitution tags, integrations). You’ll need to create a new app version.

---

​

Audit view

The “Open Audit View” provides you with a detailed audit log of actions related to work-in-progress (WIP) versions of a process. The primary goal is to ensure transparency and accountability for actions taken before the commit or save process.

You can quickly access and review the history of WIP versions, facilitating efficient decision-making and collaboration.