Creating An Approval
This is something, that in my opinion, should be out of box functionality – but is not.
But the benefit of a platform like ServiceNow is that it allows you to create enhancements on the fly, whenever you want to change some out of box behavior.
Currently (as of the Quebec build), there is no functionality built into the ServiceNow Platform to restrict sending approvals only to active users.
So, when approvals are created, there is nothing stopping a user that left the company from getting an approval request. Now this isn’t so much a security concern, because the inactive user will never actually get an email, but it will ultimately hold up the processing of the request and confuse users. A common example that I’ve personally seen is a user at a company having duplicate ServiceNow User accounts, and one is either ignored or never turned off. So when an ITIL user comes in, they select the wrong user account and the approval goes essentially to nobody. There are numerous reasons, (usually not good ones), why a certain company would allow duplicate users – it all depends on how well managed their user data is.
Approvals have a tremendous amount of power in ServiceNow, and the automation behind it can really transform an IT organization. So the approval process should be audited by every ServiceNow team. Don’t always just take what ServiceNow gives you, make sure that you’re modifying the system so it aligns with your companies use cases. There is no “one size fits all” in IT.
In the example below, we’ll run with the use case of only allowing an approval to be sent to an active user, which is pretty basic. Feel free to take the script and elaborate on it, if your use case is a little different.
Essentially, we can control who in the system we send an approval request to, before the approval is sent.
How To Only Send Approvals To Active Users
This is an operation that we want to enforce on insert of a record, so we will go with a simple business rule.
Regardless of what tables you’re processing approval requests on, we can stop the insert of an approval record, under any condition – but we will go with “if the user is not active”. You could restrict approval request to users with certain roles or those within certain groups, etc. This should all be built out in the condition line below.
Now, we will write a quick business rule that will only allow the insert of the approval record, if certain conditions are met.
Table: Approval [sysapproval_approver]
Condition:
current.approver.active == false;
Script:
(function executeRule(current, previous /*null when async*/ ) {
// Don’t allow the approval record to be created
current.setAbortAction(true);
gs.addErrorMessage(“Approval requests can only be sent to active users. ” + current.approver.getDisplayValue() + ” is no longer active. Try again with someone else.”);
})(current, previous);
When: Before
Insert: True
The above business rule runs right before a record is inserted into the Approval table. The script that is executed will only process when the condition is met.
So putting it all together, anytime an approval is created – we will always check to see if the approval user is active. In the condition we dot walk from the current record (the approval), to the Approver reference field (The user) and then ultimately to the Active boolean on the user record. This is an out of box field that is on every user record, so we will assume that it exists. When this active boolean is false, we run the script.
Another note which is just a nice touch to add is throwing an error message to the user that’s trying to process the record. If you just don’t allow them to create the approval request, and they just get an “Invalid Updated” error which is thrown whenever the current.setAbortAction(true) runs, then it will likely confuse the user. They won’t know why they can’t process the record. Adding informational and eror messaging is a crucial component to being a ServiceNow Admin/Developer. Over time, the busines units using the platform will come to really appreciate the guidance.
How To Test The Approval
Go ahead and submit 2 different approval records. One for an active user, and another for an inactive user.
You’ll quickly see that you can only process an approval request for a user that has “Active = true” on their user record.
In the above example, I took the OOB user “Abraham Lincoln”, made his user account (Active = false), and then tried to create an approval request. The approval request is not inserted – and we get the error message, just like we hoped.
If you are having any issues with this, double check the script again, and make sure that it is running “before” insert.
