SOLIDWORKS PDM Full Revision Table in Drawing Data Cards

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

Prerequisites

•  A SOLIDWORKS Drawing/Drawing Template that uses a Revision Table
• SOLIDWORKS PDM 2018 or newer
• A PDM File data card that is enabled for the .sldrw extension
• User rights to edit, save and create PDM data cards, Variables, and Workflows
• A workflow with, at minimum, two states and transitions between said states

Creating a Drawing Template

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.

  Watch >> SOLIDWORKS PDM – Custom Column in Rev Table

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.).

Necessary SOLIDWORKS PDM Permissions

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.

Administrative Permissions

• Can update variables

Folder Permissions

• Can update the design of cards

Turning on Revision Table Integration in the Admin Tool

 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.

Creating the Variables and Controls in the Data card

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.

Creating the Workflow Transition Actions

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:

1. Revision contains the revision value most recently released.
2. Description has been manually filled out by the user while previously in the WIP state.
3. Date contains the day the drawing was released and was automatically stamped by the Approved for Release transition.
4. Approved contains the approver’s initials which were automatically stamped by the Approved for Release transition.

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:

• Copy existing Row 3 to Row 4
  • Write contents of variable RTRevision3 to RTRevision4
  • Write contents of variable RTDescription3 to RTDescription4
  • Write contents of variable RTDate3 to RTDate4
  • Write contents of variable RTApproved3 to RTApproved4
• Copy existing 2 to Row 3
  • Write contents of variable RTRevision2 to RTRevision3
  • Write contents of variable RTDescription2 to RTDescription3
  • Write contents of variable RTDate2 to RTDate3
  • Write contents of variable RTApproved2 to RTApproved3 
• Copy existing 1 to Row 2
  •  Write contents of variable RTRevision to RTRevision2
  • Write contents of variable RTDescription to RTDescription2
  • Write contents of variable RTDate to RTDate2
  • Write contents of variable RTApproved to RTApproved2 
• Make a new empty row
  • Write next Revision to RTRevision
  • Clear RTDedcription by writing a blank value
  • Clear RTDate by writing a blank value
  • Clear RTApproved by writing a blank value

Not shown here, all other Transition Actions as desired

1. Print to PDF
2. Write watermark to drawing
3. etc.

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:

1. Set Type of Action to Set Variable
2. Select the variable of the field of the row we are writing to (i.e. the row beneath the one we are shifting down)
3. Use the arrow option in the Value field to open a list of system variables to choose from
4. Select the Variables option for a list of user-defined variables to choose from
5. Select the corresponding variable of the field that is “shifting down”

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.

Conclusion

 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.

Limitations and Considerations

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.

Related SOLIDWORKS PDM Tutorials

How to Update Templates in SOLIDWORKS 

How to Adjust Templates Settings in SOLIDWORKS

Allowing SOLIDWORKS PDM Users to Update Version History Comments

Controlling Access to Versions and Revisions in SOLIDWORKS PDM

Using PDM Templates Inside SOLIDWORKS