Rollback in SOLIDWORKS PDM 2017: What You Need to Know

SOLIDWORKS PDM 2017 introduced some new functionality to the rollback feature, allowing users to rollback their files with references. Before 2017, Rollback was a very simple feature, where users could take a single file and roll it back to a previous version while permanently deleting the versions after it. The process could only destroy the data associated with a single file and the wizard for completing it was simple as a result:

If a file was rolled back unintentionally or too far, the effected file could be recovered from a proper backup (if one was taken since the files last changes), or the changes to that one file could be recreated.

In 2017, the ability to rollback with references has given users much more power, and in turn, much more responsibility. The first thing you might notice is that the wizard has expanded considerably:

Now you have the ability to not just rollback a single file, but permanently destroy all versions of all referenced files that were created after the rollback setpoint of the parent file. This can be a real timesaver when you need to send everything back in time for a project, but can also be quite detrimental if not used properly.

Throughout most of 2017, the process for completing the rollback is about the same as 2016. Once the user chooses the files they would like to rollback in the wizard, they are given a short warning message about they versions being permanently deleted, and then the files are gone forever. A user could potentially delete tens, hundreds, or even thousands of file versions by mistake if they are moving too fast, not properly trained in the product, or not aware of the repercussions.

With the release of service pack 5 of 2017, SOLIDWORKS decided to add some additional warnings to the process, explicitly calling out the number of files being rolled back and forcing the users to acknowledge the action with an additional check box.

Even with the additional feedback, rollback is still a permission that is best reserved for administrative users. It has the capability of doing just as much, if not more damage than the destroy permission if put into the wrong hands (even if its name is far less scary). Properly training users on this functionality, mindfully setting permissions, and using a “roll forward” approach when applicable (saving an older file version to the end of the history) are great ways to prevent a small mistake from turning into a large loss of data.

Hannah Harmon

Application Support Engineer