Value of Overwrite Latest Version within workflow

[Brian-M]

Does anyone use Overwrite Latest Version for certain transitions in their workflows? It's a checkbox on transitions "Overwrite Latest Version (Files only)".

I'm just catching up my thinking on this, not something I've really used, but I guess there are cases where it is safe and saves on number of versions...

Would transferring to a different workflow be one of the safe uses? If you go from CADworkflow to OtherWorkflow, then to get back you'd just transition back, you wouldn't need to pull up an old version, and promote that by checking it in (or doing a rollback). Maybe moving to an Obsolete state is okay too?

It adds a line to History "Checked in with version overwrite." Transition from Released to WIP seems like a bad place to use this option.

On the other hand, I haven't seen that versions really take up much extra storage space.

I generally don't give users permission for the more manual Overwrite Latest Version On Check-in. That can overwrite design changes, vs using it in the workflow only overwrites metadata changes.

Thanks for thoughts.

[matt]

I used to use this switch for situation where I had to make a correction that didn't qualify as a revision, like a spelling error, or something along those lines. It was not something I left on.

[AlexB]

I would say leave this for administrators. If you're only updating metadata in the PDM database, then it will be able to see that the file hasn't actually changed and just reference the same file for the new version. See below for Version 6 & 7. Version 6 is referenced by version 7 because it hasn't physically changed. Different "versions" of the same file.

Even if you're updating custom properties in the file with the workflow, I'm not sure whether I would overwrite the version with that either but it does create a new archive file with each version.

[bnemec]

Most of the transitions in our workflow set variables so they make new versions. Since we already have enough trouble with referencing the correct version we didn't want transitions creating new versions. At the beginning none of the transitions were set to overwrite latest version and nearly immediately everything was constantly referencing old versions of everything. Now the only transitions that doesn't overwrite latest version are the ones out of Released state.

For clarity, users do not have permission to check in with overwrite, but your question was specific to workflow transitions.

[the_h4mmer]

Most of the transitions in our workflow set variables so they make new versions. Since we already have enough trouble with referencing the correct version we didn't want transitions creating new versions. At the beginning none of the transitions were set to overwrite latest version and nearly immediately everything was constantly referencing old versions of everything. Now the only transitions that doesn't overwrite latest version are the ones out of Released state.

For clarity, users do not have permission to check in with overwrite, but your question was specific to workflow transitions.

I too found this out and started doing version overwrites for transitions between states up to a milestone (approved for prototyping) or release. Another way to possibly side step this issue (I believe but have not yet tested) is to use the parallel transition. I'm working on setting up a new workflow where the final step from "Design Finalization" to Production Release is performed using a parallel transition, configured to require one member from a set of groups to approve the design release. This way, there are working versions for all changes up to this point, but during the final review, there will only be one version change and workflow transition.

Another possible way to side step this is to have an automatic workflow transition between your review/release stages that had an auto update/rebuild task with version overwrite (since the variables will iterate the version in the previous transition), but you'd have to pipe in the ordering to ensure that lowest level parts were updated/rebuilt first and work your way up. Instead of doing this, I've told everyone that the review/release process MUST be a bottom up process, which will force the assemblies to reference the released versions of parts (and help Purchasing start their work sooner).

[jcapriotti]

I use it for some files as they move from "Approved" to "Release". We set a few variables in that transition and some are mapped to SolidWorks, this is to avoid another version of the SolidWorks file in the file archive as we already have a lot of files and space is limited.

[bnemec]

We are evaluating if we want to use it in the process of updating where used files to pull new revision(version) of revised components. Most of the revisions we perform do not propagate all the way up the where used tree/shrub. Before PDM the parent files would just be opened and updated to pull the new revision (revision in the file name before PDM) then saved and closed. No need to update the print because the change was not significant at that level or above. Now in PDM most of those parent files are released so an everyday process that was straight forward before PDM is now nearly impossible.

We're not going to grant permission to overwrite version to users, but perhaps some API can get it done. Thing is I don't know if I want to overwrite the version and loose that data. It would be just assembly files and with version reference data stored in PDM It's pretty much just mates and configs or display data. I checked and the file in the archive is over written, the model data is really gone.

If we don't use overwrite latest version in the little API tool (probably in the form of a user initiated and guided SW add-in) then it will need to recurse up the where used tree/bush. I've don't a little bit of study on that and I'm fairly certain there would be collisions if we allowed more than one user to run it at a time. So either need to identify and handle the collision or have some kind of token so only one user can run that add-in at a time. This option of updating to latest version all the way up the tree will also take much more time. Time that would likely be non-value added.

[Brian-M]

Most of the revisions we perform do not propagate all the way up the where used tree/shrub. Before PDM the parent files would just be opened and updated. . . No need to update the print because the change was not significant at that level or above. Now in PDM most of those parent files are released so an everyday process that was straight forward before PDM is now nearly impossible.

This option of updating to latest version all the way up the tree will also take much more time. Time that would likely be non-value added.

The last sentence ("not value added") is the one that stands out to me. Yes, using PDM with released files is different than what came before.
What's the value of this whole endeavor? You're talking about changes that don't affect the drawing.

Better to train people to do things like Get Latest (or enforce it for some users with settings).

All businesses are different, you may well have some motivation I've not encountered. It may also depend how you treat part numbering and interchangeability...
It's more clear-cut and easier for me to understand if you follow the best practice: If you change a design and the new one can't be used in the original assembly - you need a new part number.
You revise a component, you don't need to do anything to the assembly above that, because the assembly is still using the same component, the same way.
...But even if you don't follow that, the revision probably propagated up just as high as it needed to. Don't worry about the stuff above that point.

(If you break assembly mates, then you probably already have a way to loop the assembly out and fix it. )

But using API to update and overwrite makes me shudder. Next time someone opens the assembly, SolidWorks will put together the updated assembly (if they Get Latest). Even if they don't get latest... once you move it back to an Edit state, and check-it out, PDM will want to Get Latest.

[the_h4mmer]

It's more clear-cut and easier for me to understand if you follow the best practice: If you change a design and the new one can't be used in the original assembly - you need a new part number.

I was going to say the same thing, and would argue this is THE most important aspect to keep in mind.

You revise a component, you don't need to do anything to the assembly above that, because the assembly is still using the same component, the same way.
...But even if you don't follow that, the revision probably propagated up just as high as it needed to. Don't worry about the stuff above that point.

Personally I'd be wary of this depending on version referencing that is used. Where I'm at, we want to ensure everyone is always referencing the latest version of anything, so if you didn't propagate the changes all the way up the chain, there's no way to be certain. I know that this is time intensive to get a vault into this state, but once you get it there, it's quick/easy to tell what's out-of-date and what's not, otherwise someone individually has to have that knowledge.

(If you break assembly mates, then you probably already have a way to loop the assembly out and fix it. )

If I understand what's being stated here (forgive my ignorance), I'd suspect that you'd be experiencing an issue with how significant the change is and would more likely need a new part number. I know there's some funkiness with how SWX treats Feature IDs that could be an insignificant design change that could break mates, but I thinking of the 90% side of things.

Thing is I don't know if I want to overwrite the version and loose that data. It would be just assembly files and with version reference data stored in PDM It's pretty much just mates and configs or display data.

If changes are as insignificant as you say, then what's to lose? If you're only using version overwrite for transitions, then you'll have the version that was last transitioned without overwrite (like you said Released > WIP) then the updated check-in, where the design/document level changes occur. The version overwrite between workflow states (in my use case) is to ensure the part version referenced by the parent assembly, stays the same thru the review process, that way nothing needs to be updated at the end. If the top-level assembly isn't getting updated anyway, then it won't matter and version iteration can stay enabled.

[bnemec]

I was going to say the same thing, and would argue this is THE most important aspect to keep in mind.



Personally I'd be wary of this depending on version referencing that is used. Where I'm at, we want to ensure everyone is always referencing the latest version of anything, so if you didn't propagate the changes all the way up the chain, there's no way to be certain. I know that this is time intensive to get a vault into this state, but once you get it there, it's quick/easy to tell what's out-of-date and what's not, otherwise someone individually has to have that knowledge.



If I understand what's being stated here (forgive my ignorance), I'd suspect that you'd be experiencing an issue with how significant the change is and would more likely need a new part number. I know there's some funkiness with how SWX treats Feature IDs that could be an insignificant design change that could break mates, but I thinking of the 90% side of things.



If changes are as insignificant as you say, then what's to lose? If you're only using version overwrite for transitions, then you'll have the version that was last transitioned without overwrite (like you said Released > WIP) then the updated check-in, where the design/document level changes occur. The version overwrite between workflow states (in my use case) is to ensure the part version referenced by the parent assembly, stays the same thru the review process, that way nothing needs to be updated at the end. If the top-level assembly isn't getting updated anyway, then it won't matter and version iteration can stay enabled.

I'm afraid I took this thread off Brian's original topic of when/why use Overwrite Latest Version. I should have kept it more to the point that we are considering it as one option to help with automating the where used update actions.

However, we do appreciate the extra minds and discussion on our practice that seems to be somewhat uncommon. It's too easy to get stuck in a "well this is the way we have to do it" instead of asking myself, "But what if it wasn't..." So rather than further high jacking Brian's thread, I'll link over to a thread that I started a while back where we hammer on this version topic.
https://www.cadforum.net/viewtopic.php?t=103

Edit: if Brian is cool with expanding on this here I'm happy to continue the conversation here.