What's that I hear you say? Vault revision tables? Great! Let's explore this shall we...
So I've done my research, I've looked at the 'blog' videos on the topic, I've spent hours and hours and hours trying to figure out a way to make it work, and hear is my conclusion.
It doesn't work.
In every which way you try to flex and bend the workflows, it does not work. There cannot be a company anywhere in the world that are using Vault revision tables with any sort of success.
Why?
Well let's explore that! Why would you want to use a Vault revision table? The answer is simple, to automatically populate a drawing revision table with values that you would otherwise need to type in manually before releasing a drawing. Correct? Which values are these? Typically, revision number, date, the change comments (reason for the revision), checker, approver, and who drawn it. Let's break that down, getting to the point of why this doesn't work.
1) Revision number. This works fine, when up-revving a drawing it will put a new row in the table with the latest Rev number. Yay, credit to the devlopers there.
2) Date. This is the only other table value that will actually work, sort of, using any number of checked in dates or date modified properties. Great success!
3) Change comment. This is where it starts to go wrong. Ideally, you'd want to map this from a change order raised when the drawing was up-revisioned. But no, not possible. For some reason Autodesk have blended the Title system property between Items and Change Orders making this extremely confusing, but either way it doesn't feed its way into the revision table anyway so it's a lost cause. Using the last 'version comment' property is also out the question, because the Job Server has to create a new version when updating the revision table rendering that comment on lifecycle change to Release null and void. There is no way to automatically populate this part of a revision table.
4) Checker. Autodesk don't understand this side of things. There is no functionality or scope for a checker to stamp his/her credentials against a drawing through automation. I'm logged into Vault, I've looked at the printed copy, I have the drawing on my screen in Vault Client, I want to stamp my initials into this drawing. No, you can't.
5) Approver. This is what really winds me up, and it's such a simple thing to get right. All that is expected is the person who makes the transition from WIP/Checking to Released to have his/her name fed into the revision table. It just cannot be done! There is a property called 'Initial Approver', that had me excited! So I released Rev 0 with 'Person A' and that name was put into the revision table!! Then I released Rev 1 with 'Person B', but it left 'Person A' in the new line for the Approved cell of the revision table!! FFS!!!!! What is the point of that property?? And for reasons stated earlier, I can't use the 'created by' property as that will be the account used by the job processor! The mind boggles that after 3 years of this being in the product, this simple aspect of drawing revision management is so incredibly useless and unusable.
6) Drawn by. Again, not possible. You could use the 'Author' property which is typically retained from day 1 rendering that property no good. I'm bored now, and in a rotten mood as I've wasted yet more days of my time trying to make something work that just never will work.
Autodesk, please... please please please just STOP IT. Stop bringing in useless garbage to the products that won't do a job properly. It's embarrassing for you. You should be ashamed that a product that claims to be 'best in class data management' can fail so badly at the fundamental basics of data management. Either get it right, and by that I mean make it simple and effective, not a maze or an endless chain of mapping unrelated properties from point A through to point Z, having to log into the job processor with an account that has to have modify rights on released data ffs what's that all about, do away with all that or do away with this sh*t that doesn't work.
I'm not sorry for the rant, I could make a post like this for 90% of what Vault does or doesn't do, I'm fed up it and it wasting my working day.
Hmmm so looks like I will be sticking with the old manual rev tables moving forward as I develop my lifecycle use.
In my simple view the whole process including state change permissions to a certain set of files should be driven by the ECO.
So regrettably without these style of controls in place a vast majority of my lifecycle flows will have manual aspects within them moving forward.
Vault revision table currently support only document life cycle. You can log a request in idea station or vote for some of the existing ones.
http://forums.autodesk.com/t5/vault-ideas/vault-revision-table-linked-to-item-revision/idi-p/3797421
http://forums.autodesk.com/t5/vault-ideas/revision-table-for-items/idi-p/3515786
We do not use items and I do not believe we will.
So I would like to see this behavior happen with file lifecycles.
I just typed out another massive rant and then the realisation set in that it just doesn't matter, it's been over 4 years since I made that original post and clearly it just doesn't matter.
To summarise how I feel about Vault right now, in its current state:
It's been in development and in use for 13 years, it should be much much better than this. It's problems keep me in a job but I can't do this for much longer, my entire career for 5 years now has been spent fighting against Vault inadequacies and defects, and there's no light at the end of the tunnel. If there are plans to put it into maintenance mode and replace it with something else, please do it quickly so I can begin planning my new career.
It's 2022 and I wonder how many of these got any traction in the last 10 years? I could go and check but lets see what an Autodesk rep has to say.
I am no Autodesk rep, but today (2022) revision tables is still a mess.
I just use a general table instead for manual input, after trying for months to configure it.
I map the Vault property revision for both drawings and models to an inventor iproperty, to get it displayed in my titleblock. The table above is pure manual work.
I wonder why did still doesn't work as excpected after all those years?
I have been through the wringer over this. I am about to ditch a well planned revision table. Either you end up with duplicated released versions ("properties applied by job processor") or you have to purchase an additional license for each approving authority to use the Job Processor, which is how Autodesk has designed the process. I agree with Autodesk that manually typing in approve values, etc. does not enlist confidence in document control, but the actual approver can check the manually entered fields for validity before release.
I think we will either move to manually added UDP fields for the revisions, capping these at 26 for the revision letters; or simple manual entries in attributed fields which is what we were already doing before getting excited about Vault automation. I just can't see past these problems without the job processor.
I never used this in production, but two years ago.... before the world went crazy, Mark Lancaster and I did a class at Autodesk University on this topic using AutoCAD and Inventor as examples. We did not use JP to demonstrate this, and it all seemed to work ok. Does anything in this class (video or handout) help?
Chris Benner
Industry Community Manager – Design & Manufacturing
If a response answers your question, please use ACCEPT SOLUTION to assist other users later.
Also be generous with Likes! Thank you and enjoy!
I dunno Chris. The first paragraph on Page 2 says "using the Job Processor".
@punisher
Point well taken, but in the live demonstration, I do not believe we had a runnin Job Server so we just manually pushed through the changes.
I will concede, however, that in large organizations, the JP would make this a whole lot easier. And if the JP is not getting the job done, that is a problem.
As I said, I never actually did this in production, we were so small we did everything the old fashioned way.
Chris Benner
Industry Community Manager – Design & Manufacturing
If a response answers your question, please use ACCEPT SOLUTION to assist other users later.
Also be generous with Likes! Thank you and enjoy!
Chris,
Thank you again for your support. The Job Processor is not the problem per se; I can get the revision table going, no problem, using the Job Processor procedure. However, we shouldn't need a background server (that requires an additional seat of Vault) to update a revision table. As someone mentioned previously, very often these changes are the draftsman's responsibility, and if these do not appear on the pre-released draft, no-one knows if the revision note will be the way the engineer / approver desires.
I finally got the no-Job-Processor method working after two changes:
1) toggled the update flag on for the 'update revision block on property sync' option (xml file), and
2) your suggestion of using the in-review state, instead of the released.
I know it shouldn't matter, but I could not get the sync working until I used In-Review state. I was skipping it, and had no luck. I only have one test this morning, but I'll give it some more work and try to prove this out.
A old thread but still worth keeping warm. Was it 2013 @Neil_Cross @Neil_Cross wrote this, and Autodesk has done nothing? How hard can it be? For every state change you could be given the option of pulling out the username and timestamp to a udp, or a standard prop. Without talking of Change orders. We live in 2022 and electronic signatures is a valid way of signing drawings. Put in also that user should type their password also before changing a state and it would meet req for electronic signatures. It could be an option when setting up lifecycles. And when changing states, why not update the properties momentarely and then lock the file.
I cannot make this work for my departement as it is and I guess im not alone. That as shame
We've dropped back to our manually revising the Vault Revision Table each time. It is unfortunate, but the only way to avoid the issues surrounding released files with misspelled Revision notes, etc. The Vault - Jobserver interaction for revision tables was far to cumbersome to include in a new implementation full of half-heated adoptees.
All would be fine if the principles were acting as Vault Document Managers, but they are not. They will sign files pre-release and leave it to everyone else to process and release after the fact.