Lifecycle changes without revisions, or versions should not result in locked working versions when managed state is reached by the revisioning workspace.

[jayna.vroman]

When an item goes through a lifecycle change driven by a revisioning workspace the working version of the item gets locked until the revisioning workspace record reaches the managed state. At that point, the affected item is released and if revision or version is checked in the lifecycle editor for the lifecycle transition chosen, the item is then released with an updated version and/or revision. However, there is a catch, if no revision or version is chosen for some reason; let's say it's for a lifecycle change where no revisioning or versioning is desired, the item's lifecycle state will update but the working version will remain locked. This causes the record to be forever stuck in this state unless the item is removed from the change order/revisioning workspace record manually and the 'Revert Changes' option is selected (note: this is currently only available in classic). This action would prevent good change documentation from occurring and cause an uptick in administrator duties. Why would anyone want that, right? 

In some cases, there is a need or desire to have an item move from Prototype to Engineering Release without a change in revision or version, because the only change to the item is its status. 

Currently, the lifecycle editor allows administrators to leave revision and version unchecked but then doesn’t support the records going forward. Why would Autodesk leave admins the option of not revising or revisioning if they won’t support it? This sounds like a bad design to me. Does anyone else find themselves in this situation? I have at least three customers who want/need this functionality without the lock state and manual 'revert changes' options. Just the simple ability to update only the lifecycle state. 

[cleyton.ribeiro]

we desperately need this option ... fails for me to understand why Autodesk doesn't allow this simple logic....

[dvirh]

Hi Jayna,

Are you saying that there are situations where the change order goes to the managed state but (some of) the affected items remain in a locked state? If so, that sounds like a bug to me and you should report it to customer support. It is important to report it to customer support so that they can help in reproducing the issue and identify any special circumstances in your tenant.

Regarding the specific need to allow changing the lifecycle state of an item "in place", meaning to change the lifecycle state without releasing a new revision of the item, the issue with that is that when you configure the BOM to a date in the past it may look like a particular item was already in, say, a Production state where the reality is that it was not. Maybe it is not a critical inconsistency (since there are other ways to ensure traceability). I'm interested to hear what others are thinking. 

[jayna.vroman]

We did submit a ticket for the issue. They say it works as designed. They told me that they would only change this if I could get enough support through the idea board. The case number I had for this is 18346286.

[dvirh]

Hi Jayna,

I met with Customer Support and we have confirmed that this is a bug. They will report it as such. That said, I would like to encourage you not to use the Revision In-Place method unless absolutely necessary. This is especially true when moving between lifecycle states. The main issue is that this method changes the history of the item without proper traceability in some cases. Imagine, for example, moving from Production to Obsolete without changing Revisions. This means that the item that was used to make parts no longer exists and any information on it may have been overwritten with data from the Obsoleted part. When you configure the BOM to a date in the past, it will now show the Obsoleted revision of the part rather than the revision that was used to make the item. 

I understand that some other systems allow for something that looks like this In Place transition, but I believe this is usually done with a different revision philosophy that lets each revision of the item go through all lifecycle states. In that case, you would want to create a new revision only when you start the revision process again, which will put the new revision in the start of the lifecycle map. This is not something that Fusion Manage supports and is very different from what Fusion Manage does. Happy to have a conversation about it if you'd like. Please reach out!