Workflow Automation CoE > Flow Designer > Approvals > Overview

Approvals on the Now Platform have undergone many changes throughout the years. In the early days, we would just set the task.approval field to the desired state with a UI Action or Business Rule. Then ServiceNow added the Approval table (sysapprover_approval) to properly track multiple approvers' replies. Then Workflow Editor was introduced and helped meet our customers' increasing needs for complex approvals with parallel paths and the approval coordinator. Flow Designer was introduced as an alternative to Business Rules back in the Kingston release in 2018. It has since evolved and been improved upon so much that it surpassed any previous business logic solutions on the Now Platform and can now handle any use case. Check out the Center of Excellence article to learn more about Flow Designer in general, best practices, and frequently asked questions.

Introduction

In this article, I will outline each type of approval that you may need and how to build them in Flow Designer. The main tool for this is the Ask for Approval action in Flow Designer. For the purpose of these examples, I'll use a Service Catalog flow, used to handle the fulfillment of a Catalog Item, but all of these instructions will work the same for any other approval use case. There's one notable exception: the Change Approval Policies, for which you use the Apply Change Approval Policy flow action. You can make use of Decision Builder to easily create and maintain your Change Approval Policies.

Speaking of Decision Builder, this is also a great way to determine which approval you need for your task fulfillment, depending on any type of conditions you need, e.g., the total cost of a catalog request or request item, the department of the requester, or the item category. To learn more about Decision Builder, check out the Center of Excellence article to get started.

In the past, many customers have shared feedback for the Ask for Approval action with us, outlining some unexpected behavior in approval creation and evaluation. To alleviate these concerns, we're working on a major overhaul of this flow action to ensure the approvals are generated and evaluated according to our customers' expectations. The first parts of this rework are available after upgrading to the Utah release, enabling the sequential use of Ask for Approval. I will outline a workaround that you can use for instances on releases prior to Utah, this same workaround will also enable parallel approvals.

Bonus tip: If you want to make your approval logic reusable for other catalog items or use cases, you can build it in a subflow to be able to add it to any other flow where you need this kind of approval. If you already have it built in an existing flow, you'll be able to break out those steps and convert them into a reusable subflow, starting in the Utah release.

Bonus tip 2: Watch the recording of our Platform Academy! @Andrew Barnes - and I covered all of these examples and approval patterns in a live webinar.

https://sn.works/platformacademy/35

Note: In my examples, the IF path goes If 1 - Ask for Approval.approval state IS NOT approved and then I'll end the flow execution for any of rejected, canceled, etc. This pattern allows the rest of the flow to act as theapproved path. An alternative approach would be to define If 1 - Ask for Approval.approval state IS approved and then use optional else if and else branches to handle other approval outcomes.

Single-stage approval

Let's start simple. The most common type of approval that you'll encounter in your ServiceNow environments is a simple manager approval. A task or request is being created and we'll need the requester's manager's approval to proceed with the fulfillment. In my example, I have a Catalog Item called 'Workshop Paper and Supplies' with a few catalog variables to order copier paper, pens, and other office supplies. It has a simple flow associated that will ask for approval, wait for the manager to give it, and then proceed with the rest of the fulfillment. Here, we're checking a decision table that tells us which discount we can give, depending on the item category. For the sake of the example, we'll only post the discount to the comments of the RITM, but in a real life scenario, we could recalculate the item cost and update the record from here. If the manager rejects we'll end the flow.

Example

Return to top

Multi-stage approval

This time we want to add another layer of approval, which we'll call sequential. These use cases often involve a manager approval first, then based on (for example) the total cost of a request or task there will be a second, third, fourth,... approval by the manager's manager, a cost center lead, a specific approval group etc.

With the improvements made in the Utah release, sequential approvals will work without any further workarounds. If your instance is on Tokyo or earlier or you want to have multiple approvals in parallel branches (Do the following in parallel flow logic), this workaround will help.

Workaround

Remove the value in Approval Field on the Ask for Approval action in your flow. Emptying this field has 2 effects:

1. The Approval Field field on the task will no longer be updated with the result of the Approval record. If this is required for your further process, make sure to add an Update Record action later in your flow.
2. The action will no longer create a record watcher for the state of approvals related to the task. For several approval actions in parallel branches, these record watchers lead to marking the other approvals as "No longer required" once the first approval has been completed. If there are no record watchers, each branch will wait for the completion of the approval in that branch, regardless of any parallel approvals.

Return to top

Sequential approval

Depending on what your process demands this second approval can be in addition to the first or an override. For an additional approval, place it in the happy path of the if-then-else branching ('if 1st approval given'), for an override approval place it in the reject path. As mentioned above, this works without further workaround if your instance is on Utah or up. For instances prior to Utah, empty the Approval Field on the first Ask for Approval action (Step 1).

Return to top

Complex approval

Continuing the path from simple to complicated, complex approval rules are next. These don't require any extra configuration or knowledge, but I think deserve extra attention, since not many people seem to be aware of the possibilities. More often than not, customers will define one set of approvers per action and then try to find ways with parallel paths to build out their use case. However, the Ask for Approval action is more powerful than it looks. You can define multiple rule sets connected with OR and define multiple condition sets within each rule set that also allow AND or OR conjunctions. Additionally, you can use the pill picker to send approvals to users or groups from previous flow steps. Be sure to check Docs to learn about all options.

One common example that we see is: we need several groups to approve, but if anyone rejects, reject the approval. This example is how you would handle this. The approval rules in the first part could also be 'All responded and anyone approves', 'All users approve', or a certain number or percentage of the groups approve.

Return to top

Parallel approval

Parallel branches may be necessary if the subsequent actions are different for each branch. If divergent, parallel logic is not needed, consider working with the extensive options of complex approval rules within one Ask for Approval action instead.

The default behavior of the Ask for Approval action is that a record watcher is being created for each approval. Once one of them is approved, the conditions of the second/all other record watchers are satisfied as well, so the next time the scheduled check looks at that record watcher, it'll change the second/all other approvals to "No longer required". If this does not suit your use case, you can use the workaround outlined above. Empty the Approval Field on the Ask for Approval actions, so that no record watcher is being created for those approvals.

Return to top

Scripted Approval rule sets

If all of the above was not sufficent to cover your use case, you can also define your approval rule set with a script. This allows you to perform more complex look up records actions and make use of flow variables and inline scripting to craft the necessary syntactic string to use instead of the low-code rule set within an Ask for Approval action. You can find all options and some steps on how to set this up with the help of a Flow Variable in my blog here.

Return to top

Decision Builder for approvals

Decision Builder is one of the strongest tools we have in our kit to simplify our logic, extract decisions from workflows, and handing the power of changing decisions to the responsible process owner. Decision Builder is a low-code builder that you can use to manage your decisions easily. It comes with different access-level roles that can be assigned to your business stakeholders, as well as an option to export & edit the decision table in MS Excel. Check out our recent Platform Academy with Product Manager Julia Perlis to learn more.

Example without Decision Builder

In our example use case, we want to have different Approval Groups based on the category of the Catalog Item. Without Decision Builder, we'll see an if-then-else logic part in the flow that can get unwieldy really fast and it's hard to keep track of all the branches. Additionally, each fulfillment beyond the approval is basically the same, but we'll have to keep it updated in multiple places if the slightest aspect of the Fulfillment Task, notifications, or updating the record changes.

Example with Decision Builder

When we use Decision Builder, we can simplify the management of our fulfillment flow by a huge factor. With it, we can remove the complex if-then-else branching and instead use the outcome of the decision table for our approvals. All steps after that will be the same and are easy to maintain. Decision Tables can have multiple condition columns that are connected with an implied AND. They can also have multiple result columns, so that your decisions can get as complex as you need them. The Default result at the bottom allows you to always have a fallback group if you add new Catalog Item Categories that don't have a dedicated Approval Group yet.