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.

[olearya]

Hi Neil,

Thanks for your feedback.  I guess the key functionality requests you would like to make are:

1. Properties from the change order available in the revision table such as the change description, checker and approver

2. I believe you would also like the "approver" and "checker" linked to the user who carries out the document lifecycle state change from WIP to released or In Review to Released

I am not sure what you would link the "drawn by" user to - this could be "last modified by" but I am not sure that is accurate in all situations and I don't think you could link it to lifecycle changes - perhaps a "responsible engineer" value could be used from the ECO but there can often be more than 1.  This may be something that stays manual.

Is there anything I am missing?

The Initial approver value was introduced primarily for use in the title block where users were looking to retain the initial values.  Its deliberately designed not to vary as changes are made to the document.

[Neil_Cross]

Allan,

I've spent the last 6 months endlessly filing product support issues to Autodesk, filing feature requests that rarely are acted upon (transparent watermark on an item to name one of many), finding bugs, I've spent £30,000+ getting the Vault customised so hard so that it can actually be useful to a certain degree, I spent 6 hours last Friday trying to check an assembly into the Vault due to the 'needs a save' problems in this release, I've lost countless working days trying to get the Inventor 2013 material library to work, I receive 10-15 emails per day from my users who experience crashes and need me to help them out, I spent last Wednesday with Chris Mitchell (Autodesk) showing him all the problems we're having, I feel like I do nothing else at the moment except fight with the Autodesk products, calming down raging end users, defending Autodesk, then having to tell them where they're going wrong.

So, with the greatest respect, and I do now apologise for my less than civil tone, but I shouldn't have to explain that on an automated revision table I expect the option of having the user who physically releases the drawing (final approver) to have his name in the revision table etc, everything I detailed in my post is common sense and blatant obvious basic practice of technical drawings.

As always I greatly appreciate the time you take to respond, but I'm seriously phyiscally exhausted from dedicating hours every day trying to butcher a system into working the way the real world works and finding it doesn't!

[xavier_dumont1]

And another bad behavior of those revision table (need a quick fix about that,I have already open a support request on that).

I you have an existing revision table in your drawing and you want to use the Vault revision table, it's just impossible. Why? Because Vault just clean all row that are not linked with a revision in the Vault... My problem? Importing existing revised data into a new Vault => just impossible. The solution? We have to develop our own application to manage revision table with simple table in Inventor...

Hope Autodesk will improve this quickly.

[hans.martin.haga]

6) Use "Designed by" instead.

http://forums.autodesk.com/t5/Autodesk-Vault/Design-by-created-by-overwritten-by-Job-Processor-on-re...

[Neil_Cross]

Thanks, but unless the entire table can be automated then it's not really going to work.  You mentioned in that post that manual process is not an option, so how are you handling the approved & checked by cells in a revision table? And the change comments/rev description?

[mbodnar]

Hi Neil

I agree that the rev table integration needs some improvements to make it 100% usable and here are some ways I have personally tried to achieve this but still not there entirely. From the clients feedback so far it's not very suitable to how most fill out rev table values.

I use completely separate custom properties for the rev table like rev_description, rev_approver, etc. Rev no is the only one that I use as default

The checker/approver would use edit properties in vault to enter their initials. The issue with this is the info does not show in the rev table once the dwf has been updated thru the JP unless the state you are moving to has been configured as a released state. I tried to make 2 states as released but apparently not allowed to do that. Values for one state will appear (for review) but not for the the other state ( released). The designer usually fills in values while working in inventor but these values get blanked out temporarily by the JP

JP being reliable and error free is another topic all together and it doesn't help with the automation of the rev table. It's usage of an additional license is another.

Hope this helps in some way

Max Bodnar

[cbenner]

I've also had some limited success in playing with the Vault Rev table by setting it up with all custom properties (except rev).  Biggest complain so far (besides the afore mentioned inability to truly link this with an ECO) is the fact that once you activate the VRT, any previous revision tables on older legacy drawings, get wiped clean when you open them from the Vault to even look at them.

Another one:  I understand that  VRT is only supposed to show released revisions in Vault.  This just doesn't work.  I finish work on a drawing, add the VRT, check it in and set the state to released.... in my new DWF in Vault... the VRT has blank fields.  The only wat for it to show up is to set to Quick Change, reopen the drawing in Inventor to get the VRT to update,... save, check in and close.  Not a good work flow.

Last but not least.... the VRT does not seem to work whatsoever with AutoCad drawings... at least not that I've been able to see.

This was an exciting innovation,... but it just doesn't get it done.  And I really wanted to like it.

[yingkit(Autodesk)]

Hi Neil,

Let me lay down some rules about Vault Revision Table (VRT) first so as to ensure our understanding is in sync:

1. For every revision, only information from the FIRST released version of the file will be used to populate the revision table
   By “released”, it refers to any state which is marked “This is a released state” in your lifecycle definition and the FIRST released version is the version of the file whereby it first gets into a state marked “This is a released state”. In other words, if your “For Review” state is marked as a released state, VRT will be using the information from the version of the file whose state first gets changed to “For Review”.
2. Each revision level, primary, secondary or tertiary, is considered as a distinct revision

Another point I’d like to highlight is that VRT works best when used together with Job Processor.

In the below section, I will try to answer and suggests alternate solutions to your issues but you’ll soon realize through my reply there’s something missing, I am definitely not getting the entire picture of your lifecycle settings and process flow, resulting in some of the scenarios not fully understood by me, or maybe your company had put in place some customization which I’m not aware of? It’d be good if you could explain a bit more about your lifecycle settings and process. And if you have any customization, do highlight as well as that may have an impact on VRT.

Now to your questions:

1. Change Comment
• First of all, VRT is not set up to work with Item or Change Order yet. This is the current functionality and we are well aware of this limitation. This request is definitely in our consideration list.
• As for the part on Job Server creating a new version and rendering the lifecycle change to Release null and void, I am unable to figure out how this could have happen. As mentioned in rule #1 above, VRT will only be using the information from the FIRST released version to populate the revision table and therefore regardless how many subsequent versions are created by Job Processor, VRT will still be using the very same information from the FIRST released version to populate the revision table, so I can’t figure out any way whereby information in the versions created by the Job Processor can get into the revision table, unless of course it is the Job Processor or a person logged in using the Job Processor credentials who created the FIRST released version.
2. Checker
• Currently there’s no means for VRT to automatically determine who is the checker. But even so, there must still be some manual indication from user that the drawing is checked and by who. For this, a simple solution is to create a UDP, say “Checker” and map it to the Checker column in your revision table. In this manner, the person who checks the drawing simply edit the value of the “Checker” property to his name, initials… once he checked the drawing.
• One will not see this value being recorded into the revision table at this point, esp. so for the Approver who may want to see the “Checker” field in the revision table being populated before proceeding to approve the drawing. He will have to check this value via the “Checker” UDP in Vault Client. But once the drawing is released, this information will surely be captured into the revision table since the FIRST released version will contain this value.
3. Approver
• Our out-of-the-box suggestion is to map the “Created By” system property to map to the Approver column in the revision table. In this manner, whoever release the drawing will have his name stamped into the “Created By” property and VRT will always be showing this value in the revision table since this is the value of “Created By” for the FIRST released version, which is in-line with your workflow of “the person who makes the transition from WIP/Checking to Released to have his/her name fed into the revision table”.
• Otherwise, you can again consider the option above for “Checker” whereby you create your own UDP, map it to Approver in your revision table, enter the correct value into this UDP prior to releasing the drawing and then release the drawing.
4. Drawn By
• Pretty much similar to “Checker” but your idea of mapping it to “Author” sounds good to me, why is it not working out for you? As long as the value of “Author” is updated to the correct value prior to being released, this value should eventually get into the revision table once the drawing is released.

Last but not least, for VRT to work nicely, Job Processor MUST be turned on because VRT relies heavily on Job Processor doing all the background work once a drawing gets released.

I understand that you have been talking to Chris Mitchell on this and I will try to get further information from him. But if you do have quick answers to some of my questions, I can see if we can work this out further over here.

Thanks! 

--

Kit

[Neil_Cross]

Kit - thanks very much for the response, I always greatly appreciate the time you guys take to communicate with the punters.

Ok, I was wrong on the approver.  If using the 'Created By' system property, the user account name does correctly find its way into the VRT and I was convinced it would be the JP account.  So I was wrong there.  But the theme of my original post is still very valid, the VRT is not usable.  This is like building a car with amazingly shiny sexy perfectly round stunning alloy wheels, but no engine, seats or a steering wheel.  Allow me to explain.

1) The Change Comment/Description is still a manual input, this is one of the most important areas of the VRT.  Whilst manually inputting this, you might as well manually input the rest of it.

2) The checker is just as important as the approver in most cases, whilst manually inputting this you might as well manually input the rest.  I have previously explored the idea of having a checker manually edit the properties to put his initials in, but they then remained there for the next revision.  There probably is a way to have this only apply to the current revision but I haven't really looked into it, I don't like the idea of having a checker edit the properties.  Call me greedy or unrealistic, but Vault manages technical drawings and change control, there should be a more robust 'professional' workflow for this basic aspect of drawing control.  Plus, this is creating new version after version after version in the Vault, simply going from WIP > Released is already creating several file versions without any checking out at all.

3) The 'Drawn By' field is definately difficult to manage, because the person checking in the drawing isn't necessarily the person who created the drawing or made the revision edits. 

But don't you agree.  Does it need to be this complicated? Creating the VRT in the settings, defining the column headers there, then having to go to Inventor and creating the rev table again and having to manually type in the column headers again to match? Mapping to properties that don't really correspond to what you think they mean.  Having a 'checked by' property in Vault that doesn't actually serve a purpose.  It's all a bit disfunctional.  I haven't even attemted to get this working in AutoCAD yet.

Oh, I thought I'd leave it until now to mention that we have Windows Authentication enabled. So that renders everything above pointless, because Vault maps the user account login name to the VRT (I believe I asked 2 years ago to introduce an account 'alias name' but I'll not dwell on that).  So, this is what I see in the approver field:

HiWeHaveVeryVeryLongDomainNameBecauseWhoThoughtItWouldEverEverEVERneedToBeStampedIntoAflippingDrawingForGodsSakeAsIfAnyoneWouldHaveExpectedThat\\NEIL.CROSS

What's that? You have approvers called Ganesan Palanivelu, Tonia Charalambous, Davud Hamoodizadeh, how are they going to have their names slotted into a tiny VRT cell? I'd need a full A0 page dedicated to who signed the bleeding thing off! I believe Autodesk have an employee named Madhanagopal Thiruvenkatachalam, I bet he feels my pain 😉

That what Autodesk giveth with one hand they burgle and beat with the other.  

[yingkit(Autodesk)]

Hi Neil,

Thanks for your reply, I've captured most of your needs and will be sending them to the Product team.

--

Kit

PS: Not sure if Madhan is feeling the pain yet, but he should be sneezing away 🙂

[olearya]

Rest assured we have them - and a few more...

[tmoney2007]

I don't understand how vault wouldn't know who to put in as the approver.  It is related to the login, and stored in the audit trail.  Also, having someone manually input their initials isn't very well validated.

Tieing it to the vault user account or active directory gives you traceability for WHO checked it.  Typing in initials does not.

[yingkit(Autodesk)]

Our out-of-the-box suggestion is to map the Approver to the "Created By" system property and VRT will automatically pick up the username of the user who FIRST change the state of the drawing to a "released" state and fill in the revision table accordingly.

Unfortunately, some usernames are too long and not suitable to be used in the revision table, hence the request for initials.

Other issues relate to the respective processes of each company and using the information from the "FIRST released version" is not a solution which fits all situations... therefore as Allan mentioned, we have collected all these issues here, plus a few more, and we need to look at all these requests as a whole to determine the best solution.

Thanks

--

Kit

[yingkit(Autodesk)]

Hi cbenner,

You seem to have some issues using VRT with AutoCAD? I wonder if you could provide some further information to see if I can help you out.

Here's what I'd like to request for:

1. A screen capture of your Vault Revision Table settings
2. In AutoCAD, after inputing the command 'vltrevblock', what is returned?
3. Has the drawing gone through any "released" state yet?
4. Please also attached a sample drawing with a revision table added

Thanks

--

Kit

[Mpendlebury]

If it does work, then its way to hard to be useful.  and I'm in the camp that it doesnt work. i totally agree with all the rants i have herd so far.

The most frustrating part of it is i can see most of the fieds i want automaticly populated into rev table and title block in the vault, i cant get them in and if i can its in the wrong format.

It would make sense that when checking in a drawing or revising a drawing that i asked you for the feilds you needed to fill in to make it complient.  

The process seems overly complicated too. even the simplest of tasks. Example finish work in autocad. Check in to revise. Now, you must save it before revising, (i am aware of the ignore view only changes) but if its checked in its read only.. so you cant.  If the drawing is checked in your not trying to edit it so why must it require a save?  so then you jump onto your vault client and hit revise it there, now the drawing you had open is makred out of date, now you cant check it out with out closing it and opening it again, or you get a "file is a historical version of the drawing"

Vault is extremly underwhelming for the price, so much stuff seems so buggy, i could whine for hours. 

Vault 2013

Civil3d 2013

Windows 7 x64

Intel Xeon X6575

24 Gig Ram

[Maxim-CADman77]

I wonder when we all finally could try the improvements declared in "Revision Table Improvements" section on page http://wikihelp.autodesk.com/Vault/enu/Help/Help/0000-What_s_N0. Afaik no downloads available on subscriptions yet?

[subsales]

We are finalizing some issues with the Vault Basic postings in subscription site, it should be available shortly.

--

Kit

[mgeurts]

Any improvements in higher version already?

[rainer.proehl]

Old post, but I cannot find any improvements in Version 2017?

Any news to the Revision table functionality?

Cheers

Rainer