Understanding SOLIDWORKS PDM Workflows, Part 1: Workflow States

by Brian Dalton

What is a Workflow State?

After years of working with SOLIDWORKS PDM, I sometimes take it for granted that users naturally understand certain fundamental concepts that are an important part of the PDM paradigm.  One question that often catches me off guard is, “What is a Workflow State?”

While it seems a curious question, it makes perfect sense for someone who has not worked with PDM in the past.  Some obvious answers might be ‘A Workflow State is where a file stays while waiting for the next transition’, or ‘It’s that rectangular box in the workflow, connected by those lines with arrows,’ but those aren’t really useful replies.  What the user is actually asking is, “What is the purpose of a Workflow State, what does it mean for a file to be there and how would I know that it’s time to move it on to the next state?”  They want to have a fundamental understanding of how a Workflow State affects their work.

At its foundation, I think the best description of a Workflow State is this:

A Workflow State represents a period in time when a group of related tasks should be performed on the file.

This description tells us a few things about the state:

  • The state that a file is in tells you what work needs to be done on the file
  • The state suggests who should be working on it, based on the kind of work that needs to be done
  • The kind of work to be done suggests what access (permissions) are available
  • When the work appropriate for the state is finished, it’s time to move it on to the next state

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

What Do Workflow States Mean?

Typical states in a three-state revision loop

In Design

Tasks – Typical tasks to be performed in the In Design state might include:

  • Part and assembly modeling (designing)
  • Drawing creation (views, dimensions, etc)
  • Design analysis
  • Engineering peer review

Users – Users who might work on a file in this state could include:

  • Engineers
  • Designers
  • Drafters

Permissions – These users need access permissions such as:

  • Add or rename file
  • Check out file
  • Read contents
  • Show working versions

Under Review

Tasks – Tasks for this state would be related to whatever design review process your company uses

  • Management review
  • Design review meeting(s)
  • Analysis results reporting
  • Use case suitability analyses
  • Design Release decision

Users – Users involved in such a review could include

  • Engineering management
  • Engineering peers
  • Configuration management
  • Document Control / Quality Assurance
  • Manufacturing

Permissions – Typically all users would be limited to read only access for files that are undergoing review.  An exception is when certain reviewers are utilizing electronic redlining. In this case, those users also have Check out file permission.


Tasks – Tasks for this state would typically involve those required for documenting and publishing the released design

  • PDF creation
  • Notifying other departments
  • Exporting to MRP/PLM
    • Publishing for qualified vendors and suppliers

Users – Users involved in such tasks might include representatives of

  • Document Control
  • Configuration Management
  • Quality Assurance

Permissions – As officially approved and released files, there should be no access in this state beyond basic read only permission.

When you think of states as being connected to the logical sequence of tasks that are performed in the process of creating and releasing a design, it helps to clarify what states would be needed and/or beneficial, and what activities would occur in each state.  Based on that understanding, you can apply your company’s design policies to determine who should be involved in each state (set of tasks) and what level of permissions they require in order to fulfill their roles in the process.

What's on your mind?

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