Understanding SOLIDWORKS PDM Workflows, Part 2: Workflow Transitions

by Brian Dalton

What is a Workflow Transition?

In Part 1 of this series, we talked about the Workflow States a file can be in, what makes one state different from the next, what should happen while a file is in a particular state and who should be involved.  Let’s now explore the paths that take files from state to state, which are called Workflow Transitions.

While Workflow Transitions seem more straightforward than States, and it’s easier to grasp the meaning of moving a file through a transition from its current state to the next. There is a lot that can go on ‘behind the scenes’ when a file is passing through a Workflow Transition.  For the user, there is only one action involved – transitioning the file to the next state.  PDM, however, can be very busy with actions of its own that are triggered by the change of state.

First, let’s define a workflow transition, then talk about the various activities that may be associated with changing the state of a file.  At its foundation, I think the best description of a Workflow Transition is this:

A Workflow Transition represents the act of moving a file or files from one state or another and may include other related actions performed by the PDM system.

Here’s a list of actions that can be triggered by a Workflow Transition:

  • Changing the value of a data card variable
  • Capturing information about the transition itself (who did it, when it was done)
  • Changing the revision of the file
  • Publishing the file to an alternate format such as PDFaor STEP (PDM Pro only)
  • Exporting release information to PLM/MRP (PDM Pro only)
  • Sending a notification message
  • Executing an external program (PDM Pro only)

Let’s take a look at what this means in the context of a simple three-state revision loop:

What Do Workflow Transitions Mean?

Typical transitions in a three-state revision loop

Send to Review

Actions – Typical actions that might be performed during this transition include

  • Notifying Approvers or Managers that a file is waiting to be reviewed
  • Capturing the initials of the user and/or the date of the transition
  • Updating a watermark or other status identifier (change data card variable)

Users – Users who might perform this transition could include

  • Engineers
  • Designers
  • Drafters

Approve Release

Actions – Typical actions that might be performed during this transition include

  • Notifying appropriate staff that a file has been released
  • Capturing the initials of the approver and/or the date of the release
  • Updating a watermark or other status identifier (change data card variable)
  • Incrementing the file revision
  • Publishing the released file in an alternate format (PDF, etc.)
  • Exporting release information to PLM/MRP

Users – Users involved in such a review could include

  • Engineering Management
  • Configuration Management
  • Document Control / Quality Assurance

Return for Changes

Actions – Typical actions that might be performed during this transition include

  • Notifying the Designer or Engineer that further changes are needed
  • Updating a watermark or other status identifier (change data card variable)

Users – Users involved in such tasks might include representatives of

  • Engineering Management
  • Configuration Management
  • Document Control / Quality Assurance

Open for Revision

Actions – Typical actions that might be performed during this transition include

  • Notifying management that a file is undergoing revision
  • Updating a watermark or other status identifier (change data card variable)
  • Modifying the revision variable to indicate that the file is undergoing revision

Users – Users involved in such tasks might include representatives of

  • Engineers
  • Designers
  • Drafters
  • Engineering Management

As we discussed in Part 1, a Workflow Transition should be performed once all the tasks associated with the current state have been completed.  The transition itself can be configured to trigger a number of useful activities that will be carried out by the PDM system as the file moves to the next state.  Based on that understanding, you can apply your company’s design policies to determine who should be allowed to perform each transition and what system actions should occur as a result of the file’s state change.

This entry was posted in blog, CAD, Product Data Management and tagged , , on by .
Brian Dalton

About Brian Dalton

With more than two decades of experience in manufacturing related roles, Brian has been the person to turn to during technical projects. In addition, his experience includes effectively managing teams (onsite and offshore) and working on highly complex systems to ensure the best outcomes. In his recent role as a PDM Specialist at GoEngineer, he is able to leverage his technical skills on continuous improvement projects, ensuring companies have compliant, efficient systems.

What's on your mind?

Your email address will not be published. Required fields are marked *

If you want the title tag to say something different from the page heading, enter the custom title here

nineteen − nineteen =