PDM Professional - Assigning Users with Conditional Notifications

Overview

The first thing I will do is break down the task into smaller manageable portions of work that will address specific aspects of the change we are implementing.

• Step 1: Create variables and DataCard layout / logic to capture the required names*.


• Step 2: Create conditional notifications on transitions
  • Notify Checker
  • Notify Approver
  • Notify Author (if rejected / when approved after checking/approval)


• Step 3: Add workflow logic to ensure correct file routings with a single ‘Transition’ visible to user from work in progress called ‘Submit for Approval’ that is actually three transitions with…
  • Conditions to allow files
  • Conditions to reject files
  • Conditions to push through later automatic transitions


• Step 4: Add transition actions to record actual users and dates for approval actions.


• Step 5: Add transition actions to clear fields on revise.

*NOTE: To enable logic that allows us to bypass checking or approval we will add a user called 'Not Applicable' who can be selected from the list instead of a valid PDM user. As this aault uses PDM login’s this is quite easy to do (the user will be ‘blocked’ from logging in). If your vault uses Windows log-ins, then in order to add the ‘Not Applicable’ user you will need to re-configure your vault to also allow PDM Users. This can be done within the Archive Server Configuration Tool.

Step 1: DataCard Changes

For the demonstration I have added an additional approvals tab to the DataCard for models and drawings. To ensure that the full lifecycle details will be visible in one place, I have initially replicated the existing ‘Author’ and ‘Creation Date’ fields, making them read only and setting the same default values as main info tab.

Next, as my workflow has both a checking and an approval stage, I want to add a couple of drop lists to allow for the nominated users to be selected. You could manually create specific lists for your checkers and approvers (the entered name must exactly match) however I have just linked my controls to the standard “user list (full name)” lists. You will want to create a couple of variables to store these.

I also want this to be mandatory at check in so I will employ a little trick to validate. Validation is only available on edit boxes, so I have added two small edit-box’s next to the drop lists. These are read only and have an input formula driving them that reads the value selected from the associated drop list.

I have added a minimum of five characters validation rule, that means I get a warning if nothing is present in that box. To make it easier to understand the warning, I have made that variable name more descriptive too.

Finally, I added some read only edit boxes to display the names and dates captured during the transitions themselves.

Step 2: Conditional Notifications

Typically, a conditional notification is only sent when specific conditions are met. For example, if a certain variable has a specified value. In the case of our workflow we want the notification to always be sent, but the recipient to vary. To do this we add our conditional notification, but set the condition to always be true.

The easiest way to do this is using filepath + text compare and a value of %. The percent symbol is the wildcard equivalent in SQL Queries and used by PDM to essentially mean ‘any value’. So, in this case as a file will always have a path, the condition is always met.

Next, we define the recipient(s). To do this we will read the name from the drop list we created on the DataCard for this purpose. So, we use ‘Add Variable’ instead of 'Add Users/Hroup', and we select our required variable. In my case ‘List_Chk’

Repeat everywhere this is required to send a notification. In my case I also added a conditional notification to check the author and alert them when the file was rejected or finally approved in the process. This is a useful technique in a workflow with multiple approval steps where the ‘Notify Last State’ modifier is not appropriate and the file creator may not be the person who made the last changes.

Step 3: Workflow Logic

In my example I want to simplify the workflow process by routing the file(s) automatically through checking / approval only if required and without the user having to make those choices again (after setting the variables on the DataCard).

To do this I have renamed the three possible routings from ‘Work In Progress’ to all use the same text and set conditions based on the value of the checker and approver variables either being ‘Equal To’ or ‘Not Equal To’ 'Not Applicable' For example. In the transition to the checking state the condition would be that the value of checker is ‘Text Not Equal To’ 'Not Applicable'.

The routing that bypasses checking would use checker is ‘Text Equal To' 'Not Applicable' The routing that bypasses checking and approval would use both checker is ‘Text Equal To’ 'Not Applicable' and approver is ‘Text Equal To’ 'Not Applicable'

Finally, If the user selects a checker but 'Not Applicable' for an approver we need to automatically route from the pending approval state through to approved. This is done by adding a second ‘Approved’ transition, set to automatic, but with the condition that the approver variable is ‘Text Equal To’ 'Not Applicable'.

Step 4/5: Transition Actions

This step will just add additional actions (as required) on the transitions to capture / clear the user(s) and date(s) the transitions are executed.

When capturing the ‘Name’ you can chose from initials, user (log in name), full name or user data.

So, with everything configured, we can now see the process in action.

Written By: Wayne Marshall - Professional Services (PDM) Manager