Skip to main content
Versioning in Variable allows you to maintain a history of your products and materials while ensuring data integrity. This is essential for tracking changes over time, maintaining audit trails, and supporting collaborative workflows.

​
Version states

Products and materials can exist in one of five version states: Only a draft is editable. Every other state is immutable, rejection included — a rejected version is not sent back for editing, it is superseded by a new version.
Once a product is locked, its data cannot be changed. This ensures that any references to that version (in other products, reports, or external systems) remain consistent.

​
Where version state appears

Version state is shown wherever an element is listed, not only on its own detail page. A small coloured icon carries it:
  • A dashed file in amber for Draft, a lock in blue for Locked, an eye in purple for In review, a cross in red for Rejected, a check in green for Verified
  • Beside the element’s name on bill-of-materials rows, element pickers, every inline reference to an element, and the Where it’s used tree
  • In a Version column on the Inventory list and the Inventory and LCAs tabs of a product or LCA group
So you can tell — without opening anything — whether the thing you’re about to consume is a draft someone is still editing or a version an auditor has signed off. Every element you version shows its state, drafts included. When a newer version of the element exists, the icon carries a green dot, so one mark tells you both what state you are looking at and that there is something newer behind it. Curated lists that show more than one version of the same element — a product’s Inventory tab, the LCA group tabs — also print the version number beside the name, so duplicate rows stay distinguishable. A first draft prints no number: v1 · Draft says nothing the draft icon hasn’t already.
Two kinds of row show no icon at all. Things that aren’t versioned — transport lanes and activity items, for example — and elements from the Variable database, which carry no version story of your own. Absent means “not versioned”, which is different from “draft”.

​
Filtering a list by version state

The filter row on any element list offers a Version state chip: pick any one of the five states, or Not verified to see everything that hasn’t been signed off yet — which is every state below Verified, so locked, in-review and rejected versions come back alongside drafts. The choice is kept in the URL, so a filtered list is a link you can send someone. Rows the list leaves blank are not returned by any of the options — anything unversioned, and Variable database elements. There is nothing to verify on something you never versioned.

​
Version life-cycle

​
1. Create draft

When you create a new product or material, it starts as a draft:
  • Fully editable
  • Changes save automatically
  • Not visible to external references by default
  • Can be deleted without impact

​
2. Edit and refine

While in draft state:
  • Add and modify inputs
  • Adjust quantities and datasets
  • Update metadata (name, description, taxonomy)
  • Review calculated impacts
  • Make as many changes as needed

​
3. Lock version

When you’re satisfied with the product:
  • Lock the version to make it immutable
  • Locked versions get a version number (1, 2, 3…)
  • The product becomes available for use in other products
  • External systems can reference it with confidence
Locking is permanent for that version. You cannot unlock a version. If changes are needed, create a new version instead.

​
4. Create new version

When updates are required:
  • Create a new draft from any version past draft — locked, in review, rejected, or verified
  • The new draft copies all data from that version
  • Edit the new draft as needed
  • Lock when ready to create the next version

​
Verifying a version

A locked version can be verified — an independent sign-off that the version has been reviewed and can be trusted. Verified is the highest-confidence state, signaling third-party validation rather than just finalization. Verification is carried out by a team member with the Verifier role, who has read-only access plus this capability. Only locked versions can be verified, and verifying never changes the underlying data — it records the sign-off, with an optional note, in the audit history. Verified versions keep their version number and stay immutable. To verify a version in the Variable app, open the version and choose Mark as verified. Verification is available for any product or material that supports versioning. A verified version can’t be edited or deleted, exactly like a locked one. When the data needs to change, fork it into a new draft — the draft takes the next version number, and the sign-off stays with the version it was given to.

​
Taking a version through review

A verifier who isn’t ready to sign off can put the version into review instead. On a locked version, Start review moves it to In review, which records that the version is with a verifier while it waits. The version stays locked throughout, and can be signed off directly at any point. From In review the verifier has two decisions:
  • Approve signs the version off and moves it to Verified, with an optional note.
  • Reject moves it to Rejected. A reason is required, and it is kept in the audit history so the next version’s author knows what to fix.
A rejected version is still immutable — rejection is a verdict, not a return to editing. Make the fixes in a new version. If the rejection itself was the mistake, Un-reject returns the version to In review. Every one of these transitions is recorded in the audit history, with whatever reason or note was given.

​
Un-verifying a version

A sign-off given in error can be revoked. On a verified version, a verifier chooses Un-verify and optionally records a reason. The version returns to locked — still immutable, and available to verify again later. Both the sign-off and the revocation are kept in the audit history.
Un-verifying is not unlocking. It steps a version back from verified to locked; there is no way to return a locked version to draft. It always lands on Locked, whichever route reached Verified — so putting the version back through review means starting a fresh one.

​
Signing off in bulk

A verifier working through a batch — an LCA group’s buckets, a whole inventory list — doesn’t have to open each element in turn. Tick rows in any list with checkboxes and the bulk toolbar slides in carrying a Change state selector. The selector offers the same actions the version selector does, each with the number of selected rows it can act on: Mark as verified, Start review, Reject, Approve, and Un-verify. An action with no eligible rows is disabled. Start review also picks up rejected rows, since un-rejecting lands in the same place. A mixed selection is fine. Each action reaches only the rows already in the state it starts from, and counts the rest as skipped rather than refusing the whole batch. The confirmation dialog spells the split out before you commit — 42 items will change · 7 skipped (not in the state this action starts from) — and carries the same note or reason field as the single-item action, with a reason still required to reject. The result is then reported per outcome — 42 verified · 7 skipped · 1 not found. That second skipped is a different number from the dialog’s: the ineligible rows were never sent, so this one counts rows whose state moved between selecting and confirming. Not found means the row is no longer visible to you. Neither is an error, and the elements that did change keep their new state. Each element is signed off individually in the audit history, exactly as if you had opened every one of them.
Change state is a Verifier action. A modeller ticking the same rows sees the toolbar’s other bulk actions and not this one. Rows that can’t be selected at all — declaration variants, and elements from another company’s claimed catalogue — show their checkbox greyed out, with a tooltip naming what bulk actions do reach.

​
syncId preservation

The syncId is a stable identifier that persists across versions:
Use syncId when you need to track an item across versions in external systems (ERP, PLM). The uuid identifies a specific version, while syncId identifies the logical item regardless of version.

​
syncId rules

  • Must be unique across your organization
  • Can be set during creation
  • Persists through version creation
  • Should be treated as a stable identifier for external integrations
  • Changing it can impact downstream system mappings and references

​
When to create a new version

Create a new version when: Keep editing the current draft when:

​
Version visibility

Control who can see and use different versions:
Locked versions are typically set to appropriate visibility for their intended use. Draft versions are usually kept private until ready.

​
Versions in a CSV export

Both CSV exports carry the version of each row’s element, so a reviewer can tell at a glance whether a line’s numbers are still moving. Version_State reads as Draft, Locked, In review, Rejected, or Verified, spelled the same way as the badge in the app. An element with no version recorded reads as 1 / Draft — the export fills the blank the app leaves empty, so a Variable database element reads as a draft in the file and carries no badge on screen.

​
Working with versions in the API

​
Get latest version

Returns the most recent version of the product with that syncId.

​
Get specific version

Returns the exact version identified by uuid.

​
Create new version

Creating a new version from an existing product in any state past draft — locked, in review, rejected, or verified:
  1. Retrieve that product
  2. Create a new product with the same syncId
  3. The new product starts as a draft with version number incremented

​
Best practices

  1. Lock before sharing - Don’t share draft versions externally; lock first to ensure stability.
  2. Document changes - Use the description or notes field to explain what changed between versions.
  3. Regular reviews - Set up periodic reviews to update products with new supplier data.
  4. Version alignment - When updating a product, consider whether component materials also need new versions.
  5. Clean up drafts - Delete abandoned drafts to keep your inventory tidy.
  6. Use syncId consistently - Map syncId to your internal part numbers for seamless integration.