Skip to main content
SolidWorksSolidWorks Enterprise PDM

Advanced Data Cards: Part 1

By September 12, 2016July 10th, 2023No Comments

Advanced Data Cards Part 1: Dynamically Configurable, Restricted and Required Input

What is it?

There are multiple inputs or fields on a data card that may be valid but depending on some condition or a specific situation, certain fields are not valid and should not be allowed to be editable.

How can these concepts be implemented?

There are two obvious choices that we need to make.  How will we lock down or make the fields non-editable and also how will we allow the input to be captured only when we want it and not when we don’t.  There are almost always multiple ways to accomplish the goal so we need to choose the best one for us given our specific circumstances.

Choosing how to lock down fields

There are many approaches that combine concepts but they really all revolve around two core functionalities:

  • Tabs controlled by variables
  • Control Logic
  • Read-only flag

Tabs controlled by variables – There are two different ways a controlled by variable tab control could be used.  The first is to show completely different values on each tab where activating a different tab will hide fields.  With this method you’re locking down the field by not allowing it to be seen.  This can be useful in some scenarios but can be confusing if you don’t know what’s going to happen.  The content changes quickly and if you blink you won’t notice what changed.  The other way to use a tab control is to use it to allow input and will be covered in the next section.

Control Logic – Using control logic has the advantage of putting all the logic for an individual control in one place but has the disadvantage that every Control must be controlled individually and that that you can’t apply logic to multiple controls at once so it’s a pain to implement.  There are two things that can be done to alleviate the pain to implement slightly.  The first is to create the control logic for one control first and copy and paste it.  Of course you’ll have to change the control properties but sometimes that’s easier than changing the control logic so in this case you may need to choose from the lesser of evils.  The second is to put multiple controls on a tab control and use the control logic on the tab.  One trick with this is that if you don’t want to see the tab control just choose a since tab and set it to be controlled by a variable.  It doesn’t matter which variable because if there’s only one tab it will always show the contents but never the tab itself.

Tip for using Control Logic:

When using control logic against a variable that’s controlled by a checkbox it’s fine if you need to say “equal to 1” but don’t ever say “equal to 0”.  Always say “not equal to 1” because that way if the checkbox is unspecified or unchecked it’s still handled correctly.

Read-only flag – The read-only flag is an absolute.  It can be used but the flag itself can never be changed by the user.  The fields marked as read-only can only be changed by the methods listed under choosing when and how to allow input.

Choosing when and how to allow input

The ability to set or change a variables value that are read-only on a data card can be done in one of these ways:

  • Tab Control
  • PDM Template
  • File Attributes (Custom Properties in a SOLIDWORKS file)
  • Workflow Transition Action – Set Variable

Tab Control – To use this method you should copy and paste the exact same controls to two different tabs then on one of the tabs mark all the controls with the read-only flag.  Many times this is used with a user name or group name as the controlling variable but don’t limit yourself to this mindset only.  This technique can be very useful when controlled by other variables too.  This is the only method that can be used to allow users to input field values directly on the data card by checking out the file and editing it.

PDM Template – To use this method you would create a Template for creating a new file of the type you want in the PDM Administration.  There you can create a template card where the variable is editable even though when the values in the template are pushed into the file the file’s card is read-only.  This method is ideal if the value needs to be set on file creation but can’t help you if the file already exists.

File Attributes – To use this method simply set the file attribute you desire in your template.  This requires that the file has attributes that are understood by PDM (like SolidWorks Custom Properties) and is also only useful if the file is being initially created.  Using this method after initial creation encourages users to circumvent PDM data card logic altogether and although is technically possible it is highly discouraged.  This could be used effectively in the Part/Assembly details example for setting the Part/Assembly Variable since it could easily be set in the Part and assembly template and would never need to be changed after that.

How to Require input

Requiring input to be typed manually is not usually recommended because inevitably you will get bad input and as a general rule no input is better than garbage input.  Requiring input can be effective when the input can be picked and not typed because that forces valid input.

The ways to require input are:

  • Mandatory Variable
  • Textbox Min Length
  • Workflow Transition Condition

Mandatory Variable – This is pretty straight forward if the variable flag is checked you may not save the data card values unless the field controlling the variable has a value.

Textbox Min Length – This is almost the same as Mandatory variable but has the advantage that every file in your vault doesn’t need to have a value in order to implement it because it’s card specific and doesn’t apply to the whole vault.  The down side is that it only works for textboxes but there’s an easy workaround.  Add whatever type of control you want and then add a textbox with the same variable and flag the textbox as read only.  This way the textbox will require the min length but only the other control will be able to edit the value.  The textbox can then be made super tiny or moved to an area where it won’t be seen.  Collapsing the width only seems to work best for making the textbox invisible but it will need to be re-collapsed every time you edit the card.

Workflow Transition Condition – Using transition conditions can be very useful but users need to understand conditions because PDM has a limitation that it can’t show any meaningful information as to which condition is blocking the transition or why.  It will only say “Conditions for transition were not met”.  (If everyone who reads this would submit this as an enhancement request maybe we could get that changed)

Usage Example 1: Part/Assembly details

Purchased Part or Assembly
  • RestrictedMaterial
  • RestrictedFinish
  • RequiredVendor
  • RequiredVendor Part Number
Manufactured Part
  • RequiredMaterial
  • OptionalFinish
  • RestrictedVendor
  • RestrictedVendor Part Number
Manufactured Assembly
  • RestrictedMaterial
  • RestrictedFinish
  • RestrictedVendor
  • RestrictedVendor Part Number

The goal is to control the variables as detailed by the bullet point listed above.  Again there are many variations on how this could be done.  This is only one possibility.

Set control logic for Material and Finish as seen in this image:

Set control logic for Vendor and VendorPart as seen in this image:

The Or in this case isn’t required but is added just in case there are more conditions in the future.

The variable behind the Part and Assembly radio buttons is named FileType.  Set the read-only flag on both radio buttons to true (checked).  Then, in the part and assembly template files add a custom property named FileType and set it to the respective value.  Once that is done set the variable attributes in PDM like this image:

With this done the file will now only enable the fields if they are valid for input.  The Purchased checkbox can be controlled by the user whenever the file is checked out.  As a final step we could require input by using transition conditions but in a scenario like this that usually isn’t required even though the initial request asked for it.  It’s more important to disallow bad input.  It would be ok if there was a way to display a message other than “Conditions for transition were not met” but with that limitation it would likely be very confusing if implemented.

Usage Example 2: Document Signoff and/or notifications

Imagine there are 7 departments that may need to sign off on ECOs

  • Engineering
  • Management
  • Marketing
  • Operations
  • Purchasing
  • Quality
  • Sales

When the engineers fill out the ECO it’s their job to decide who needs to sign off on the changes.  Admittedly having the engineers decide what sign-offs are required isn’t the most bulletproof but for this simple scenario let’s not consider that and just look at how we could implement this requirement.


First we build a card that looks something like the picture below where all fields that you can see are read-only, all the checkboxes and all the textboxes.  The only fields that are not read only are the checkboxes on the Engineers tab.  They’re a copy of the exact same checkboxes in the exact same location but with the read-only flag unchecked.  The tab control is then set so that it is controlled by a variable and the chosen variable is “”.  This assumes that all the engineers are in a group named “Engineers”.

You’ll notice right away that it doesn’t appear like the checkboxes line up with their respective Name and date fields.  This is ok, although annoying, because when the tab control is controlled by a variable the tab portion of it is collapsed and it moves up.  The following picture illustrates what this would look like to the user who is an engineer (the checkboxes are editable).

The next step is to create the workflow.  Don’t get scared at first glance, it may look like a circuit board, you don’t’ need a degree in electrical engineering to understand it.

All of the transitions that are named the same have the same respective condition logic they’re just unique with respect to the field they’re checking.

All the transitions named “Sign Off – …” that end it a department name have this condition logic:

If the department signoff required checkbox is checked AND the department signoff date is equal to “” then it sets the variable for sign off by and sign off date and moves to the next state named Approval Logic where automatic transition will check if all the signoffs are complete.

They also need to have their permission set so that only people from the department that they name have permission to execute the transition.

All the transitions named complete have the same respective condition logic:

If the department signoff required checkbox is checked AND the department signoff date is not equal to “” then it’s complete and should advance to the next state.

All the transitions named Skipped also have the same respective logic:

If the department signoff required checkbox is not checked then it’s skipped and should advance to the next state.

Finally, all the transitions named Incomplete have the same respective logic also:

If the department signoff required checkbox is checked AND the department signoff date is equal to “” then it’s incomplete and should go back to the ECO Pending Approval state.

All the transitions named Complete, Incomplete, Skipped and the one transition named Sign Off Complete are automatic transitions and should be permissible to all users because no user will ever manually execute them.  They need to flow freely no matter who started the process.  All restrictive permissions need to be set on the non-automatic transitions.

This example not only allows you to have a simultaneous approval process but it also allows you to dynamically set what approvals are required at design time.

We hope you found instruction this helpful.  If you have any further questions, feel free to shoot us a note and someone will get right back to you.

Close Menu