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 dot in its own colour, 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

​
What a copy carries

Both ways of copying a product carry its EPD onto the copy — Duplicate in the product’s ⋯ menu, and Edit on a version past draft, which forks the next version — along with the PCR it was declared against, its program operator, contacts and verifiers, and its scenarios and attached files.
Duplicating is not a way to start a product from a blank declaration — a duplicate always arrives with one.
The copy’s declaration always starts as a Draft, and it claims none of the identity a registry issued: registration number, declaration number, issue date and valid-until date are all cleared. Submission history stays with the version that was submitted. Edit copies nothing when the chain already holds a draft: it opens that draft instead of forking a second one, so what the draft carries is whatever it was given when it was forked. The two paths differ in one place. A new version continues the declaration’s own version chain, so the declaration’s history follows the product’s — unless the declaration is still a draft, in which case the copy starts a fresh chain, since a chain holds one draft at a time. A duplicate is a new product, so its declaration always starts a fresh chain. Only the product you asked to copy carries a declaration. Where a copy pulls in the products behind the bill of materials as well, those arrive without one.

​
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. Products, parts, transport lanes, and LCA groups can be verified. Before signing off a product, part, transport lane, or LCA group, Variable checks the elements it uses. Every element your company owns must already be verified; elements owned by the Variable database or another company do not need your sign-off. The same check applies when you Approve a version in review. An LCA group must have its inventory products and transport lanes verified before the group can be verified. If an element blocks sign-off, the dialog names it, shows its version state and where it sits in the model, and disables Mark as verified. Verify the listed elements from the bottom of the model upward, then return to the parent. You can verify inventory products in a batch with Change state on the inventory list. 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. An LCA group version is the exception for its LCAs: a version past draft — locked, in review, rejected or verified — still takes LCAs and lets them go. An LCA joins a version only when the group’s inventory already holds every source it uses. If a source is missing, add it to the inventory first, or on a version past draft create a new draft and add the LCA there. An LCA can sit in several versions of one group but not in two groups, and a draft LCA sits in one version only. A new draft version of a group takes its LCAs with it: a locked LCA stays in the earlier version too, and a draft LCA moves to the new version. The reference LCA carries over only when it is locked: a draft reference LCA moves without its designation, so neither version keeps a reference LCA until you set one.

​
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 also returns verified versions that use this element to Locked, up through their consuming products and LCA groups. Re-verify from the affected element upward once each part of the model has been reviewed again. This also applies when you un-verify from the inventory list’s bulk action.
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. Transport lanes can be ticked too, in any list that shows them, an LCA group’s Transport tab included. An LCA group version that is locked or verified keeps its checkboxes for a verifier, so the version under review can be signed off from its own inventory. While a lane is selected, Change state is the only action on the toolbar. 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. For Mark as verified, a row whose model still uses unverified elements is blocked, separate from skipped or not found. The result counts blocked rows and opens Cannot verify, which names each unverified element, where it sits in the model, and which selected rows it blocks. Verify those elements first, then retry the blocked rows. 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, elements from another company’s claimed catalogue, and transport lanes for anyone but a verifier — 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.