Vault Revision Tables - Make it useful or ditch it

[Neil_Cross]

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.

[tahdesign1]

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.

• Admin develops and assigns an ECO for a requested change

• In the development of said ECO, users are defined that will do:
  • Modifier (Drawn By, etc)
    • This users ID populates the REV table being driven by the ECO for Drawn By
    • Can fill in the actual change description in the ECO that will populate the Rev table (could be different as the work progresses from what the author assigned in naming the ECO.
    • ECO assigns the right for this user to change state from released to wip for files that will be changed in the design attached to the ECO. It is often very difficult to understand all files that will be rev'd for a change and only the effected files should have to change state. Change of state should not be a globally open action for most users so that revs do not happen by mistake and roll backs are not necessary (or limited).
    • Can move ECO assigned files from wip to checking state
  •  Checker
    • This users ID populates the REV table being driven by the ECO for Checked By
    • Can move ECO assigned files from checking state back to wip for any redlines
    • Can move ECO assigned files checking state to approval state
  • Approver
    • This users ID populates the REV table being driven by the ECO for Approved by
    • Can move ECO assigned files from approval state back to checking or wip states for unapproved reasons
    • Can move ECO assigned files from approval state to released state

So regrettably without these style of controls in place a vast majority of my lifecycle flows will have manual aspects within them moving forward.

[junyi_zhu]

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

[tahdesign1]

We do not use items and I do not believe we will.

So I would like to see this behavior happen with file lifecycles.

[tschaeferZNBXX]

Why can you not use the person who moves a document from Released to WIP?

I find this very upsetting when I have been in several different data management systems that had this automated and very useful. There is no reason that my users should have to manually put in signatures into a drawing. This is a non-value added activity and pointless.

[tschaeferZNBXX]

Why vote them up? The first one you have here shows that it is from 2013! Seems that many of the features users request never get put in Autodesk software or are "add-ons" that cost more. Seems pointless to have a forum for us to suggest EXACTLY what the USERS of your software want IF YOU NEVER PUT THEM INTO THE SOFTWARE!

[Neil_Cross]

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.

[WG1987]

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.

[johan.degreef]

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?

[punisher]

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.

[CGBenner]

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?

[punisher]

I dunno Chris. The first paragraph on Page 2 says "using the Job Processor".

[CGBenner]

@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.

[punisher]

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.

[evenmartinsen]

Nd old thread but i @neil 

[evenmartinsen]

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

[punisher]

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.