How To Make Approval Rejections Useful

This article is relevant for the following ServiceNow releases: Yokohama, Zurich .

Enterprises often focus on approvals, but often reject to consider rejections (pun intended).

So let’s talk about it, and how we can make it more useful!

But before we dive into how to make approval rejections useful, we must first ask ourselves some basic questions.

Why do we need approvals?

Approvals can sometimes seem like mindless box ticking beuracracy, but they do serve an important purpose.

Like cars slowing down for a speed camera, just knowing that there is an approval process can be enough to stop end users from requesting things they don’t need. This alone can help control the cost of delivering services.

But on a more serious note, approvals are required for accountability and managing costs. Every user wants the highest spec laptop, every Microsoft 365 product, and now – every AI subscription – but do they really need it?

Without approvals, IT turns into a wild west spending spree with no one to blame when it all goes wrong.

Approvals can check if it is a legit business need, makes financial sense and fits company policy before fulfilment even starts wasting time or cash, in which they can be rejected.

How often are records rejected?

We understand the importance of approvals, but how often do requests actually get rejected? Are managers so overwhelmed with boxes to tick that they just always tick them?

I invite you to find out! In your head, guess what the rejection rate of tickets is in your instance.

Now, go on and report on it. It won’t even take 5 minutes!

Table: Approval [sysapproval_appover]
Type: Donut
Group by: State
Filter: State is one of Approved, Rejected

My Results+

What did you find? Was it more or less than expected?

In my experience, this typically sits at 2 – 4 %

Rejecting an approval is an edge case! As developers, we usually suggest that edge cases are not even considered.

But we all know that suggesting removing approval will never fly!

And perhaps knowing that a record can be rejected is enough to stop people from requesting silly things?

Why is rejection hardly used?

Rejecting a record usually stops the workflow in its tracks. This is even built into Catalog Builder, where one rejection will always cancel the request. In change, it takes it back to the New state, where the user who raised the record can either recreate or start all over.

That will teach the user to raise a bad record, right? It’s their own fault!

Or… no one ever rejects anything. They just add a work note and approve.

This can cause issues down the line, with auditing, and even workflow decisions made on data that has not been corrected, as we often see in Catalog items. Even if it is just because the wrong cost center was used!

It is common practice to lock down all end-user populated Variables on the Catalog Task / Requested Item view, as this is seen as the transcript, not to be updated after the record is raised otherwise it will invalidate auditing and potentially workflow automation.

So, what is the solution to make the rejection experience better for requests?

Making rejection useful

What if the end user could just correct themself, without having to fill out the form again, and resubmit for approval?

Rejected items as catalog item drafts

The solution

When an approval is rejected, the user is provided a link to resubmit the item with the appropriate corrections made. The link to their Drafts, which will contain a link to resubmit the original item, named with the approval rejection reason. This allows the user to make the correction required and resubmit without having to fill out the entire form again from scratch.

Assumptions

Employee Centre, using OOB Widgets
Rejecting via Employee Center, with rejection reason mandatory
Using the ‘Requested for’ field (delegated request experience)

How it works

The implementation is incredibly simple.

A Business rule on the Approval table copies all variables from the rejected RITM into a new Draft item:

(function executeRule(current, previous /*null when async*/) {
    var ritmGr = new GlideRecord('sc_req_item');
    if (!ritmGr.get(current.sysapproval + '')) {
        gs.warn('RITM not found: ' + current.sysapproval);
        return;
    }

    // Collect all variables from the original RITM
    var vars = {};
    var variableSet = ritmGr.variables;
    var keys = Object.keys(variableSet);
    for (var i = 0; i < keys.length; i++) {
        var key = keys[i];
        vars[key] = variableSet[key].getValue();
    }

    // Extract rejection reason from comments (skip first line with timestamp/user)
    var lastEntry = ritmGr.comments.getJournalEntry(1);
    var rejectionReason = lastEntry.substring(lastEntry.indexOf('\n') + 1);
    var draftName = `(${ritmGr.getDisplayValue()}) ${rejectionReason}`;

    // Create draft cart and add item
    var targetUserSysId = ritmGr.requested_for + ''; // Use original requester
    var cart = new sn_sc.CartJS('draft_items',targetUserSysId);

    var item = {
        'sysparm_id': ritmGr.cat_item + '',
        'sysparm_quantity': '1',
        'sysparm_name': draftName,
        'variables': vars
    };

    cart.addToCart(item);

})(current, previous);

An email Notification with content generated by a Mail Script is sent to the user, containing a link to the new draft (e.g. https://yourinstance.service-now.com/esc?id=my\_requests&draftSearchText=RITM0010237):

Email sent to the Requestor containing link to draft

The draft can be seen in the Drafts tab in My Requests, named with the RITM number and rejection reason:

The user can open draft, and only has to worry about changing the Cost center before resubmitting:

Where can I get this?

I’ve uploaded a copy of this to ServiceNow Share. You may wish to tailor the email notification to align with your organisations branding.

Complementary functionality

The following features are available OOB to improve your rejection process and can be used in combination with the above to improve the approval rejection process.

Approval Reason

In Yokohama, ServiceNow added the Approval Reason field to the Ask for Approval action in Flow designer to little fanfare. This can be used to provide approvers with guidance as to how the request is to be evaluated and approved against, to support a more accurate approval rate.

Once set in Flow, you’ll need to add this field to the To-dos configuration , Task configuration for your Approvals to show in the Employee Service Center.

Adding Approval Reason to Task Configuration

Adding Approval Reason to Approvals in ESC

Due Date

On the Ask for Approval Action you can also set a Due Date. This will prevent the request from waiting indefinitely for approval, with an option to reject it once the timer expires. This motivates the requester to nudge the approver, and the approver to do their paperwork on time.

What does “good rejection” look like, anyway?

With so much data on the ServiceNow platform, there is no shortage of things to report on. Have you ever considered reporting on the health of your approval rejections? What would be considered an acceptable rate of approval rejection? And is reporting on one dimension alone enough? A higher rejection rate could be considered bad (suggesting that forms are not well designed), or it could be a good thing, preventing wastage from occurring. Is less more? Quality over quantity?

We could consider measuring the following for a broad picture of rejection help:

Average time to approve
% Rejected within target range
% Approved on the second submission
$ Saved by rejections

Consider setting up some KPIs and measuring your progress, and leveraging the tips and tricks in this post to improve them.

Post your results!

The post How To Make Approval Rejections Useful appeared first on The SN Nerd.