Don't Create An Approval, If Task Is Assigned To Approver

Table of Contents

Don’t Allow Approval To Be Created, If Task Is Assigned To That User

How do we stop an approval from being created, if the associated task is assigned to that user? We don’t want people to be able to approve their own cases in ServiceNow. This would defeat the entire process of an approval

Since it’s a little difficult to fully explain, let’s use an example.

Example: A Change Request exists and is “Assigned to” Abraham Lincoln. Someone goes in and tries to get Abraham Lincoln to approve the Change Request. But why? Why would a user be approving their own request? This removes the need for an approval in the first place.

Or say for example that a certain request needs to be “Approved” before an employee can make a certain financial expense? If you can just approve your own task – an approval becomes pointless.

We can set up a simple business rule that checks the assigned to user on the task, before, the approval is inserted. If we discover that the approval record is the same as the “assigned to” user on the task – we just don’t allow the record to be created.

If your IT Org is using dynamic approvals, then this is a less likely scenario to run into. But it stops someone from being able to get around the approval process.

This is another example of something that should be out of box in ServiceNow, natively.

We are using setAbortAction() in this post, if you’re not yet familiar with that – it is covered here.

Prohibit An Insert or Update with setAbortAction(true)

If you are already well versed in using setAbortAction() in a business rule, keep on reading how we can use it in another example.

Manual Approvals – Who Would Do That?

Approvals in ServiceNow should be, dynamic.

Meaning that when a certain point in workflow is met – the system auto generates an approval record from a manager/VP/other stakeholder.

This process covered here is really meant for IT Orgs that are still processing approvals manually.

While this is not a best practice to still be creating ad-hoc approvals, I think a lot of companies are still operating this way. We’re not recommending that you have manual approvals set up – but if you already do and you’ve run into this problem. Then this business rule will provide you with a solution to stop some bad behavior. In the long run, consider moving to a more automated approach.

Consider baking in approvals to your processes that run on workflows, this will take the guess work out of any approval creations. ServiceNow can be configured to understand when to kick off an approval, and who it should go to – automatically. There shouldn’t be a need to check a run book to see who owns what, as the data can all live inside of ServiceNow.

Approval Records

All approval records have a few things in common that tie them to a record to take action upon.

We have a couple reference fields on every approval record that shows what record is being approved and who is approving the record. No real surprises here.

For this business rule, we’re just getting the value of the “Approver” and then checking it against the value of the “Assigned to” user on the “Approving” reference field. If they’re the same, we stop the record from being created.

What we’re going to do is create a before/insert business rule that just does one simple comparison check before being created

When: Before

Insert: True

Table: Any Task table, example: Change Request

Script:

(function executeRule(current, previous /*null when async*/ ) {

checkApprover();

function checkApprover() {

// Retreive data about user and change
var apprUse = current.approver;
var changeRecord = current.sysapproval;

// Find the change request
var getUser = new GlideRecord(“change_request”);
getUser.get(changeRecord);

var assignedTo = getUser.assigned_to.toString();

// Does the approver match the assigned to user. IF so,
// don’t allow the approval to created and throw an error
if (apprUse == assignedTo) {

// Throw an error
gs.addErrorMessage(“The attempted approver is assigned the Change request. Select another user.”);

// Don’t allow insert
current.setAbortAction(true);
}
}

})(current, previous);