- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Email to a Friend
- Printer Friendly Page
- Report Inappropriate Content
Hi,
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.
Thanks,
- Mark as Read
- Mark as New
- Bookmark
- Highlight
- Email to a Friend
- Report Inappropriate Content
It would also be nice to have a mechanism to be able to pick the type of revision increment when changing state. There are situations where I don't want to always revise by the Primary and need to pick Secondary or Tertiary. Currently I would have to turn off Bump Revision or set it to Bump Tertiary and change revision again once it's in Work In Progress' state to get what I want.
- Mark as Read
- Mark as New
- Bookmark
- Highlight
- Email to a Friend
- Report Inappropriate Content
- Mark as Read
- Mark as New
- Bookmark
- Highlight
- Email to a Friend
- Report Inappropriate Content
I would like to have this request above almost all others. it is such a huge hassle if a user accidentilly bumps a rev through state change or sync property. Especially if a file is used on several assemblies.
- Mark as Read
- Mark as New
- Bookmark
- Highlight
- Email to a Friend
- Report Inappropriate Content
I agree 100% that Vault needs this functionality. We have Vault Professional yet we have no plans for implemention the Vault item master and ECO module. We have an item master that lives in our ERP system and have not currentl plans to maintain two. We need to capability to roll back revisions when a change gets rejected or cancelled. I've discussed this with some Autodesk folks and they all say implement the item master and ECO module and then you can do this. NOT ALL CUSTOMERS CAN OR ARE WILLING TO DO THIS! Vault needs to have this file centric functionality. We moved from 3rd party PDM to Vault last year and this is the sngle most feature that we as a company feel needs to be part of Vault.
John Weiss
CAD Administrator
Follett Corporation
- Mark as Read
- Mark as New
- Bookmark
- Highlight
- Email to a Friend
- Report Inappropriate Content
I could not agree more. This is one of the single biggest issues my company faces as we rollout Vault from Product Development to the rest of the company. Multiple engineers have brought up this issue independently in my company. To start our ECR process we change our state from "released" to inwork" which triggers a rev bump so we can make the proposed changes to the drawing. Then we initiate an ECR within our ERP system and attach a PDF of the proposed new Rev to this ECR to communicate the change. Our Engineering Changes often have to go clear to our end customer and rejections are not uncommon. What then? I have yet to figure out a work-around here...
Aside from rejected ECR's, even adminstrators can accidentally bump a rev sometimes.
- Mark as Read
- Mark as New
- Bookmark
- Highlight
- Email to a Friend
- Report Inappropriate Content
- Mark as Read
- Mark as New
- Bookmark
- Highlight
- Email to a Friend
- Report Inappropriate Content
Agree 100% We're moving more into actually USING lifecycles the way they were meant to be used... but along the line certain files have benn revised in Vault incorrectly. Roll back would be awesome as long as there was good security on it... Admin function only.
- Mark as Read
- Mark as New
- Bookmark
- Highlight
- Email to a Friend
- Report Inappropriate Content
Setting the revision to bump on the transition to "release" would be the proper methodology to protect against this. You would need the ECO workflow to be allowed to put a file back into "released" if it were rejected. Having to go through the workflow give accountability to the process by tracking those that make those mistakes and why they happen.
It makes more sense to me than discarding a revision, and if any downstream systems trigger off of a revision change, you wouldn't run into issues.
That brings on the issue of what to do with the versions that are numerically higher than the latest released revision, but business rules can work around this. "Any further modifications must start from the last released revision" could handle it. Or, the eco process that moves the LC back to "released" could discard later version.
- Mark as Read
- Mark as New
- Bookmark
- Highlight
- Email to a Friend
- Report Inappropriate Content

