In this guide, you'll learn the steps and procedures required to design and implement a full Revision Table on the face of a SOLIDWORKS PDM data card that updates rows as part of the workflow as well as the Revision Table found on the face of the drawing.
With a typical example of Revision Table integration with SOLIDWORKS PDM, only the most recent row is still editable and in sync with the drawing file. We have now added additional rows that showcase and store previous row values as read-only—similar to how the table might work on the face of the drawing itself.
Related >> Creating a SOLIDWORKS PDM Revision Table
Here’s how to add a Revision Table to a SOLIDWORKS Drawing and save it as a template and sheet format for standardized use. Additionally, this has to be an actual Revision Table feature as seen below.
This process will not work with PDM if our revision table is just a bunch of drawn-in sketch rectangles or a generic table feature.
In a Drawing, use Insert >Tables > Revision Table.
Once you have the revision table in place, decide what columns are needed in advance and how they should be filled out (either by default when a new row is generated or manually by the user).
For this example, I want a new empty row to be generated whenever a drawing is sent back to WIP in order to start a new release. The only value that I want prepopulated is the Revision column, which showcases the next revision/release the user will be working toward. See an example below.
Once you’ve finalized the design of how the revision table ought to look on the drawing, use the Insert new row option to create the first empty row and make sure to use your initial revision value. This way, when a new user uses this file template to generate a new drawing, they will not have to insert and appropriately format the table themselves and it will be immediately interactive with the drawing data card.
Then, go ahead and save this drawing as a Template using Save As > SOLIDWORKS Drawing Template (.drwdot).
Save the sheet format using File > Save as Sheet Format (.slddrt) in their desired respective locations. And, if desired, right-click on the table and select Save As > Revision Table Template (.revtblt.).
While the default admin account is what is being used to create these configuration changes, (it is unlikely that anyone outside of an admin role/permission would be reading this anyway), you need at minimum these Administrative and Folder permissions as seen below to implement the changes detailed in this guide.
As mentioned previously, SOLIDWORKS and PDM 2018 or newer is required for this feature to work as that was when Revision Table Integration was first introduced. This feature, once enabled, allows only the most recent row of the Revision Table on a drawing to be filled out using the SOLIDWORKS data card and vice versa. Additionally, it also allows PDM to generate new rows on the revision table when triggered by a workflow action.
To turn this feature on, go to Administration >Your PDM Server Name > Your Vault Name > Login with admin/equivalent credentials. Start by going to and expanding the SOLIDWORKS node.
Then open the Revision Table feature and select Enable Revision Table Feature.
Here is where we decide the maximum number of visible rows before we will allow in the drawing before older rows get deleted. For this example, I will use four rows with a placeholder value of * as I use a simple Numeric scheme for the revisions.
We have to decide the number of rows here because that is how many “rows” will be emulated in the card itself.
Now to get to the variable and data card setup. It’s generally considered best practice to create your variables ahead of time rather than as you are designing your data card on the fly. This is mostly because this method saves on a lot of clicking later in the Card Editor.
In the Admin Tool > Variables > Right-Click > Open.
The first few variables are the most important, as they carry the SWRevTable mapping that allows them to interact/populate the latest row of the Revision Table of the drawing itself.
For example, for the Revision column I will make a dedicated variable RTRevision with the sole mapping of SWRevTable to Revision for the file extension “.slddrw” and repeat the process for each of my other columns of Description, Approved, and Date.
To speed up this process, just use the dropdown menu to select the appropriate SWRevTable block menu and Attribute name. See as shown below.
Note: While it is possible to embed the SWRevTable mapping into other variables with other mappings, it’s far easier to leave them as completely separate variables. The reason for this is that we do not want any write to a variable to change an existing field in the revision table or unintentionally create a new row.
To emulate the presence of the other “rows” we will simply need to create similarly named but sequentially enumerated variables with no mapping. This way, the older “rows and fields” will be visible on the data card—however, they won’t have any mapping functionality to their corresponding rows on the face of the drawing.
Going over to the data card itself, we need to create an appropriate control for each field in the table. Here I will add a couple of edit-boxes for Revision and Description, a date field for the Date, and an edit-box for the Approver’s initials.
For flags, my intent is that Revision, Date, and Approved, are controlled by PDM, so I will set each control appropriately as read-only.
As for the subsequent rows, I will copy and paste them like so and align them to look nice.
One quick note is that the description for all the “old” rows should also be set to read-only—recall that these aren’t actually connected to anything on the face of the old drawing anymore. Otherwise, a user could accidentally “desync” the data card and the drawing.
This is where things get a little tedious and tricky. First, consider when the creation of new rows in the table should take place. In this case, it occurs during the transition “New Release” where an existing release is moved back into WIP in order to begin working on a new revision of my file.
To review what has happened to the revision table on the file in other portions of the workflow up to this point in the Production Release State:
Moving forward to the New Release transition. The best way to visualize the transition actions needed is to see them happening all at once in the correct order. See the picture shown below.
Breaking the steps down further:
Not shown here, all other Transition Actions as desired
Note: These actions are still happening for the first three revisions of a file even when a new Revision Table is growing to its full length, but since they are writing nothing to nothing, it does not matter.
It’s important to do the “rows” in this order as we want to make sure the second oldest row (Row 3) gets a chance to offload its information before it gets overwritten with the information from Row 2.
Taking a closer look at one of the actions, they are simple variable write actions that take the existing column value of Row 3 and then copies it into the following Row 4.
To create this action of copying the Revision of Row 3 down into Row 4:
The same will be done for all other fields in all other rows. As for the final cluster of actions, we’ll treat this as a typical set of actions that generate a new empty Row.
Note: By default, when the SOLIDWORKS Revision Table feature is triggered to make a new revision row, it will also tend to populate the Date field with the current date as defined by one’s local computer time which may not be desirable. To avoid this, the variable write action is blank to purposely empty that field.
Now with all the pieces in place, we can see the end result and it works! Instead of just a single row, the data card now reflects the previous revision table information as well. And, much like any other PDM revision table integration, the most current row interacts with the Revision Table on the drawing itself.
If multiple revision cycles need this similar behavior in other transitions, then copying and pasting the transition and renaming it is perfectly valid. What matters most is that the order of actions is correct, otherwise, some rows might become duplicated or emptied improperly.
As mentioned previously, the other “rows” are read-only not because we don’t want users editing past values, but more because they don’t do anything—there’s no interaction between older “rows” and the drawing itself.
Additionally, scaling this to more rows is incredibly tedious, as there’s no way to copy and paste individual actions within a transition or between transitions in a workflow. Only entire transitions can be copied and pasted within a workflow.
Lastly, this feature still does not fix the biggest weakness of revision table integration—deviation from the workflow for the creation and deletion of new or past rows. If you accidentally make a new row, there’s no back button. If you delete a row manually, it’s gone forever. As far as PDM is concerned, the best way to maintain table functionality in the case of an accidental row is to do a rollback.
About Miguel de Villa
Miguel de Villa is a SOLIDWORKS Elite Applications Engineer with a B.S. in Mechanical Engineering from the University of California, San Diego. He’s been working at GoEngineer since 2017 helping customers with all their SOLIDWORKS, Simulation and PDM needs. In his free time he enjoys working with his 3D printer, playing video games and building model kits.
Get the latest articles delivered daily to your inbox, unsubscribe at any time.