🔄 Migration to the Workflow Builder v2

Where today's workflow (process) builder V1 behaviour is described, V1 names are used: Process Configuration for the admin surface and the Process tab for the user surface. V2 names are used everywhere else.

1. What became what

2. Steps and actions become manual form nodes

3. Gates become manual review nodes

4. The Process tab becomes the Action section

5. Phase tags are not migrated

6. Other changes

7. What has no V1 equivalent

🗺️ 1. What became what

📝 2. Steps and actions become manual form nodes

In V1, one thing a user does is assembled from three nested objects: an Action Step holds one or more Actions, and each action holds its Forms. In V2 that collapses into one Manual form node.

The migration is per action, not per step: every V1 action becomes a single Manual form node. A step that contained three actions therefore becomes three Manual form nodes, connected in sequence.

Example:

Step “Decision” with actions “Set Description” and “Assign Users” becomes two manual form nodes “Decision - Set Description” and “Decision - “Assign Users”. Steps with a single action keep the step title.

What the node adds

Beyond what the action carried, a Manual form node (1) also configures the action button itself (2) (label, colour, and appearance — solid, subtle or ghost), a condition to complete (5), an auto-continue (6) toggle, and its own next-node selection. Forms (3) gain two block types alongside Section and Rating: Columns, which lay blocks out side by side, and Information block, which carries explanatory text for the person filling the form in.

What the user sees instead

In V1 the user opens the Process tab, fills the form, clicks Submit action to save, then clicks Complete to submit the step for review. In V2 the user clicks the action button on the Actions section on the element, which opens a drawer holding the form (edits autosave).

One button reads Save while the condition to complete is unmet, and Save & Next once it is met or if no condition is set. Submitting writes the values to the element and advances the workflow.

Important notes:

• The three-layer nesting is gone, so there is no longer a container that groups several user actions under one heading. Grouping is expressed by the order of the nodes on the canvas.
• Deleting a V1 action deleted its forms, and deleting a step deleted its actions and their forms. In V2 a form belongs to the node it is configured on.

✅ 3. Gates become manual review nodes

Every V1 Gate becomes a single Manual review node. The decision model carries over almost unchanged; two things that used to be toggles on the gate become nodes of their own. Set Reviewers are carried over.

What the node adds

A configurable action button, a condition to complete that can gate Validate behind criteria beyond the approval count — "approvals > 2 AND budget > 1M" — and an auto-continue toggle, available where the review has a single next node.

What the reviewer sees instead

V1 offers Approve, revoke approval, and Request changes with a mandatory comment, with Validate becoming active once enough approvals are in and the validating expert choosing the next step.

V2 opens a review drawer built as a split button: See submissions, plus Fast approve, Fast request changes and Validate. The drawer shows who has approved, who is still pending, and any open change requests with their comments. It shows the values the submitter entered, with an Edit that opens the form so a reviewer can correct a small error in place rather than sending the whole thing back. Where the path forks after the review, the validating reviewer still chooses the branch on Validate.

Important notes:

• When Validate is unavailable, a popover on the button lists every unmet check – the approval count, the unmet conditions – so the reviewer can see what is missing. V1 gave no such explanation.
• In V1, a single gate could carry several conversion destinations. A V2 Convert element node carries one destination (e.g. can be combined with prior routing nodes to route into different conversion paths based on criteria).

📄 4. The Process tab becomes the Actions section

The Process tab is removed. Nothing replaces it as a tab.

Instead, every action button from every workflow active on an element appears in a single Actions section on the element detail page. Clicking a button opens the matching drawer – the form, the review, or the URL – and submitting there both writes to the element and advances the workflow.

Note: on migration, buttons are automatically named after their step ("Open <step title>"). They can be renamed to your liking afterward.

Beyond the detail page. The same buttons are available in the stack view, where the form and the review open as modals rather than drawers – same configuration, same flow, different container.

Admins can also move the buttons: a workflow action widget in the element configuration's form builder places them anywhere on the detail page rather than at the default top-right.

Where the history went

V1 tracked approvals, rejections, actions and comments in the actions and activity log on the gate. V2 carries an Activities log on the element detail page covering every workflow action on that element, automated and manual, filterable by All, Auto, Manual or Reviews, with each entry tagged by the workflow that produced it. Note: for now, only workflow-related property change are logged.

🎚️ 5. Phase tags are not migrated

Phases stop being a workflow object. This is the change most likely to need explaining.

In V1, a phase tag is created inside the workflow builder, reused across steps as a tag and (potentially) across workflows. The phase tag carries a title and a colour, is attached to a step, and drives the pearl chain on the element. Its order is maintained through Manage Phase Order in the workflow settings menu.

For now, in V2 there is no phase tag concept:

• Existing v1 phase tags are not migrated to a drodpown property, per workflow.
• Since a phase tag does not have any impact on the execution of the v1 workflow
• However, the phase tag display as a pearl chain on the element is removed and views utilizing the phase filter have to be reconfigured.
• Note: ITONICS is working on a potential migration path in the near future

Optional (short-term) workaround approach:

• Creating a (custom) dropdown property on the element type, same options and ordered like the prior “Phases”. Optionally, pin the property to the element header with "display as step", which renders it as the pearl chain.
• You can mimic “changing the phase” by setting the property with an Update element node.
• In this approach: a phase change no longer has to sit on a step; an Update element node can set it at any point, including after an automation rather than after a user action.

🔧 6. Other changes

E-mail notifications become nodes

• V1 carries an e-mail toggle with custom text on an action and on a gate, which fires when that action or gate needs performing.
• V2 removes both toggles and provides a Send email node with configurable recipients, subject and body, placed before the Manual Form and/or Review node in v2 (note: the system notification is kept when a manual review is validated). Recipients currently cover specific users and user search fields.

Two consequences worth knowing: in V1 no notification was sent when the same user was both action assignee and gate reviewer; and V1 tied a notification to the moment a task became due. In V2 the send happens when the workflow reaches the node.

Further, since now the “send email” node is separate, you can now review and change the default subjects without changing the list of assignees. Also: v2 now supports rich text in the email body; make use of it by updating your prior message.

Element conversion becomes a node

• V1 configures conversion as a toggle on a gate, with a destination element type, an archive-original toggle, a copy-comments-and-relations toggle, and the option to add further destinations.
• V2 provides a Convert element node carrying destination, archive and copy options, placed anywhere in the flow rather than only on a decision point.

Start-node criteria become the Matching elements trigger

• V1 filters which elements of a type follow the process using criteria on the start node, combined with AND/OR.
• V2 keeps this as the Matching elements start trigger, configured the same way — property, operator, value, combined with AND/OR. What changes is that it now sits alongside other trigger types rather than being the only way a workflow starts.
• If no criteria has been set, the new trigger is Always apply.

Linking is no longer one-in, one-out

• In V1 a step could be linked to one node in and one node out, and only a gate could lead to several paths.
• V2 removes that constraint: routing nodes fan out by design, a Manual review can lead to several next nodes, and each branch has its own connection point. The next node can also be chosen in the configuration panel rather than only by dragging on the canvas.

Shared steps and shared forms

• In V1, steps and their forms are shared across workflows: editing a form inside a shared step updates every workflow using that step, and the documented way to avoid this is to delete the step in the duplicated workflow and rebuild it from scratch.
• In V2 a form is configured on the node that uses it.

The workflow settings menu loses one entry

• Version History, Rename, Duplicate and Delete are unchanged.
• Manage Phase Order is removed

Multi-destination gates

• V1 allows several conversion destinations on one gate; a V2 Convert element node takes one destination.
• In v2, a multi-conversion node is migrated and a popup decision shown on the gate exit which convert to conduct.

Multi-phase properties on one element type

• A customer running several workflows on one element type can target the same or use several phase properties – using the same must cautiously be configured to not unintentionally overwrite progress of another workflow action.

Migration of running elements

• Forms submitted inside a not-yet-completed step in v1, are considered “submitted”.

• Example: In v1, a step with two forms – both are submitted but the step is not completed – become two submitted forms in v2.

• Those submissions show the element’s current field values:
• Each element receives one continuous workflow history logged in the Activities tab on the element detail page in v2. “Step completed” entries are deprecated and now considered a form completion.

📋 7. What has no V1 equivalent

These are not migrations – nothing in V1 maps onto them – but they are the reason several V1 workarounds are no longer necessary.