Property mapping on lifecycle state change

[Ohm_IK]

Problem

A very common requirement in Vault is to automatically populate revision and approval fields on drawings based on lifecycle state changes (Designer, Checker, Approver, Approval Date, Reason for Issue, etc.).

Today, this typically requires:

• Third‑party Vault extensions, or

• Custom jobs built on top of the Job Processor

The end goal for most users is simple: clean, correct data that can be shown directly in the drawing revision block.

Proposed solution – Property mapping on state change

Introduce a built‑in Property Mapping on Lifecycle State Change feature.

On each lifecycle transition, administrators can define one or more mapping rules:

• Source: system property, user‑defined property, or static text

• Target: any writable property

• Action: copy value, set static value, or clear value

The mappings are executed automatically on state change, using the existing Job Processor.

This provides a generic and flexible automation mechanism for setting, transferring, or clearing properties based on lifecycle transitions, without custom API code or third‑party extensions.

Example workflow

Typical use cases include populating revision tables, drawing signatures, approval initials, and approval dates based on lifecycle state changes.

• Work in Progress → For Review
  Copy Created By → Designer

• For Review → For Approval
  Copy Created By → Checked By

• For Approval → Released
  Copy Created By → Eng. Approved By
  Copy Created Date → Eng. Approved Date
  Set Reason for Issue = "Issued for Construction"

• Released → Work in Progress
  Clear approval and revision‑related properties

These properties can then be referenced directly in the drawing revision block, which is the primary driver for this feature.

Value

• Clean, automatic revision and approval data without custom jobs or extensions
• A reusable automation mechanism for lifecycle-driven metadata

[Nick_Hall]

Don't get me started on Vault Revision Tables!

Our current solution for a basic Inventor involves 

• Five custom iProperties - for a basic setup; the setup described above would require more
• Six iLogic Rules, each linked to an Event Trigger
• One overridden Vault prompt
• One Vault LifeCycle with Custom Jobs triggered on the relevant transitions
• A custom Job Handler that can set one or more Vault Properties, depending on file type, to
  1. A fixed value
  2. The value of another property
  3. The result of a formula
  4. Submit a Sync Properties Job for the file

It really should not be this difficult to deliver a robust system and a decent user experience

Nick

[RajSchmidt]

Would be nice to have, but…

As I see it, the mapping works fine. However, Vault cannot actually change a file. (Update a title block, change a field in Word, etc. This would have to work with all the file types where we have interfaces.)

So, updating the actual file is the job of the application. And this works, too. Unless of course, your file is write-protected in the current state. Then the app may update everything but is not allowed to save the changes.

Here comes the job processor: You run it with elevated privileges and allow it to change & save files which are write protected for the common folk.

[Ohm_IK]

I agree that updating the actual file content is handled by the application and the Job Processor. Ideally, the mapping would execute before synchronize and publishing jobs, so that updated properties are included when the file is updated and PDFs are generated.

[RajSchmidt]

There is a sync job you can trigger before anything else starts. You can even trigger it during a lifecycle transition, there is an option in the configuration.

[Nick_Hall]

The issue for me is that while it is possible to create a workflow that delivers a decent UX for Revision Tables, it should work straight out of the box with the standard configuration tools.

It should not require the level of customisation that it does - iLogic, custom job handler, forcing Vault prompt responses

Nick

[ProductivCADUser]

@Nick_Hall 

Exactly.

I find it incomprehensible that the processes described above cannot be handled directly within Vault.
It's simple:
Maintain, check, set, delete, copy revision informations or whatever else you need to do with Metadata.
For life cycle changes. Everything is configurable.
Followed by an update of the CAD file.
Then the subsequent process, such as PDF creation.

Anyone who takes the effort to research this topic in forums (or here at autodesk) or training courses will find that this is a frequently discussed topic among vault administrators. One might think that Autodesk deliberately does not implement such functions directly in Vault so as not to jeopardise the business of third-party providers or Vault software customisers.

Link to simliar topic:
Lifecycle Action: Clear property e.g. for Change Comment - Autodesk Community
Lifecycle Transition Action to Automatically Set Property Values - Autodesk Community
Property mapping on lifecycle state change - Autodesk Community

[pedro_monteiroAPM78]

Vault Lifecycle Transitions currently support actions such as revision bumping, property synchronization, validation checks and Job Server tasks.

However, there is no native way to automatically update Vault properties during a lifecycle transition.

For example:

Pending Eng Validation
          ↓
     Eng Validated

Vault should be able to automatically set properties such as:

• Eng Approved By = Current User
• Eng Approval Date = Current Date/Time

This would eliminate manual updates, improve traceability, and avoid the need for custom Job Processor development or third-party add-ins for a common engineering workflow.

Suggested dynamic values could include:

• Current User
• Current Date/Time
• Current State
• Previous State
• Revision
• Static Value

This would make Vault Lifecycle workflows significantly more powerful while remaining simple to configure.

[Nick_Hall]

@pedro_monteiroAPM78 

That's something that's been needed for years. I ended up writing a custom job handler to do it because I got so frustrated

Nick

[pedro_monteiroAPM78]

@Nick_Hall 

Sometimes it can be frustrating because we invest in a PDM system to improve and standardize engineering workflows, and then we struggle to justify that investment due to relatively small missing features like this.

Writing a custom job handler is certainly a solution, but I believe this should be a standard Vault capability rather than something every company has to develop independently.

[ProductivCADUser]

I support this idea. But as already mentioned, this request isn’t new, and Autodesk has certainly been aware of it for 15 years... Here in the forum, you’ll find several suggestions regarding exactly this point, or others which point to the same missing feature.

I would even extend this functionality to include any metadata; ultimately, it’s up to the company to decide what data should be changed during a lifecycle change.

I agree with you: this capability should be expected from a todays PDM. I’m frustrated that Vault has been so outdated as a PDM for several years now. It’s these small, yet significant, details that make Vault unattractive as a PDM compared to the competition.

[jbauerNuP]

Related existing idea

This extends "Lifecycle: Property set/trigger for State-Change" (idea 7565565, submitted 2017, still Gathering Support) with two things that idea does not cover: a rule set engine with conditions in the style of Copy Design, and an explicit choice between a PRE and a POST transition event.

What we have today

Copy Design already has exactly the mechanism we need, just in the wrong place. Its Action Rule Sets let an administrator define rules made of conditions (property, condition, value) and attach property behaviours to them: Reset, Set Blank, Set Value As, Copy Value From. Rules are ordered and evaluated top to bottom.

At a lifecycle state transition, the Actions tab offers a fixed, hard-coded list instead: bump primary/secondary/tertiary revision, synchronize properties with the Job Server for selected file types, release restrictions, purge, and sync items to Fusion Manage. There is no way to set, clear or reset a Vault property, and no way to make an action conditional on the data.

Problem

For anything beyond that fixed list, administrators of existing Vault environments have only one option: configure a custom job and have a programmer implement it. That means a Job Processor dependency, custom code to maintain across Vault upgrades, and knowledge that usually sits with one person or an external partner. For a task as ordinary as "clear the approver fields when a document goes back into work" that is a very heavy answer, and it is the single most common reason our customers end up with custom code in an otherwise standard Vault.

Request 1 – rule sets on the transition

Add a rule set configuration to the lifecycle transition, modelled on Copy Design Action Rule Sets:

- Rules built from conditions on properties, evaluated in a defined order
- Property actions per rule: Reset, Set Blank, Set Value As, Copy Value From
- Configured in the Vault Settings UI, no code and no custom job required
- Reusable rule sets that can be assigned to several transitions

The concept and the UI already exist in the product. Reusing them at the transition would keep the learning curve for administrators close to zero.

Request 2 – PRE or POST event

Because Vault permissions depend on the lifecycle state, a rule set alone is not enough. The administrator must also be able to declare whether the rules run before or after the state change.

Example: a document is Released. The user has no write permission in that state and moves the document to Work in Progress. Writing the properties has to happen after the transition, once the document is in Work in Progress and the user is allowed to write – so this rule set needs to be a POST event.

The reverse case exists too: when the target state is the locked one, the values have to be written before the transition, so the rule set has to run as a PRE event.

A simple PRE/POST selector per rule set at the transition would cover both, and would make it explicit instead of something administrators have to discover by trial and error.

Benefit

- Removes the most frequent reason for writing custom Vault jobs
- Standard, upgrade-safe configuration instead of maintained code
- Consistent with a rule set concept administrators already know from Copy Design
- Predictable behaviour with state-dependent permissions, because PRE/POST is explicit

[ProductivCADUser]

Link to simliar topic:
Lifecycle Action: Clear property e.g. for Change Comment - Autodesk Community
Lifecycle Transition Action to Automatically Set Property Values - Autodesk Community
Property mapping on lifecycle state change - Autodesk Community

[Ohm_IK]

Not an oversight – but a fundamental flaw
I recently discussed this with Autodesk representatives and got the impression that this is viewed as a relatively small oversight. I actually think it highlights a much more fundamental weakness in Vault.

Vault is a PDM system built around reliably controlling documents: their lifecycle state, revision, approval and release. Yet it cannot reliably ensure that the files it manages actually contain that same information.

Vault knows the current revision. It knows the lifecycle state. It knows who approved a document and when. It controls the transition that makes the document Released. Yet getting that information accurately and consistently into the document itself is surprisingly difficult.

This becomes even harder to understand when Vault is also responsible for automatically generating secondary files such as PDFs and DWFs. It can release a document and generate the corresponding PDF, without being able to guarantee that the revision and approval information shown in that PDF actually represents the state Vault has just assigned to it.

To me, that is not a small oversight. It is a fundamental flaw in a document management system: Vault can control the document, but it cannot reliably ensure that the document reflects what Vault controls.

What makes it particularly frustrating is that this does not appear to require some major new capability. The missing piece is relatively simple, yet its absence forces companies into custom code and complicated workflows just to achieve something that should be fundamental to a PDM system.