Autodesk Vault Professional - Lifecycles… Overexplained.

By Chris Smith

Introduction

If you’ve worked with Autodesk Vault Professional for more than five minutes, you’ve probably battled with lifecycles. Usually what that means is:

• Too many states
• Too many transitions
• Too many permissions

And absolutely nobody remembers why it was built that way.

So, let’s overexplain lifecycles properly, so you can simplify them later with confidence focusing on States, Security, and work flow transitions.

What is a lifecycle

At its core, a lifecycle in Vault is simply a rulebook that controls what can happen to a file, when, and by whom.

It defines:

• States (The current “state” of a file - Work in Progress, Released, etc.)
• Transitions (who can move it along the workflow and under what conditions)
• Security (who can read, modify, delete, download files in each State)
• Revision behaviour (does this bump revision or not?)

That’s it. Everything else is implementation detail.

The Example

The image at the start of this blog is a representation of a lifecycle shown as a flow chart. The States, Transitions, and even Security can be viewed in this image.

The key below will help understand the legends in the image.

The flowchart image is essentially a graphic representation of this lifecycle in Vault.

Lifecycle states break down.

This Vault lifecycle is a general engineering workflow with an additional customer approval step.

The main workflow for files associated with this lifecycle is:

1. Work In Progress
   Engineers (Designers) create and work on design files. Files must be editable for the design team (Vault Group) while in this state. This is also the default state as can be seen by the tick next to the state. 
   
   This means any new files that are added to the Vault and get assigned to this lifecycle will be set to the Work in Progress state by default.
2. For Review 
   The engineers have reached a stage where the design file requires an internal, peer review. The files are not “locked” by the Vault, but modification rights have been removed for all users when in this state.
3. Approval 
   Following a successful internal review, the design files are submitted to the customer for Approval. This state is similar to the review stat in that all users are denied modification rights, but the files are not “locked”
4. Released 
   This is a special state in Vault in which the file receives a “locked” status from Vault. No user may edit these files regardless of security level and must progress files out of the Released state to make future modifications. This will automatically bump the revision number.

This is the general workflow that my engineering documentation will follow when associated to this lifecycle.

There are also 2 additional “special” states included in this lifecycle.

• Quick Change 
  When a file is set to a Released state Vault will treat that file differently. It prevents any changes and as part of the lifecycle transition, will bump the revision of the file when the file is moved back into Work in Progress state so that changes can be made. This makes sense, as any changes to the design would generally be a new revision. There are however times when we need to make a “Quick Change”. A typo on a drawing, an appearance on a model, punctuation in an iProperty, etc. By including this state, we can make the file editable without changing the revision number.
• Obsolete 
  One of the best features in Autodesk Vault is the ability to reach back through the history of a design and extract historic information from Vault. Having the ability to reference a design from 2, 5, 10 years or more after multiple design changes gives designers the ability to recall those designs in ways previously not possible. If users were allowed to delete information from Vault this rich history would break down. Because of this we create the Obsolete state. This state allows users to lock and hide files in the Vault preventing them from being used in further design projects, but ensuring the files are still available for historic designs should they be recalled. It also allows for these files to be reinstated should that be a requirement.

By using these states, we can ensure that our design data is controlled, traceable, and reliable throughout its entire lifecycle.

Lifecycle states in Autodesk Vault are not just labels — they actively control behaviour, permissions, and revisioning. This gives us several key advantages:

• Data integrity – Files cannot be accidentally modified once they reach Review, Approval, or Released states. This prevents uncontrolled edits and protects approved designs from unintended change.
• Clear ownership and responsibility – Each state reflects where the file sits in the engineering process. Designers know when they can modify data, reviewers know when action is required, and manufacturing knows when a file is formally Released.
• Automatic revision control – When a file leaves the Released state through the normal workflow, Vault automatically increments the revision. This enforces proper engineering change practice without relying on manual processes.
• Controlled flexibility – The Quick-Change state provides a structured exception process. Minor corrections can be made without disrupting revision history, while still maintaining control and visibility of the change.
• Long-term traceability – The Obsolete state ensures that historical data is preserved. Designs are never permanently deleted, meaning previous revisions and legacy projects can always be reviewed, referenced, or reinstated if required.
• Reduced risk in downstream processes – Manufacturing, procurement, and external stakeholders can trust that “Released” means final. There is no ambiguity about whether a file is ready for production.

Ultimately, lifecycle states allow us to embed our engineering process directly into Vault. Instead of relying on manual discipline, spreadsheets, or informal communication, the system enforces the workflow automatically. This improves consistency, reduces errors, supports compliance requirements, and protects the intellectual property of the business.

In short, lifecycle states transform Vault from a simple file storage system into a structured engineering data management solution that supports controlled design, formal approval, and complete historical accountability.

Lifecycle security overview

During different stages of a design process, access to data needs to change. Early in development, designers require full control to iterate and refine their work. Later in the process, stability becomes more important than flexibility.

Without lifecycle-based security, it becomes very easy for:

• Manufacturing/Production to build from an outdated drawing
• Sales to quote from a concept model 
• Designers to unintentionally modify a file that has already been approved
   

Lifecycle security in Autodesk Vault allows permissions and visibility to change automatically as a file progresses through its workflow.

For example:

• Work In Progress - Designers can modify files freely
• Review / Approval - Files remain visible but are protected from edits
• Released - Files are locked and formally controlled
   

This removes ambiguity. The file’s state clearly communicates its status, and Vault enforces the rules behind the scenes. Rather than relying on users to “remember not to edit that,” the system simply makes it impossible to do the wrong thing.

And that’s really the point of lifecycle security — it replaces good intentions with enforced process control.

There are 4 options that we can allow or deny for Vault users in the lifecycle security window for each state in the lifecycle. Read, Modify, Delete, and Download.

Note – The JP row is for the Job Processor specific user in my Vault configuration and can be ignored

Read
This essentially sets whether a user/group can see the Vault file. If a user/group Read access is set to,

• Allow - the file will be visible
• Deny - the file will not show up to that user/group.

In the image above from the Work in Progress state, Administrators, Manager, and designers are all set to allow. The consumers group (Sales, production, procurement, etc) are set to Deny.

This ensures,

• Admins can fix problems
• Managers can keep track of projects
• Designers can work on files
• Downstream departments cannot “see” any files in this state.

By restricting Read access, we prevent early visibility of incomplete or unapproved data.

Because in engineering, visibility equals perceived validity — and that can create risk if not controlled.

Modify

The Modify permission controls whether a user or group can change a file’s data while it is in a specific lifecycle state.

• Allow, the user can check the file out, edit it, update properties, and check it back in.
• Deny, the file can still be visible (if Read is allowed), but it cannot be altered.

This distinction is important. A user may be able to see a file without being able to change it.

In the Work in Progress state:

• Designers - Modify = Allow
• Managers - Modify = Deny
• Consumers - Read = Deny (so Modify is irrelevant)

This ensures that:

• Designers can actively develop and refine the design
• Managers can observe progress without accidentally editing files
• Sales and Production cannot access incomplete work

Now compare that to the Review or Approval states.

Even though designers can still see the file, Modify is set to Deny. This prevents further edits while the file is under review. The design is temporarily stabilised so it can be evaluated without moving targets.

This is where lifecycle security becomes powerful. Instead of sending emails saying, “Please don’t change this while it’s being reviewed,” Vault simply enforces the rule. The system removes the ability to modify the file until it transitions back to an editable state.

In other words, the Modify permission controls who is allowed to change history — not just who can see it.

Delete

This permission determines whether a user or group can permanently remove a file from Vault and is usually straight forward.

We do NOT want users deleting files from Vault. As previously mentioned, this would upset the history from the Vault files, break links, and potentially introduce errors into Vault. Administrator should have this option set to allowed for problem resolution purposes, but all other users should be set to Deny on all lifecycle states.

Vault is designed to be a system of record. It stores revision history, lifecycle transitions, and design evolution over time. If users were free to delete files:

• Audit trails could be broken
• Released designs could disappear
• Historic project data could be lost
• Downstream references could fail

Instead of deleting files, we typically use lifecycle states like Obsolete to retire data safely while preserving its history.

• Deletion should be rare.
• Obsolescence should be controlled.
• History should be protected.

In short, Delete controls who can erase history, and in most organisations, that power should be tightly controlled.

Download

The Download permission controls whether a user or group can extract a copy of the file from Vault to their local machine.

• Allow – A user can Get/Download a copy of the file from Vault
• Deny – Although a file may be visible (if Read is set to allow) a copy cannot be pulled from the Vault

This distinction matters more than most people realise. A user being able to see a file does not automatically mean they should be able to take a copy of it.

Why Download Control Is Important

In many environments:

• Designers - Download = Allow
• Managers - Download = Allow
• Consumers - Download = Deny (depending on policy)

Why?

Because once a file leaves Vault:

• It is no longer lifecycle controlled
• It is no longer revision managed
• It can be emailed, copied, or modified outside of process

Vault cannot govern what happens to a file that exists outside its system. Imagine a Released drawing.

If a user can download it freely, they could:

• Email it externally without approval
• Store it locally and accidentally use an outdated copy later
• Modify it outside Vault and reintroduce uncontrolled changes

By controlling Download permissions, you reduce the risk of unmanaged file distribution and protect intellectual property. In some organisations, downstream teams are given access only to neutral formats (PDF, DWF, STEP) rather than native CAD files. Download restrictions help enforce that separation.

Together, these permissions allow Autodesk Vault to enforce not just workflow — but governance. And that’s ultimately what lifecycle security is about. Not restricting users unnecessarily but making sure the system prevents the kinds of mistakes that are expensive, embarrassing, or irreversible.

Transitions overview

If our lifecycle states define where a file is in the workflow, transitions define how it moves.

A transition is the controlled pathway that allows a file to move from one state to another. Without transitions, lifecycle states would just be static labels. Transitions are what turn a lifecycle into a workflow.

Every time a file changes state — for example:

• Work In Progress to Review
• Review to Approval
• Approval to Released
• Released to Work In Progress

It does so through a defined transition. And those transitions can be controlled just as tightly as the states themselves.

A transition can:

• Restrict who is allowed to perform it
• Require certain conditions to be met
• Enforce property rules
• Perform actions, like bump revision numbers
• Trigger lifecycle events (such as locking a file)

In other words, transitions control how change happens, not just whether it happens.

Each transition can be edited to individually control,

Criteria

Criteria are like A set of rules that must be followed before the file can move to the next state in the workflow, based on the file properties, also known as metadata. These rules compare the metadata values using conditions like, Starts with, Ends with, contains, Is not empty, etc.

If a file does not meet all these criteria the file cannot progress and the user will be notified of a property noncompliance.

This means that transition criteria should be thoroughly considered before enforcing the rules. Criteria can enforce good working practices, ensuring users are filling in the correct metadata for use downstream, but it can also serve to block some files from progressing in the workflow should the criteria be impossible to achieve.

Actions

Actions are the automated tasks we can ask of Vault when files move between states to ensure best working practices, enforce company standards, and protect data integrity when progressing files in the lifecycle while removing reliance on manual processes and checks.

The actions available within a lifecycle transition can be configured to:

• Maintain revision control – Automatically increment revisions when leaving a Released state.
• Validate related data – Ensure dependent or linked files are also Released or Obsolete before allowing progression.
• Trigger the Job Processor – Generate secondary outputs such as PDF, DXF, or STEP files, or update property values automatically.
• Purge old versions – Remove unused Vault versions based on lifecycle rules to maintain database efficiency.

Without actions, users must remember to:

• Update revisions correctly
• Check assembly dependencies
• Generate manufacturing outputs
• Maintain file housekeeping

With actions configured properly, Vault does it automatically. No missed PDFs. No forgotten revision bumps. No assemblies containing unreleased components.

Actions turn lifecycle transitions from simple state changes into controlled, automated process steps. And that’s where our lifecycles stop being administrative and start becoming operational.

Custom job types

Custom job types are a way for companies to create their own Vault jobs using code that can be actioned by the Job Processor. A job is created by a programmer and would require understanding of the .NET language, dlls, and creating software plugins. But custom jobs open up the Vault through programming interfaces to allow:

• Interactions with 3rd party software, like ERP systems or cloud drives
• Sharing of Vault data outside of the Vault
• Additional file generation

And much more.

Security

A large part of the control that Vault professional can provide is linked to the Vault lifecycles and the States contained within them, giving read, write, and download access to users at the right time. Transition security can also control who can move files between these states at different stages of the design process.

For example, we do want designers to progress files from Work in Progress to Review, but we never want them to move files from Work in Progress to Released, skipping the peer review and customer approval steps.

By applying security to the transitions, we can control who can move the files between states and which states they can be moved to from their current state.

Peer review

A relatively recent addition to Vault transitions is the Peer Review option.

Like the Criteria tab, the Peer Review system will check for property compliance.

The Peer Review system differs however in that it can use multiple rules containing varying criteria checks to trigger a peer review step and will check though each rule, top to bottom in the rule list until a criteria set has been matched.

Should a rule return a positive check the Vault will then check that the user trying to progress the file to the next state is not the same user who made the previous state change, forcing a 2-person checking system. Providing the criteria check comes back as true, Vault will perform this check. If no rules are present, or no rule triggers, the peer review system will be ignored.

Transitions can be the most time-consuming part of the lifecycle creation process but usually have the highest impact on control once the initial setup stage has been completed.

Transitions are a vital part of any robust lifecycle workflow, turning a simple state model into an enforceable, and controllable, engineering process.

This detailed explanation of the principles of Lifecycles in the PDM software Autodesk Vault Professional was brought to you by ARKANCE. Contact us for advice on your PDM system and/or for Autodesk Vault training, implementation and integration services. Worldwide.