Modifying/Correcting Revisions

[Anonymous]

We need a controlled, structured way to make changes to released revisions.  The primary use would be to make clarifications or administrative corrections on technical drawings that are attached to an item record.  Another use would be to make corrections on the Item Details tab in a locked section.

The primary requirement is to be able to open a particular version for editing via a workflow.  As far as I know the only solution today is to use the "Override revision control locks" permission which gives access to all records in a workspace and does not have a traceable workflow associated with it (the workflow might contain an approval or review step as well.)

I thought maybe creating a lifecycle transition that neither increments version nor revision might do it but no luck because that only opens up the working version for editing, not any of the released versions.

Thanks.

Joe Hendrickson

[Anonymous]

We need a controlled, structured way to make changes to released revisions.  The primary use would be to make clarifications or administrative corrections on technical drawings that are attached to an item record.  Another use would be to make corrections on the Item Details tab in a locked section.

The primary requirement is to be able to open a particular version for editing via a workflow.  As far as I know the only solution today is to use the "Override revision control locks" permission which gives access to all records in a workspace and does not have a traceable workflow associated with it (the workflow might contain an approval or review step as well.)

I thought maybe creating a lifecycle transition that neither increments version nor revision might do it but no luck because that only opens up the working version for editing, not any of the released versions.

Thanks.

Joe Hendrickson

[gasevsm]

Does this use case describe a form of quickchange - item gets released and want to make adjustments that don't change form/fit/function of last released item without re-revising it again. Could you create a process of employing another revisioning workspace alongside ECO (eg. QCO) and in the lifecycle map only make and enable a loop transition from Prod to Prod and increment version and revision. This way to make a quick change, the working version of a released item must be added to QCO, must be in prod lifecycle state and can only go to prod again. It would act on working obviously, but you will record that this wasn't an engineering change but a quick change-driven revision against the same item. Another approach is to employ a different revision-controlled workplace with own release process and in a released item's uncontrolled section add a pick list (with show latest revision option) reference to the quick change item. This allows tracking and linking of quick changes for any historical released revision of an item and no just latest released as the first option above. Thoughts?

[Anonymous]

It's important that the revision letter remains the same following the change since our suppliers probably already have the revision in their records.  Fit/form/function has not changed.  It's probably 90% important that we change our records, 70% important that suppliers do it - not important enough to require all of the administative activities that go along with a new revision.

The second suggestion is interesting and may work if there's no change to the present revisioning structure.  But it's certainly not as elegant as a system-based solution.  It would mean splitting our drawings from the primary item's record.  It's hard enough to get folks to understand the workspace/record/attachment/revisioning structure as it is.  I don't want to add another workspace to address what should be a minor activity.  There's a reason Quick Change was formally introduced to Vault, right?

Thanks for the suggestions.  Hopefully some other users will back me up that this is a worthwhile feature.

Joe Hendrickson

[gasevsm]

Point taken - they are weak approaches to implement quick change within revision. What you are looking for isn't possible natively unfortunately. Another idea to explore possibly is allowing manual rev bumping and repeat the rev letter for the Quick Change Order approach, while bumping rev for ECOs. Let me know what you think of this. It may result in multiple releases of same rev letter. Good luck Joe. I'll add this to my list of things to discuss with team. Regards.

[Anonymous]

Ah, manual rev bumping.  We were doing that for a while then finally got away from it recently.  I don't want to go back.  And multiple records with the same revision letter?  We have some of those too due to how we had lifecycles setup regarding obsolete items.  I don't want to see that again either.

Thanks for adding it to the list and offering some good suggestions.  We'll make due, it is certainly not all the time that this happens (I sure hope not!)

Joe Hendrickson

[benderk]

Hello -

Since this topic is over 6 months old, and we would like to review it in more detail internally in the context of Modern before potentially moving into a development backlog.

Thank you,

Keri Bender | Global GTM Business Strategy Manager, Product Lifecycle Management

[benderk]

Thank you for submitting your idea. Have you tried the Modern Interface lately? We request that you review your idea in the context of the Modern interface. If your idea is not addressed, we invite you to create a new Idea in the context of Modern so that it can be addressed accordingly. Sincerely, Keri Bender | Global GTM Business Strategy Manager, Product Lifecycle Management