Seeking Approval - Part 2: Task vs non-Task approvals and the Approval - Group Activity

[russ_sarbora]

In Part 1 of this series, I covered the basics of how workflow approval activities work. This time, I'm going to peel back the covers a bit more, and look at the difference between approvals for records from task-derived tables vs non-task-derived tables. Then we'll take a look at the Approval - Group activity, which only works with task-derived records.

Task Approvals

Back in the olden days before there was Workflow in ServiceNow, there were tasks and approvals. tasks needed to be approved, and it probably seemed that everything that needed approving was a task. And from this simple, pure view of the world, it was decided that Approvals should have a reference to the Task table. Thus it was made so, and it was good. Any record on a table that extended Task could have many approvals, approvals were related to exactly one Task, forms and related lists rejoiced, a simple Approval Engine managed the whole process, and all was well in the ITIL ivory tower.   You can kind of think of it like this:

With this design, Approvals could only connect to Tasks.

Then customers got hold of our platform. And they invented amazing new uses for it. We introduced the Workflow engine and Orchestration plugin. More customers invented even more new stuff. And soon the "everything that needs to be approved is a task" view of the world seemed pretty short-sighted. So it was decided to use Workflow to enable approvals on non-task records.

Non-Task Approvals

The fundamental issue facing the intrepid developer who undertook this feature enhancement, was that Approvals were linked directly to their Task via a reference field. That reference was pretty much what made the whole thing work, and reference fields by definition point to a specific table ( in this case Task). Since the goal was to enable Approvals for any record in the system, using that reference field was pretty much out of the question.

At this point, you are probably saying to yourself, "I really don't care about this", but stick with me a little longer, we're almost to the payoff. The solution to the problem was to add a new Document ID field to the Approval table, and make the Approval - User activity in workflow understand how to use that field instead of the task reference. The old connection to Task was left in place, so that no existing functionality would break, but a new, generic, connection was added. Kind of like this diagram to the right:

Finally, we get to the two reasons you will care about this:

1. only Workflow, and specifically, only the Approval - User activity can manage approvals on non-Task records. The Approval Engine does not run on non-Task tables.
2. Approvals store their link to the record they are approving in one field ("Approval for") if that record is a Task, and another field ("Approving")* if its not. If you are customizing or creating functionality related to the approval process, you need to use the correct field.

* Technically, a Document ID is stored in 2 fields, in this case "Approving" and "Source table". However, you usually don't have to care about the "Source table" field unless you're writing script.

While its not an ideal solution, it did let us accomplish the goal of extending approvals to non-task items, without breaking existing functionality.   And almost all the time, these details are transparent to you. For example, if you're editing a workflow that is based on a non-Task table, the palette will only show you activities that work with non-task tables have activities available. Similarly, the system automatically uses the correct field whenever an Approval record is displayed or processed. You've probably been using ServiceNow for a while now without even realizing this difference exists. Its really only if you are customizing or creating new functionality that you need to understand it.

That's probably enough of a peek behind the curtain for today. Now let's have a look at the Approval - Group activity. You can build this example as we go, or apply the attached Update Set which should have everything you need. If you're going to build your own, you should probably read the Workflow Setup Note in the first part of the article, it talks about the environment we'll be using.

Approval - Group : One for All and All for One

In the previous article, I explained that the basic job of an Approval activity is to:

1. create approval records

2. aggregate the outcome of those approvals into a final Approved/Rejected decision

That's still true of the Approval - Group activity, but it works on the group level. A Group Approval record will be generated for each unique group specified in the configuration of the activity. Just like with Approval - User, the activity gives you several ways to do that, including script. There are also configuration options for what logic will be used to make the final Approved/Rejected decision. You just have to remember that these apply to each group.

The wrinkle here is that a group is approving something. What does that mean? Well, in ServiceNow it means this...for every Group Approval, all members of the specified group will get an individual Approval. This lets the users in the group vote on the Group Approval.   The "Wait For" option on the Approval - Group activity gives different options for how the individual Approval "votes" will be counted towards the Group Approval. It also lets you determine how those Group Approvals aggregate into the final decision.

Hopefully an example will make all this clearer. Let's say we need a process to approve a change to a system. I'm going to use my WFApprovals Test table to represent the change, and say that for this type of change, we need sign-off from the Hardware, Network, and Database groups because they are ones who will be performing the change. I know that's a simple scenario, and I will make the same offer I did in the previous article. Send me your complicated, messy, headache-inducing approval use cases. At the end of this series, I want to do a post with our recommended ways to solve tough, real-world approval problems.

From the Workflow Editor, open the Seeking Approval - 2 workflow (or create a new one if you're building your own).

It should look something like this:

Next, double-click the Approval - Group activity to open the Activity config form. It should look like this:

I've given it a name and added the three groups that need give their approval to the Groups field. Other than that, I accepted the default values.

In Action

Create a new WFApprovals Test record. You don't need to complete any of the fields, but just for fun give it a short description like "Potentially catastrophic change to our most critical production system". When you click the Submit button the record insert will start our workflow. (Note: if you completed the Part 1 article and haven't removed that workflow, it will start as well. You can either ignore it or delete that old workflow.) One final caveat, I used out-of-the-box groups for this example and I'm expecting them to have their original out-of-the-box users in them. If you've changed that setup, you will see different results.

Just like in my last post, if you look at the workflow context diagram for our flow, it will be waiting on the Approval activity. The activity has created its Approvals, and its now waiting for them to be resolved. Once they reached a state where the activity can make a final decision, the workflow will take the appropriate transition and move to the next activity. The same events and business rules spiels that I went through in the last article applies, and that's all I'm going to say about that. Instead, let's look at what's different here.

Open the WFApprovals Test record you just created. You should have two related lists on it, "Approvers" and "Group approvals". Look at the "Group approvals" list first. There should an entry for each group specified in our activity configuration, and all entries will be in Approval state = Requested. So far, so good.

Now, look at the Approvers list. You'll have an Approval for every member in the three groups.

On my instance, that means 15 Approvals. Take a look at the first entries in the list above. Both of them are for Bow Ruggeri. Why the duplicates? They actually aren't duplicates, Bow happens to be a member of the Network and Hardware groups, and he gets an approval for each group. This is different from Approver-User. No matter how many times a user is specified in the Approver - User activity, only one Approval will be generated for them. That same consolidation logic does apply to Approval - Group, just at the group level. No matter how times you specify a group, only one Group Approval will be generated for it. But a user will get an Approval for every group they belong to, so that they can participate in that group's Approval process.

Wearing his Network hat, Bow reviews this change and decides its OK by him. Click on one of Bow's Approver entries and approve it.   By doing that, Bow has just approved this change for his entire group. You can verify that going back to the Group Approvals tab. The entry for Network will now be state=Approved.

Now go back to the Approvers tab and notice the State column on those. The Network group approval has already been resolved, so the approvals for the other members of the group are now in state "No Longer Required".   The approvals for members of the other groups are still in Requested state.

Next, Bow puts on his Hardware hat, and decides this change is crazy and there's no way he can approve it. Click on his other Approver entry and Reject it. This rejects the Hardware group approval. Based on the way we configured the Approval - Group activity in our workflow (okay, based on the way we accepted the default configuration), any rejection is enough to Reject the whole activity, so the workflow will take the Rejected transition and complete.

Auto-Approving

Remember from my previous article how Approval - User auto-approves if no active users are identified for the activity to create approvals for? Approval - Group behaves similarly. If either:

1. no active users are found in the specified groups

OR

2. no groups are specified

the Approval - Group activity will auto-approve. Notice that I didn't say "no active groups" in #2. We made a change in Eureka so that only active users would get approvals. I just discovered that fix did not get applied to the group approval logic. So whether a group is active or not makes no difference from an approval standpoint. Maybe that's correct behavior, or maybe we should fix it, I don't know. How often does a group get marked inactive anyway?

The End - For Now...Again

I'm going to stop here for now. In Part 3, I'll cover the Manual Approvals and Approval Coordinator activities. And in case you missed my offer in the text above, here it is again. At the end of this series I would like to wrap up with some best-practice patterns for handling difficult real-world approval scenarios. So if you have a specific use case you're struggling with, send it to me.