Seeking Approval - Part 3 : Manual Approvals and Approval Coordinator

[russ_sarbora]

I've used the the phrase "Approval activities" frequently in this Seeking Approval series. If you open the Workflow Editor and load a workflow that uses a Task table as its current record, you will see seven activities listed in the Approvals category. But when I say "Approval activities", I'm really talking about only four of those: Approval - User, Approval - Group, Manual Approvals, and Approval Coordinator. While the other activities in that category (Generate, Rollback To, and Approval Action) are definitely approval-related, they aren't the focus of what we've been talking about. Seeking Approval has been about a basic two job concept:

Job 1) create one or more approvals (records in an approval table)

Job 2) aggregate the resolved (approved or rejected) approvals into a final approve/reject decision.

In Part 1 and Part 2, we took a look at how that concept plays out with the Approval - User and Approval - Group activities. So let's wrap this up by looking at Manual Approvals and Approval Coordinator.

The Manual Approvals activity

In the case of the Manual Approvals activity, the logical flow of the approvals process still follows our fundamental approval concept: Some approval records are created, the workflow waits for those approvals to be resolved, and then makes a final approve/reject decision. However, Manual Approvals doesn't do job 1. It's like the Pointy-Haired Boss from Dilbert, it skips immediately to making a snap decision without doing any of the actual work.

Just kidding, Manual Approvals actually fills a nice niche in the Approval activity universe. It gives you the same capability final approve/reject decision logic that you get from Approval - User and Approval - Group, but it uses approval records added to the system manually via the SNC user interface. This can be a very handy way to deal wth edge cases or really complex approval scenarios where automating the approval creation isn't really justified.

Manual Approvals will auto-approve, just like the Approval - User, and Approval - Group. If there are no Approvals waiting when the workflow transitions into the Manual Approvals activity, it will keep on trucking right out the "Approved" transition and onto the next activity. That's important to keep in mind when designing the workflow. If the flow is starting on a record insert, there needs to be some activity that will cause the workflow to wait long enough for people to create the required approvals. This may be a task that's assigned to someone (Create Task) or a period of time (Timer).

There's not a whole lot more to say about Manual Approvals. We'll see an example of using it later, but first let's talk about Approval Coordinator.

Approval Coordinator - One Activity to Rule them all

Approval Coordinator, get this..coordinates other approval activities. Wow, I should write dictionary entries for a living. A more helpful definition would be that its a container activity that wraps around one or more of the other Approval activities. It has the same two jobs as the other three Approval activities*:

1) create one or more approvals (records in an approval table)

2) aggregate the resolved (approved or rejected) approvals into a final approve/reject decision.

* I promise this is the last time I will write out the two jobs. The point of all the repetition is too hammer home the idea that the four workflow approval activities all work on the same basic concept, and also to help people understand where to look when troubleshooting problems.

If the Manual Approvals activity is like Dilbert's Pointy-Haired Boss, then Approval Coordinator is more like the boss you've always wanted. It delegates to its child activities, trusting them to do their two jobs and make their own Approve/Reject decisions. Then it bases its final Approve/Reject decision on what its child activities have decided.   Just like the other Approval activities, the logic for that final decision is configurable. The end result is that Approval Coordinator lets you mix and match Approval - User, Approval - Group, and Manual Approvals together into a single aggregate Approval activity. Each child activity of the Approval Coordinator works independently of its siblings, with its own Approve/Reject logic and its own set of approvers. That makes it a great tool for situations where you have different sub-approvals that all need to be taken into account for an overall approval.

Now let's take a look at it in action. Before we start, you'll need to setup the right environment. Either read the Workflow Setup Note from Part 1, or download and install the attached Update Set.

Here's our made-up scenario for this example. Our WFApprovalTest table represents work that will be done on our company's systems (ie, a Task). The Assigned To will be the person on the hook for coordinating the work, so we want them to have an approval on the Task. This work will be performed by the Database, Network, and Hardware groups, so we want them have an approval. And once in a while, an executive gets it in his head that he should have an opinion about these tasks, so we need to be able to give them approval rights as well.

Open the Seeking Approval - Part 3 workflow in the Workflow Editor. It looks like this:

We have a single Approval Coordinator that contains 3 child activities, an Approval - User, an Approval - Group, and a Manual Approvals.   The Approval - User activity provides the approval for the Assigned To user. Its configured the same as the example from the Part 1 article.

The Approval - Group activity is providing approvals to the members of the Database, Network, and Hardware groups. Every member of a group gets a vote, and the activity is configured so that if any member of the group votes to approve, that group approves. We're also requiring all groups to approve in order to get an overall Approval from this activity. This is the same setup as the Part 2 article.

We haven't seen the Manual Approvals activity previously. Its giving us the ability to add ad-hoc approvals for our busy-body executive. Configuring it is very simple. It has the same Wait For and When Anyone Rejects fields that we've seen on the other Approval activities, but none of the fields related to creating Approvals. That makes sense, because it doesn't create Approvals,   you have to add those manually.

If you open up the Approval Coordinator config, it will look very similar to Manual Approvals. You get Wait For and When a Rejection Occurs options, with no approval creation options. Again, that make sense, Approval Coordinator doesn't create any approvals of its own, it bases its decision on what it's children decide.

To run this flow, add a new WFApprovalTest record. Make sure you set an Assigned To user. The insert of the record will launch our workflow. I added a "Workflow Context" UI action to the WFApprovalsTest form that will link you directly to the workflow context. Open it up and click the Show Workflow link to open the context diagram. You should see something like this:

This is showing that the Approval Coordinator is waiting on its children, and the Approval - Group and Approval - User children are waiting on their Approvals to be resolved. Notice that Manual Approvals is not waiting. It found no manually created Approval records attached to this WFApprovalTest, so it has auto-approved.

Leave that tab open and go back to the tab with the WFApprovalTest record you created. There are 2 related lists on it. Approvers and Group Approvals. We walked through those in the Part 2 article. This time, the Approvers list contains entries for every member of our 3 approval groups PLUS our Assigned To user.

Now, pretend you're the nosey executive and add an approval for yourself. Click the Edit button on the Approvers list. You'll get a slushbucket control that you can use to add yourself to the Approver's list. Then click Save to return to the WFApprovalTest form. You will now appear in the Approver's list, but your Approval record will be in state "Not Requested". Remember, there's no workflow activity controlling this approval, you'll have to change it to state "Requested" yourself. Then go back to the tab that has workflow context diagram in it and refresh it. The Manual Approvals activity will be green also this time, it has recognized your manual approval, and is now waiting on that to be resolved.

You can go back and forth between the WFApprovalTest record and the context diagram experimenting with approving different Approvals and seeing how it affects the Coordinator and its children. Basically, the coordinator is patiently waiting for its children to make up their minds about their Approve/Reject decision. Once they've all decided, it will AND those decisions together (because we configured it with Wait For=All child activities to Approve) and Approve/Reject appropriately.

The End

We've now covered all four Approval activities, so it looks like this really is the end of Seeking Approval. However, all of our simple scenarios so far have been based on people approving our requests. I don't know about you, but my life doesn't work that way. Like a pimply-faced 13 year old, we need to learn to gracefully handle rejection. So next month, I'm planning a post on rollbacks and dealing with the rejection path. If you've got any specific questions, send them in now and I'll try to answer them in the article.