Workflow Automation CoE > Flow Designer > Approvals > Overview
Approvals on the Now Platform
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
Flow Approval System Properties
New in the Yokohama release, we introduced 4 additional system properties that greatly improve approval auditing. These new system properties give you more control over how approvals are tracked, especially in complex workflows involving delegation, impersonation, or inactive users and groups.
Let’s walk through each property with real-world use cases to help you decide how to configure them for your environment.
Showing Approver Names in Audit History
Property: com.glide.hub.flow.approval.show_approver_name_in_audit
Use Case:
A flow is triggered by a service desk agent, but the actual approval is done by a team lead. Without this property, the audit trail misleadingly shows the agent as the approver.
Set to true to ensure the audit log reflects the actual approver, not just the flow initiator.
Best for: Clear accountability in multi-user workflows.
Highlighting Role-Based Approvals
Property: com.glide.hub.flow.approval.show_higher_role_audit_comment
Use Case:
A senior manager approves a request because their role grants them override permissions. You want the audit log to reflect that this wasn’t a standard approval.
Set to true to add a comment like:
“XY approved, permission granted by role.”
Best for: Environments with tiered or escalated approval paths.
Tracking Delegate Approvals
Property: com.glide.hub.flow.approval.show_delegate_audit_comment
Use Case:
A VP is on vacation, and their delegate approves a budget request. You want the audit trail to show that the delegate acted on behalf of the VP.
Set to true to log:
“XY approved the task as delegate of YZ.”
Best for: Teams with formal delegation policies.
Capturing Impersonation Details
Property: com.glide.hub.flow.approval.show_impersonate_audit_comment
Use Case:
An admin impersonates a user to troubleshoot a workflow and accidentally approves a task. You need to know this wasn’t the user’s own action.
Set to true to log:
“System Administrator approved the task by impersonating XY.”
Best for: Admin-heavy environments or sandbox testing.
Types of Approvals
- Single-stage approval
- Multi-stage approval
- Complex approval
- Decision Builder for approvals
- Change Approval Policies
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
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:
- The
Approval Fieldfield 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. - 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.
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).
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.
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.
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.
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.
Change Approval Policies
Finally, our product team for Change Management have brought together Decision Tables and approvals in Flow Designer into a tailored process called Change Approval Policies. They've just published a brand-new webinar recording that takes you through everything you need to know:
https://www.youtube.com/watch?v=pKBNUhuE_uw
Center of Excellence Navigation
Hi @Lisa Holenstein Thanks for your reply.
I was checking the option you mentioned above but I couldn't find (attaching a screenshot)
You mentioned above "Once you pick a due date (this can also be relative to another date field data pill), there's an option box to say auto-reject, auto-approve, or auto-cancel." I am not seeing auto-reject, auto-cancel option after selecting the due date.
Could you please share a screenshot where you see auto-approve option?
Thanks
Jobi
@Jobi Thevupara I think I phrased it the wrong way round. You have the right field just there. You chose to either approve, reject, or cancel if the approval is still pending by the date you define.
@Monica Chakrabo this article is dedicated to Flow Designer Approvals, not Legacy Workflow. Please ask your question in a new post, possibly even on the PPM forum. That being said, you can look at the approval records, see who created them, and then trace the steps from there. It's possible they were added manually, not part of an automated workflow at all.
@Lisa HolensteinReject not working as expected. My expectation is when one group not approved after due date, RITM should go to closed skipped or cancelled state but that is not working.
RITM state stays OPEN
Approver state changed to No Longer Required. Is this expected behavior?
@Jobi Thevupara Maybe it's just your screenshot, but I don't see a data pill to set the date for the relative check, so it wouldn't know 5 minutes after which date/time. The action state output will be 'approved' or 'rejected' or 'canceled' - whichever you specified - and the individual approval records are no longer needed.
But: the Ask For Approval flow action will not do any further updating, except for the Approval field on the task. It should always be followed up with some if-else logic, as outlined in my article above. You can either go simple "if not approved then cancel RITM, else proceed with fulfillment" or have a branch for each option: "if approved, proceed with fulfillment, if rejected, do something else, if canceled, do another thing".
I am not sure if this is not working for me or it is how it is supposed to be. Kindly assist.
Below are the steps I followed:
1. Got a Utah Patch 4 hotfix 2 PDI.
2. Choose OOTB Catalog Item - "Miro"
https://<your_ instance>.service-now.com/sc_cat_item.do?sys_id=6c626eb297c2019021983d1e6253af48
3. Opened its flow.
https://<your_instance>.service-now.com/$flow-designer.do?sysparm_nostack=true&sysparm_use_polaris=false#/flow-designer/30f3d26187e92300e0ef0cf888cb0b91
The flow contains 2 approval sub flows.
a) Requested Item Manager Approval
b) Requested Item Dept Head Approval
4. Scenario 1: Created a RITM, approved first level approval, and then approved second level approval. Approval field on RITM got auto updated by approval flow listener.
5. Updated Ask for approval action in both subflows, and removed approval field.
a) Requested Item Manager Approval
b) Requested Item Dept Head Approval
6. Scenario 2: Created a RITM, approved first level approval, and then approved second level approval. Approval field on RITM got auto updated by approval flow listener, even when approval field was set as blank on both actions.
If I understood the blog correctly, all we need to do is make "Approval Field" as empty in the "Ask for Approval" flow action, so that it does not update the RITM Approval attribute. But in this case it is not working as expected. Can you please help me understand what I did wrong here.
Thank you in advance!
Thanks
Karan Sharma
__PRESENT
@Lisa Holenstein @Julia Perlis
Thanks for the videos and articles. I have been following and trying to learn from these examples.
Wondering if you assist with 1 simple decision build.
I would like to skip the approval if the request is opened by the manager of the "Requested for" variable.
1) Created this decision build:
2) Created a flow:
Opened by above is checking the variable "Requested for- > manager".
if its true it should create a catalog task but its not working for some reason.
Flow showing the values but its not skipping the approvals.
Any suggestions how this can be achieved?
Regards,
G
@GB14 First, I'm guessing this scenario is for training purposes only, as I would recommend to use an if logic for this use case. Within the condition column in decision Builder, there's no way to compare two fields, as there is no pill picker. All you can do is pick specific users (or groups or other records based on the column definition).
Besides the above, here are some further thoughts on issues you're running into:
- The decision table input is the Requested Item (sc_req_item), but the other screenshot asks for Opened by, looks like you made changes between the screenshots. It's best if you just hand in the whole item in case you need to build conditions off of several fields on this record.
- What the input is called (Opened by, Requested by, Manager, ...) is completely irrelevant if it's just a User (sys_user) reference input. The decision table won't know which user field you're looking at.
- The decision row doesn't have a condition at all, so it will always equate to true, thus triggering your approval.
Hope this helps!
Lisa
Please mark the post as correct if this answered your question.
Have questions about Flow Designer, PAD, or Decision Builder? Check out the Workflow Automation CoE.
Have questions about the Now Platform? Join our bi-weekly Platform Academy.
Hi @Lisa Holenstein - thanks for all the details here, really useful.
I'm having one issue and wanted to check if I'm missing something regarding approvals to multiple groups.
I've got my "Ask for approval" step set up as follows
Approve when:
Anyone approves from group 1
AND
Anyone approved from group 2
OR
Reject when:
Anyone rejects from either group
What I'm finding is that when the first person from a group approves, the other approvers in that group approval are not being set to "No longer required", they are still "Requested" even though the condition for that group approval has been met. All other approvals are only set to "No longer required" once at least 1 user from both groups has approved. So we could have 2, 3, 4 users approve from one group as long as there hasn't been a user from the second group who has approved yet.
The only way I'm finding around this is to do the hack of not setting the Approval Field and using multiple Ask for Approvals.
Is this expected, am I missing something? We don't want to bother people with unnecessary approvals showing up if the condition for their group approval has already been met.
Thank you for your feedback! 🙂 Glad this is helpful to you.
Can you try out "Approve when" - "# of users approve"? This did the trick on my instance! When I approved for one user in group 1, the others were set to No longer required, while the second group approvals were still requested.
Thanks for the great article. I tried your suggestion of using "# of users approve" for user approval instead of group approvals.
But when 1 person out of 2 approvers approve, the approval for other person do not change to "No longer required". See screenshot below.
Do you think I'm doing anything wrong here?
Thanks
Hi Team,
I've got an approval case that I couldn't find covered here (or in any threads).
The use case is:
1. ) Approval is sent to group A, due date set.
2.) If the approval is still "Requested" at due date minus 24 hours, then
3.) Create additional approval and send to group B, same due date.
I tried a "Do in Parallel" with a "Wait for Duration" but even if the first approval is received, that doesn't "cancel" the "Wait for Duration" -
Is this a situation where I'll need to script the approval? Any thoughts?
Thanks team!
