Vault IdeaStation
Share your wish list directly with the Autodesk Vault Development Team
New Idea
30 Kudos

I have a unique request that I think would benefit many users.  I have a need to specify a criteria be met prior to a state change.  In my example, I need to have a particular property with a value before we can send a file to the next state.  This property is not mandatory until we reach this state, so the compliance flag is not displayed for this. 


The problem we experience occurs when someone forgets to fill in the required value and then tries to submit the file to the next state.  The resulting error message indicates that there is missing information, but is not specific as to the missing or unfulfilled criteria.  It would be very beneficial to have the error dialog indicate the particular criteria that failed.  If the user could see the property missing the value or something similar to direct them, it would be very useful.


6 Kudos

From what I can tell right now, users have very limited control over the visibility of file records in the Thin Client.  You can either see all versions of a document or all Released versions of a document.  Both options can lead to confusion based on workflow.


What if you want to only show the latest Released version of a file record?  You can't do that - all Released versions are currently displayed.  Worse, what if you use a lifecycle like the built-in Flexible Release Process and perform a Quick Change?  Now you have two versions at a particular revision.  The result can be something like this:





To provide better control over file record visibility in the Thin Client, I'd like to see the options for File visibility expanded to a total of four (from the two we have now).  These four options would be as follows:


  1. Show all file versions
  2. Show all Released file versions (allow multiple versions at the same Revision)
  3. Show all Released file versions (show only the latest version of each Revision)
  4. Show only the latest Released file version

I think one and four are self explanatory.  Two and three might be confusing to the user, but I think they're ultimately necessary.  Option two would function like the current 'show only released' versions, and would lead to a list like the screen capture above.  Option three would be new functionality, and would hide all Released versions of a particular Revision level except for the latest.  This option would hide versions that had been superseded by activities like Quick Change, and so in the example screen capture above, version 6 of the file would not be visible in the Thin Client.

Status: Under Review

Thank you for your feedback.  We will take a look at this and see what we can do.

1 Kudo

Status change - Apply Button

Status: Comments Requested
by hans_hydrac on ‎12-20-2014 01:22 AM

Make a "Apply" Button in the Status Change Dialog.

For example

I must change the status from "in wok" to "check in" and then from "check in" to "ready to produce"


Bildschirmfoto 2014-12-20 um 10.13.30.png

Status: Comments Requested

Is there a reason why your transitions are not configured so that you can't go straight to "ready to produce" from "in work"?

91 Kudos

Rollback Revision Increment

Status: Accepted
by Valued Contributor jeff.noel on ‎07-25-2012 12:44 PM



If a user accidently makes a change state of a model from Released to Work In Progress, it will increment the revision, and then leave us with no way to go back to the previous revision.  I understand why you would do this, as we shouldn't be going backwards with Revisions, so I don't believe every user should have access to this functionality, but an Administrator should be able to override the Revision if they determined there was a mistake made and we need to go backwards.



Status: Accepted
15 Kudos

I've known this issue has existed from about day one in Productstream and now Vault Pro, but
it's time that this security issue is fixed. I feel its a major defect, but they tell me it's "AS DESIGNED".


If you are using items, this has the potential to be costly to your organization. It allows users to print an older version of a file which has been revised and it still shows the water mark of "RELEASED". All without any kind of warning.


We are dealing with items and when an item has several revisions and you toggle back thru the revisions, the drawings
linked to that revision still have a water mark of released, even though the drawing is an old - revised drawing.


The attached video illustrates this disaster waiting to happen.


There has to be a way to prevent the printing of older drawings with "RELEASED" on them. The water mark should say "VOIDED Drawing" or the like when a user toggles the revision level back. Any guidance here on how to
fix this issue?


Steve Hilvers

95 Kudos

When creating and working with lifecycle states, I want to be an environment like this...



Something with boxes and arrows that I can drag around.  I graphical approach like this is easier to work with and provide an easy way to see how files get routed through the entire lifecycle.


5 Kudos

vault revision challenges

Status: New Idea
by *Expert Elite* on ‎09-03-2014 07:05 AM

there have been a few posts about what users or admins would like to have to be able to manage revisions a bit better, especially when we wish to undo an accidental rev bump for example.


an accidental rev bump may happen if a state change has the rev bump action set to fire, and a user chooses the state change by accident.


i such a case, maybe we could have some functionality implemented to warn the user, and ask for confirmation at the time, prior to the rev bump being fired!


by the way, how are we going with the earlier requests on this topic?

22 Kudos

I think it is crazy that everytime the state is changed within vault, specifically from "Released" to WIP, I have to synchronize the properties.  Why aren't the properties automatically syncing when the state is changed.  They should be.  Changing states should not be a two step process.

50 Kudos

Better tools for managing security

Status: Accepted
by Employee on ‎06-26-2012 05:11 AM

Folder and lifecycle state security is a useful feature, but it can be really hard to use.  For example, it's hard to find out which users have access to which folders.  Likewise if a user doesn't have access, it can be hard to figure out why.  If you are managing many folders, you are forced to manage them one at a time.


One possible improvement to provide a view like in the Effective Folder Permissions app, which unrolls the security settings to show a per-user view.


Status: Accepted
6 Kudos

Vault Feature Request: When you obsolete an item it should obsolete all previous revisions, released or not.


Obsolete Items are still viewable in Web Client because some previous revisions are released


Ref: previous Autodesk case 09411810 and new Autodesk case 09515277


Also see attached Word doc with relevant context as "Obsolete Item scenario - public.doc"


The customer has the advised workflow and has asked for this feature request case be opened with Autodesk to obsolete all previous revisions, released or not.


The reasoning is so that Web Client users cannot access parts in error that are no longer in production.


The business case for this company involves 35 seats of Vault Pro 2014 and several dozen more Vault Web Client users at multiple sites routinely relying upon the accuracy of parts that are accessible as 'in production'.


They do not want obsolete parts being requisitioned or ordered as parts of extensive bills of material, for example.


They understand that this feature request will likely not be made available in Vault 2014. They have the workflow workaround in place as an alternative as detailed in the attached Obsolete Item scenario - public.doc

Submit Your Ideas

Share and shape product ideas.

New Idea
You are not logged in.

Log into access your profile, ask and answer questions, share ideas and more. Haven't signed up yet? Register

Top Kudoed Authors