SOLIDWORKS PDM Vault Configuration: Workflows, States & Permissions

01 Configure the Process, Not the Software

A vault workflow is the engineering change process expressed as software configuration. If that process is unclear, configuring the vault does not clarify it — it makes the ambiguity permanent and considerably harder to modify.

This is the most common implementation failure, and it is not a technical one. A vault is procured, an IT project installs it, and the workflow is configured afterwards by whoever is available, based on how things appear to work. The result encodes a process nobody agreed to, enforced by a system nobody can easily change, and the organisation then works around it.

The work that determines whether a vault succeeds happens before any configuration screen is opened: deciding what the states mean, who may authorise each transition, what a revision represents, and what "released" permits and prohibits.

FirstDocument the process on paper before configuring anything

StatesEach must have a clear operational meaning, not just a name

LayeredEffective permission is the intersection of several grants

TestedEvery transition walked through before go-live

Scope and currency

Capability limits differ substantially between the two product tiers, and the configuration interface changes between releases. Verify tier-specific limits and interface details against the administration guide for the release and tier in service.

02 Anatomy of a Workflow

States

A named condition a document occupies. Every managed file is in exactly one state at any moment, and that state determines what may be done to it and by whom.

Permissions attach to states, not only to folders.
A state can mark a file as the current released version.
Revision increment is typically driven by entering a state.

Transitions

A permitted movement from one state to another. Transitions carry the control: who may perform them, what must be true first, and what happens as a result.

Permission to execute is granted per user or group.
Conditions can block a transition until requirements are met.
Actions can set variables, increment revision or send notifications.

Tier limits shape what is possible

The lower capability tier supports a single workflow with a bounded number of states. That constraint is not merely a count — it means every document type, including CAD files, office documents and purchased data, must travel the same approval path. Where a business has genuinely different routes for a drawing, an engineering change note and a supplier specification, the single-workflow constraint forces a compromise.

The upper tier supports unlimited workflows and states, with automatic routing that directs documents to the appropriate workflow based on their characteristics. This is frequently the deciding factor between tiers, and it is worth evaluating against your actual process rather than against a feature list.

Fewer states than you first think

The instinct is to model every nuance of the current process as a state. Resist it. Each additional state is another set of permissions to maintain, another transition matrix to reason about, and another place for a document to become stuck.

A workflow with four or five well-defined states that people understand outperforms one with twelve that only the administrator can navigate. Where a distinction matters but does not change what may be done to the file, it is usually a variable rather than a state.

03 Designing States & Transitions

Work this out on paper, with the people who actually approve things, before opening the configuration tool.

Step 1List the real statesWhat conditions does a document genuinely occupy in your business? Not what the software offers — what your process recognises. Typically: in work, under review, released, and superseded or obsolete.
Step 2Define each operationallyFor each state, state what may be done to the file and what may not. "Released" is not a label; it is a set of permissions and a commitment about what the file represents.
Step 3Map the permitted transitionsWhich movements are allowed, in both directions. Reverse transitions matter — how does a released document return to work, and who may authorise that?
Step 4Assign authorityWho may perform each transition. This is an organisational decision about approval authority, not an administrative one, and it should be signed off by whoever owns the change process.
Step 5Define entry conditionsWhat must be true before a transition can complete. Required properties populated, a drawing present, an approver identified.
Step 6Define the consequencesWhat happens on transition: revision increment, notification, variable updates, movement between folders.
Step 7Walk it through with real scenariosA routine change, an urgent change, a rejected review, a document that must be recalled after release. If any of these has no path, the design is incomplete.

Design the reverse path deliberately

Forward transitions get careful attention. The path back — a released document returning to work, a rejected review, a recall after issue — is frequently an afterthought, and it is where a workflow becomes unusable in practice.

If returning a released drawing to work requires administrator intervention, engineers will avoid releasing documents at all, and the vault stops reflecting reality. Make the reverse path controlled and available rather than controlled and absent.

04 Revision Schemes

What a revision means, and precisely what event increments it, must be settled before the first document is released. Changing the scheme afterwards leaves historical data on the old basis permanently.

Decisions to make

What a revision represents. Usually a released, externally issued state of the document. Distinguish it clearly from the internal version count, which increments on every check-in and is not the same thing.
What increments it. Ordinarily a transition into a released state, applied automatically by the workflow rather than typed by a user. Manual entry guarantees eventual divergence between the recorded revision and the actual approval history.
The sequence. Alphabetic, numeric, or a combination. Consider whether a pre-release sequence is needed for documents issued for comment before formal release.
Whether drawing and model share a revision. A significant decision with no universally correct answer, discussed below.
How it reaches the title block. The vault should own the value and populate the file property, not the other way round.

Model and drawing revision

Two defensible positions. Shared: the model and its drawing revise together, so a revision identifies one consistent pair. Simpler to explain and to check, at the cost of revising a drawing that has not changed when the model has.

Independent: each carries its own revision, so a drawing correction does not force a model revision. More precise, but it requires the drawing to record which model revision it documents, or the pairing becomes ambiguous.

Either works. What fails is leaving it undecided, which produces both behaviours in the same data set and no way to tell which applies to a given document.

05 The Permission Model

Permissions come from several independent sources and combine. Reasoning about a user's effective access means considering all of them together, which is why permission problems are so often misdiagnosed.

Permission layers and what each governs
Layer	Governs	Typical use
Administrative	What a user may configure — workflows, users, data cards, the vault itself	Restricted to the small group responsible for the system
Folder	What a user may do within a location — read, add, delete, check out	Separating project areas, library content and restricted work
State	What may be done to a file while it occupies a particular state	Preventing modification of released documents by anyone
Transition	Who may move a file between states	Encoding approval authority
Group membership	Aggregates the above; a user inherits from every group they belong to	The unit permissions should be assigned to, rather than individuals

State permission overrides folder permission for released data

The most useful application of the layered model, and the one most often missed. A user may hold full folder permissions and still be unable to modify a released file, because the released state grants nobody write access.

This is the correct configuration — it is what makes "released" mean something. Granting write access on the released state to accommodate an urgent change removes the only real protection the vault provides, and it is a request that should be declined in favour of a proper reverse transition.

Practical principles

Assign to groups, never to individuals. Individual grants become undocumented exceptions that outlive the person and the reason.
Model groups on roles, not on people. Designer, checker, approver, viewer, administrator — roles survive staff changes.
Grant the minimum that lets the role work. Additional access is easy to add and difficult to justify removing later.
Restrict deletion severely. Very few roles need it, and a vault's value depends substantially on things not disappearing.
Give read access broadly. Non-CAD roles who can see released data stop asking engineering for copies, which is one of the clearest returns a vault delivers.
Review annually. Permissions accrue. An annual review against the current organisation chart catches accumulated exceptions.

06 Data Cards & Variable Mapping

The interface between vault metadata and file properties. Configured well it makes the property schema effortless; configured poorly it produces two sets of data that disagree.

A data card presents fields to the user when a file is added or edited. Each field is bound to a variable, and each variable is mapped to where that value lives inside the file — a custom property for a native model, an attribute for other file types. The mapping is what makes the vault and the file agree.

Configuration principles

Bind to the existing property schema. Variables should map to the property names already established in the templates. Introducing a parallel vocabulary in the vault guarantees divergence.
Use controlled lists. Dropdown fields for any value drawn from a known set. Free text on a field that feeds a bill of materials or a search is a slow-motion data quality problem.
Mark required fields and enforce them at transition. A required field on the card can be left blank; a transition condition cannot be bypassed. Use both.
Handle configurations explicitly. Where a file has multiple configurations, decide which values are configuration-specific and configure the card accordingly.
Keep cards short. A card demanding twenty fields at file creation is a card that gets filled with placeholder values.
Let the vault own what the vault owns. Revision, state and approval identity should be written by the workflow, not typed by users — display them read-only on the card.

Automatic numbering

Where the vault allocates identifiers, it removes a whole class of problem: duplicate numbers, gaps, and the spreadsheet that tracked them. Configure a sequence per document class, and populate it into the file property automatically through the card mapping.

Two points to decide first: whether numbers are allocated at creation or at release, and what happens to a number allocated to work that is subsequently abandoned. Neither has a universally correct answer, but both should be answered before go-live rather than encountered afterwards.

07 Conditions, Actions & Notifications

Conditions as quality gates

A transition condition blocks movement until requirements are satisfied. This is the most valuable automation available, because it enforces standards at the moment of release rather than relying on a checking step that may be skipped.

Gate 01

Required data present

Block release where part number, description, material or document class is empty.

Effect: the bill of materials cannot contain blank columns, because incomplete documents cannot be released.

Gate 02

Referenced files ready

Block release of an assembly while its components remain in work.

Effect: a released assembly cannot depend on unreleased content.

Gate 03

Approval recorded

Block release without an identified approver distinct from the author.

Effect: the approval record is a property of the system rather than a convention.

Actions and notifications

Transition actions set variables, increment revision, and can move files between folders. Notifications inform the next party that something awaits them. Both are useful and both are easy to overdo — a workflow generating a notification on every transition trains recipients to ignore all of them.

Notify where someone must act, not where something has merely happened. A reviewer receiving a document for approval needs telling; an author whose own transition succeeded does not.

Automation makes a bad workflow worse

Conditions and actions amplify whatever the workflow already does. A condition on a state that should not exist, or a notification driven by a transition nobody understands, adds friction without adding control.

Get the states, transitions and authorities right and running before adding automation. A simple workflow that people follow is worth considerably more than an elaborate one they circumvent.

08 Testing Before Go-Live

A workflow that has only been configured has not been validated. Walk every path with real accounts before any production data enters the vault.

Test with role accounts, not as administrator. An administrator can do everything, so testing as one validates nothing about permissions.
Walk every transition in both directions. Including the reverse paths and the rejection route.
Verify each condition blocks and each action fires. Confirm a transition is actually prevented when a required field is empty, not merely that the condition is configured.
Check the data card mapping both ways. A value entered on the card must appear in the file property, and a value in the file must appear on the card.
Confirm revision increments as intended and reaches the title block on a real drawing.
Test the scenarios that were hardest to design. Urgent change, recall after release, rejected review. These are where the design is thinnest.
Have an engineer who did not design it try to use it. If they cannot work out how to get a drawing released without help, the workflow needs simplifying rather than the engineer needing training.

Keep a test vault

A separate small vault for testing configuration changes is one of the highest-value things a vault administrator can maintain. Workflow changes applied directly to a production vault affect files already in flight, and some changes are not reversible.

It also serves as the restore rehearsal target, which means one piece of infrastructure covers two obligations.

09 Vault Configuration Checklist

Process documented first. States, authorities and revision rules agreed on paper and signed off before configuration began.
States defined operationally. Each state has a stated meaning in terms of what may and may not be done.
Reverse paths designed. Return to work, rejection and recall all have controlled routes that do not need administrator intervention.
Revision scheme settled. What increments it, the sequence, and whether model and drawing revise together.
Revision owned by the workflow. Incremented automatically, populated into the file property, displayed read-only on the card.
Permissions assigned to role groups. No individual grants; groups modelled on roles rather than people.
Released state protects released data. No write access granted on the released state to anyone.
Read access granted broadly. Non-CAD roles can see released data without asking engineering.
Card variables bound to the existing schema. No parallel vocabulary between templates and vault.
Controlled lists used. Dropdowns for every value drawn from a known set.
Release conditions in place. Required data, referenced file state and approval identity all enforced at transition.
Notifications restrained. Sent where action is required, not on every event.
Every path tested with role accounts. Including reverse transitions and the difficult scenarios.
Test vault maintained. Configuration changes validated outside production.
Permission review scheduled. Annual review against the current organisation.

10 Frequently Asked Questions

How many states should a workflow have?

Fewer than you initially want. Four or five covers most engineering processes: in work, under review, released, and obsolete or superseded, sometimes with a separate state for documents issued for comment before formal release.

The test for an additional state is whether it changes what may be done to the file or who may act on it. If it only records a fact — which project, which phase, which customer — that is a variable, not a state. States carry permissions, and every extra one multiplies the permission matrix you must maintain and reason about.

An urgent change is needed to a released drawing. Should we grant write access on the released state?

No. That single change removes the protection the released state exists to provide, and it will not be reverted afterwards. Every future released document becomes editable, and the vault stops being able to assert that a released file is the file that was approved.

The correct answer is a controlled reverse transition — released back to work, authorised by someone with that authority, recorded in history, with a subsequent release incrementing the revision. If that path is too slow for genuinely urgent work, the remedy is to make the transition faster and better delegated, not to remove the control.

Should the vault or the file own the revision?

The vault, without qualification. Revision is a state of the controlled item, and having the workflow increment it on transition guarantees the recorded revision and the actual approval history cannot diverge. The file property is then populated from the vault so the title block is correct, but the vault holds the authoritative value.

Where the revision is typed into a file property by a user, nothing prevents it being changed without an approval, and eventually it will be. That weakness is one of the strongest arguments for introducing a vault in the first place, so it would be perverse to configure it away.

We are on the lower tier with one workflow. How do we handle different document types?

Design the single workflow around the most controlled document class — typically issued engineering drawings — and accept that other document types travel the same path with some states doing nothing meaningful for them.

Use a document class variable on the data card so that different types remain distinguishable for search, filing and reporting even though they share a route. Where the compromise becomes genuinely obstructive — a supplier specification forced through a drawing approval chain, or a change note that cannot follow its own path — that is a concrete, evidenced argument for the upper tier rather than a general preference for more features.

Series context. This page is part of the KEVOS® SOLIDWORKS environment administration series. It presents general administration practice and is written to be release-independent wherever possible. Where specific versions, limits or supported platforms are cited, they reflect the SOLIDWORKS 2026 release family and should be verified against current vendor documentation before being relied upon for procurement, platform or upgrade decisions.

SOLIDWORKS is a registered trademark of Dassault Systèmes SolidWorks Corporation. Product names are used here for identification and reference only. KEVOS® is independent and is not affiliated with, endorsed by, or a reseller for Dassault Systèmes.