Workflow Steps Example

The following is a detailed example of workflow steps. It illustrates how the workflow due date and the due date for assignments for each step are calculated using the Default Due Date and the Days Allotted defined for the workflow type. The example contains rejections and delegates to explain a large number of scenarios.

This example is based on the default workflow type Initial Work Authorization which contains the following steps:

For the selected project and control account, the user fields above contain the following users:

• PCA — Evelyn

• CAM — Jack

• IPT Lead — Ed

• PM — Rick

• Evelyn’s Delegate — Adele

All due dates are calculated by adding a number of days to today’s date. The number of days is calculated by taking the duration plus the number of non-working days and holidays.

Use the calendar below for this workflow example.

When a workflow is created, the default due date of the workflow is calculated using the Default Due Date (Number of Days After Workflow Creation Date) setting on the Workflow Type Configuration General tab. The workflow due date is calculated by adding this value to today’s date plus any non-working days and holidays. The Initial Work Authorization has a Default Due Date of 20 days.

When the workflow steps are started, the due date for each assignment in each step is calculated using the value in the Days Allotted for the current step. The assignment due date is calculated by adding the days allotted to the day the step starts plus any non-working days and holidays. Each assignment is given its own due date to help ensure all steps can be completed before the workflow due date.

The workflow due date is beyond the sum of the days allotted. This is a helpful practice to ensure that the assignees in the last steps have time to complete their assignments before the workflow due date.

The non-working days and holidays are defined in Administration » System Calendar. In this example, the company working days for March are Monday through Friday and there is a holiday on March 16th.

Workflow Creation

Evelyn, the PCA, creates the workflow on March 1, 2012. When it is created, she checks the due date calculated and determines April 2, 2012, is correct.

The due date is calculated by counting 20 working days from the April 1. The system calendar indicates working days do not include weekends nor March 16th, which is listed as a holiday.

Evelyn doesn’t start the workflow steps on March 1st. She saves and closes the workflow. On March 5th, she opens the workflow, reviews the information, and clicks Start Workflow.

The due date didn’t change when she started the workflow. She could have changed the date any time before clicking Start Workflow.

Step 1

Clicking Start Workflow initiates a sequence of events. An assignment record is created for each person assigned to the step. The Workflow  Steps tab for this workflow type in Workflow Type Configuration indicates a Mapped User Field labeled CAM. User Field Mapping indicates the actual field is the Manager field on the control account table with the user ID of the person assigned to the workflow. Using the selected project and control account on the Initial Work Authorization, the CAM is determined to be Jack. The assignment record is updated with Jack’s ID as well as the assignment due date, the date the assignment was created, and so on.

The assignment due date was calculated using this formula: step 1 has 5 days of allotted time. The step start date is March 5th. Adding 5 working days to March 5th is March 12th (there are no holidays).

The workflow action on step 1 that occurs at step start is the Notification to the assignee. PM Compass sends Jack an email and a dashpart alert stating he has an assignment that is due Monday March 12th.

The Description in the Action grid on the Workflow Steps tab indicates when the action will be performed.

Jack is reading his email and he sees and email sent by PM Compass notifying him that he has an assignment. He clicks on the hyperlink and the Initial Work Authorization displays. Jack starts to document the statement of work for the control account and saves, but he does not approve the workflow. Instead, he closes the dialog box.

Three calendar days later on Monday the 8th, Jack gets a notification reminding him that he needs to approve the Initial Work Authorization. He clicks the hyperlink in the reminder email and make more edits, but he does not approve the workflow. There’s one more thing he wants to get confirmed before approval.

Reoccurring notifications such as reminders occur as indicated regardless of weekends or holidays.

Three calendar days later on Sunday the 11th, a reminder notification is sent to Jack. On Monday morning March 12th, Jack see the reminder notice, completes the statement of work and approves the workflow.

The 12th was Jack’s assignment due date. He didn’t get a Past Due notice because the workflow was completed on the due date.

The Completed Step Status for all steps in this workflow type is Approved. Each person who approves a workflow has their name display in the Approval grid on the workflow Progress tab. The Approval grid also displays in reports.

Step 2

When the assignee of step 1 approves the workflow, the workflow steps indicate that the PCA is assigned the next step. In User-Defined Data, in Area = Projects, there is a custom user field with the label PCA. In the Projects Form View on the Code Assignments tab, for the project selected in the Initial Work Authorization, Evelyn’s user ID is assigned. The workflow creates an assignment for Evelyn and performs the actions that occur at step start.

On March 12th, Evelyn, the PCA, receives a notification to approve the Initial Work Authorization. The due date for the PCA’s assignment is: March 12 + 4 working days = March 19th.

The assignment due date was calculated using the four days allotted for step 2 + 4 days.  Since the 4th day is a holiday and then the weekend, the next working day is Monday March 19th.

Evelyn is taking advantage of the Friday holiday and getting a long vacation (the week of the 19th through the 23rd). Evelyn has not approved the workflow when she leaves the office on Thursday the 15th. Evelyn also forgot to delegate her assignments when she left the office. She receives reminder notifications on the 15th and Sunday 18th.

On Sunday evening Evelyn remembers she needs to delegate her assignments while on vacation. She access PM Compass from her laptop at a local wi-fi hotspot. She selects User Preference and indicates delegating her assignments to Adele, but she doesn’t look at the alerts in her dashboard.

Evelyn was not delegating assignments when the reminder notices were sent, so Adele has not been notified via email or dashpart alert. If Adele were to access Workflows and select the My Assignments quick filter, she would see Evelyn’s assignment.

On the 20th, both Evelyn and Adele get past due notifications for the approval of the Work Authorization.

The assignment of step 2 was due on the 19th and is now past due. The Initial Work Authorization due date is March 30th.

Adele accesses PM Compass and looks at her assignments. She notices the workflow action is Approve for the workflow; however, she is concerned about approving such a large work authorization. She decides to close the workflow without approving it and wait for Evelyn to return.

Step 2 has a workflow action of Management Escalation to occur every three days past the assignment due date. Since no one has taken action, Evelyn’s manager receives notification on the 22nd. The email states that Evelyn has not completed an assignment for a work authorization that is not due until March 30th; so, he does nothing.

Both Evelyn and Adele continue to get reminders notices on the 21 and 24.

Reminder notices are sent every three days the assignment is open.  Past due and management escalation’s are sent only once.  

Finally on the 26th, Evelyn returns to her office.  

Step 3

The Assigned To column for step 3 in the workflow indicates two users. The PM is a custom user field on the project that is viewed from the same location as the PCA. The IPT Lead is stored in a code on the WBS code file in Cobra. The Mapped User Fields indicate the control account field and code value where the user ID is stored. Using the project and control account identified on the workflow, PM Compass created assignments for both Ed, the IPT Lead, and Rick, the PM.

Who Must Approve for the step is set to All, meaning that both Ed and Rick are required to approve the workflow to complete the step.

The allotted days for this step is 5. However, 26 + 5 working days is now April 1st. Since the Initial Work Authorization is due March 30, the due date on Ed and Rick’s notification is March 30th.

The due date is checked before creating the assignment due date and the earlier of the two dates is used.

Rick accesses PM Compass daily to check progress on the project and so on. He sees a dashpart alert notifying him of his assignment and rejects the workflow on the 26th. In the rejection comment, he notes that there is no documentation on the technical requirements requested by the customer.

When Rick rejects the workflow, the action Rejection Notice sends Ed a notification letting him know the workflow has been rejected and it includes Rick’s comments.

Step 2 repeats because of the Rejected action. The Rejection Action on step 3 indicates to Restart Prior step. When Rick clicked Reject, PM Compass updates the status to step 2 and creates an assignment for Evelyn.

Evelyn, the PCA, receives notification that the workflow was rejected. The step start date is March 26th plus the four days allotted for this step gives her notification a due date of March 30th.

The assignment due date calculation is always based on the step start date plus the days allotted for the step regardless of the number of subsequent steps.

Rick’s comments of why the workflow was rejected are listed in the email, in the dialog box displayed when clicking the dashalert, in the Past Assignments grid, and in the History grid.

Evelyn reads why the PM rejected it. She contacts Jack to obtain details on how to clarify the SOW and makes the edits herself. She could have rejected the SOW and had Jack make the change; however, since the workflow is close to its due date, she chooses to call the CAM and make the edits herself.

Evelyn can edit the Statement of Work because the In-Progress Step Status of her step is In Review. If this had been In Approval, the workflow would be read-only for her and she would have to reject the workflow so Jack could make the edits.

Evelyn makes the edits and approves the Initial Work Authorization. It is still March 26th.

Evelyn checks the Progress tab to see who is assigned to the workflow for this final step. She sees the Approval grid already has Jack and Evelyn listed. In the Assignment grid, she can see that Ed and Rick are assigned for the current step.

Step 4

When Evelyn approves the workflow, notifications are sent to Rick and Ed.

Scheduled Alerts, such as reminders and past due notices, occur at a set time. By default, that time is 3:00am. User-initiated alerts, such as notifications and rejection notifications, occur when the action is performed.

Rick and Ed receive notification that they need to approve the Initial Work Authorization. The step start date is March 26th. When we add the five working days allotted for this step, it puts the due date at April 2nd; however, due to the workflow due date of March 30, Rick and Ed’s assignments are due on March 30th.

The next morning Rick reads and approves the workflow after confirming the statement of work has been updated to his satisfaction. Ed waits to see if Rick is going to approve the workflow. On March 29th, Ed receives a reminder notice. He realizes the due date is tomorrow, so he reads the statement of work and approves the workflow.

The workflow includes a Publish action that occurs at step end. When Ed approves, the step ends and the Publish action indicates the status changes to Published. Using a filter on a workflow dashpart of published is an easy way to display important workflows such as work authorization or approved change requests.

The workflow includes an Update Source action that also occurs at step end. When Ed approves, the statement of work on the control account is updated. At this time, Evelyn can access Cobra and see the statement of work as a note on the control account.

You can manually create a User Initiated Alert for Area = Initial Work Authorization to send a notification to the Cobra user when the status becomes published so that they know the statement of work in Cobra is updated.

Checking the Workflow History

Open the work authorization from the document management area to see the following approvals:

• Jack, the CAM, approved on March 12

• Evelyn, the PCA, approved on March 26

• Rick, the PM, approved on March 27

• Ed, the IPT Lead, approved on March 29

The Assignment grid is empty by default; however, when you click Show Past Assignments, it displays a list that shows when the workflow was rejected and comments entered for each step.

If you click the History button, you see which person moved the workflow to each step. In this example, the only difference between past assignments and the history is the record indicating when Rick approved the workflow. When Rick approved, the status didn’t change, so no entry was added to the history.

Learn more about...