Chaining approval processes

You can initiate a new approval process automatically when the first process is done. For example, if a manager approves a new computer purchase, the IT department can start another chained approval process that determines the exact model of computer to buy.

The Lunch Scheduler application demonstrates the technique of chaining three different approval processes together to approve Lunch Scheduler requests. The Lunch Scheduler application uses workflow to start the initial process and to automatically run the additional processes when necessary.

Related topic

Using-the-Lunch-Scheduler-sample-application

Using filters and a process status field

The main tasks implementing this workflow are to link the filters to the approval form with the appropriate Execute On conditions and to use a field to store the current process status on the request form. The workflow filters that start each chained process test the process status field with a Run If condition to determine whether the chained process should run.

In the Lunch Scheduler application, the filter that starts the initial process, Management Cost Authorization, is configured to run when the AP-Sample:Lunch Scheduler form is submitted or modified. Using the Submit condition assures that this process will run first. The chained processes, Major Account Level Approval and Special Overdue Approval, use filters that are configured to run only when the AP-Sample:Lunch Scheduler form is modified.

In the Lunch Scheduler application, a character field named Approval Workspace, ID 536870920, tracks the process status. The Approval Process Done rules for each process enter a string in this field to represent the current process status. The Run If conditions of the filters that start the Major Account Level Approval and Special Overdue Approval processes test this value to determine if the chained process should run.

The three processes in the sample Lunch Scheduler run in this order:

23_3_Lunch_Scheduler_Process_Stages.png

  1. The Management Cost Authorization process runs first because the filter is configured to run when the request is submitted.
    • In the Process Done stage of this process, the Approval Process Done rules populate the Approval Workspace field of the Lunch Scheduler request form.
      For example, if the request is approved, the Approval Process Done rule enters Cost-Approved in this field.
  2. Because the request form was modified, the filters for the two chained processes are run.
    • If the customer is a major or enterprise account, the filter's Run If condition causes the Major Account Level Approval process to run.
    • When the Major Account Level Approval process is done, its Approval Process Done rules modify the Approval Workspace field to indicate the process result.
      For example, if the request is approved, the Approval Process Done rule enters Level-Approved in this field.
    • If the customer is not a major or enterprise account, the Major Account Level Approval process does not run.
    • If the account is not overdue, the Special Overdue Approval process does not run. If the account is overdue, this process runs only after the Approval Workspace field has been set to Level-Approved.
  3. If the Major Account Level Approval process runs, its Approval Process Done rules again modify the request form. This action causes the filters for the two chained processes to start again. In this case:
    • If the Level process is completed with approval, and the request is marked to indicate that the account is overdue, the filter's Run If condition causes the Special Overdue Approval process to run.
    • If the Level process is completed with any other result, such as rejection, or if the request does not indicate that the account is overdue, the Special Overdue Approval process does not run, and the overall approval process is complete. 

These three steps explain how the three processes are chained together to create the overall approval process in the Lunch Scheduler application.
In addition to the filters that start the three processes, a fourth filter, AP-Sample:Test Level Approval, runs whenever the approval request is modified. This filter runs only after the Approval Workspace field is marked Cost-Approved, and if the Account Type is not major or enterprise. The filter performs a set fields action that sets Level-Approved in the Approval Workspace field. This action assures that the Approval Process Done rules function the same, even though the Level process did not actually run.

Restarting an approval process

Occasionally, after an approval process has been started, it becomes inappropriate to proceed. You can configure your approval process to restart in such a situation. For example, in the Lunch Scheduler application, a request automatically restarts if anyone changes the restaurant, the company, or the number of attendees. This process ensures that users cannot make a change after the request has been approved.

The sample application implements this functionality by using a set of filters that watch for a change to the Company, Number of Attendees, and Average Cost/Person fields when the form is modified. If a change occurs, a filter sets the Approval Workspace field to contain a cancellation string. Another filter resets the status of the request to Pending Approval in this case. If the requester cancels the request by another means, such as by modifying the Approval Status field, the request does not restart because in that case the Approval Workspace field has not been set.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*