The Solution…

At least in my mind, in order for this solution to be successful, it needs to meet a few criteria…

1. First and foremost, the user should not be notified of an approval request if they’ve already approved a record.
2. We need to maintain the history of the approval record for audit purposes and accurately reflect what happened to the redundant approval requests. This means that deleting or aborting record insertion is out of the question!
3. We cannot negatively impact the approval workflow by interrupting the normal approval process.

The first two criteria need to be met at the same time. Preventing the approval request could be done in a couple of different ways. One way would be to somehow manipulate the workflow activity to check if the user has previously approved. The drawback to this approach is that it requires hacking the workflow approval activities…which would be a significant upgrade risk, or adding custom code to every single approval activity in every single workflow…which would be a maintenance nightmare.

That leaves us with intercepting the creation/update of the approval records in a business rule. Using a ‘before’ insert/update business rule we can evaluate every ‘requested’ approval record, run a script to determine if the approval is for a user that has already approved this item, and then adjust the approval record by setting the approval state to ‘No Longer Required’…all before we trigger any update or notification to the approving user. We can also add some approval comments so that we can accurately reflect why the approval isn’t required anymore. Adding the following business rule to the ‘Approval [sysapproval_approver]’ table accomplishes that for us.

//Check to see if user has previously approved
approveDuplicateApproval();function approveDuplicateApproval(){
//Must have link to record being approved
if(current.document_id || current.sysapproval){
//Query for approval records for this user/record
var app = new GlideRecord('sysapproval_approver');
//Handle empty document_id and sysapproval fields
if(!current.document_id.nil()){
app.addQuery('document_id', current.document_id);
}
else if(!current.sysapproval.nil()){
app.addQuery('sysapproval', current.sysapproval);
}
app.addQuery('approver', current.approver);
app.addQuery('state', 'approved');
//Optionally restrict to current workflow
//app.addQuery('wf_activity.workflow_version', current.wf_activity.workflow_version);
app.query();
if(app.next()){
//If previous approval is found set this approval to 'approved'
current.state = 'not_required';
current.comments = "Approval marked by system as 'Not Longer Required' due to a previous approval on the same record by the same user.";
}
}
}

While the above script works great in manipulating the approval records on its own, it fails in the third criteria mentioned above…it can negatively impact the workflow in certain situations. This is because the workflow processing that happens after an approval status is changed isn’t seeing the true value of the approval request to process the workflow approval activity correctly. In my testing this couldn’t be done in a ‘before’ or ‘after’ business rule due to the timing of the updates. What is needed is to run the workflow checks one more time, and ensure that it happens after all of the above manipulation happens. The best way I could find to do this is through a separate ‘async’ business rule. The only downside to this async business rule is that it may not process immediately depending on the load on your system. Generally it should process within a few seconds though so for all practical intents and purposes it’s a non-issue.

// Run any workflows for our parent so they can check the approval states
runWorkflow_userApprove();function runWorkflow_userApprove() {
var id = current.sysapproval.nil() ? current.document_id : current.getValue('sysapproval');
var table = current.source_table.nil() ? 'task' : current.source_table;
if (id != null && table != null ) {
var gr = new GlideRecord(table);
if (gr.get(id)) {
new Workflow().runFlows(gr, 'update');
}
}
}

With the above solution in place, you should have created a very effective way to prevent the issue of redundant approval requests for the same user against the same record in ServiceNow.

The post Prevent Redundant Approval Requests in ServiceNow appeared first on ServiceNow Guru.

The following example scripts are designed to be placed directly in the ‘Approval Script’ field on a workflow ‘Approval’ activity as shown in the screenshot above. The ‘Approval Script’ field is only visible if you select ‘Condition based on script’ from the ‘Wait for’ field. Once you paste the script in, just adjust the ‘approvePercent’ variable for the specific approval percentage needed.

Percentage-based approval with an ‘Approval – User’ activity

This first example assumes you’ve got a group of users grouped into a single workflow activity. These users could all be members of a single group. In fact, this is how I typically do majority approvals for the Change Advisory Board. Regardless of whether the users come from a group or are added individually, they are all combined together when evaluating counts in an ‘Approval – User’ activity.

//Approve based on percentage indicated
var approvePercent = 50;
if((counts.approved/counts.total)*100 >= approvePercent){
answer = 'approved';
}
if((counts.rejected/counts.total)*100 > (100 - approvePercent)){
answer = 'rejected';
}

Percentage-based approval with an ‘Approval – Group’ activity

It is also possible (albeit a bit more complex) to do percentage-based approvals with an ‘Approval – Group’ activity. The primary difference here is that you can require a certain percentage from multiple groups. In the example given, each individual group must meet the 50% approval threshold before the activity will return ‘Approved’ and tell the workflow to advance. Any single group not meeting the 50% mark will force a rejection for the entire activity. This took me way more time than it should have to figure out :). Hopefully it saves you a bit of time.

//Approve based on percentage from each group
var approvePercent = 50;
var approveCount = 0;
for(var id in groups){
var group = groups[id];
if((group.approved/group.total)*100 >= approvePercent){
//Mark the group approval record 'Approved'
var groupApproval = new GlideRecord('sysapproval_group');
groupApproval.get(id);
groupApproval.approval = 'approved';
groupApproval.update();
approveCount++;
}
if((group.rejected/group.total)*100 > (100 - approvePercent)){
answer = 'rejected';
break;
}
}
//Ensure all groups have approved
if(approveCount == counts.total){
answer = 'approved';
}

The post Percentage or Majority-based Workflow Approvals appeared first on ServiceNow Guru.

The challenge that we faced was how to easily add those images while maintaining the mailto functionality and populating the correct information (including the watermark ID) on the reply email. Here’s a screenshot of the solution we came up with. Read on to see how we did it!

This post is not intended to be a full explanation of the approval email notification process but I think a short explanation is helpful in understanding the problem we faced. When an approval record is put into a requested state, it triggers an event that sends out an approval email corresponding with the task the approval is associated with. The approval email (and corresponding email template) are chosen based on the task type and event triggered. For request tickets the email template is called ‘request.itil.approve.role’ and everything else uses the ‘change.itil.approve.role’ email template.

Approval templates actually go one step further by including special mailto links within the email that allow you to show ‘Approve’ and ‘Reject’ reply links directly in the email. This makes it a little bit easier for your users to process these approvals directly from their email client. The template code that does this looks like this…

${mailto:mailto.approval}

What this says is that the system will construct a mailto reply link in the email based on the ‘mailto.approval’ email template. The ‘mailto.rejection’ template serves the same purpose. Each of these two templates contains the actual text for the mailto link that pulls in the number of the task to be approved as part of the link.

Click here to approve ${sysapproval}

The end result of this setup is an email notification with a couple of links for users to approve or reject directly from their email client.

So…now to add images. One idea would be to modify the template code to accomplish this. The challenge is that the ‘${mailto:mailto.approval}’ command in our first template automatically adds some important information (our reply watermark ID) to the reply email for us and there’s not another simple way to replace that functionality. The simplest solution in this case was to intercept the email on its way out of the system (after the original mailto link had been formatted) and modify that piece of HTML to include our image tags. This technique is something I’ve described before on this blog if you want to read more.

All of this can be done in a simple business rule on the ‘sys_email’ table. The business rule runs when the email record is being sent and corresponds with the approval table. Then it looks for some specific text that is included only in the approval templates…’Click here to approve’ and ‘Click here to reject’, and replaces it with an image tag. The only thing you’ll need to modify in the script below are the URLs for the images themselves to point to your own instance or other publicly-available images of your choosing.

current.body = current.body.replace('Click here to approve', '<img src="https://demo.service-now.com/images/workflow_approved.gif" />');
current.body = current.body.replace('Click here to reject', '<img src="https://demo.service-now.com/images/workflow_approval_rejected.gif" />');

Here is the end result…

The post Approval Email Mailto Image Links appeared first on ServiceNow Guru.

Simple Approvers Selection (Select Specific Group)

The simplest (and most common) type of approval is to select specific groups or users to approve the change. The screenshot below shows how you can use the standard reference field lookup to select a group to add as approvers to the change request. This method is commonly used when you want to have a specific group (like the CAB) approve at some point in your workflow.

Simple Approvers Selection (Drill to Related Records)

Another common method is to drill into the change request itself and pull the approvers from a field on the change. This method is commonly used when you want to have something like a manager approval for the person requesting the change (as shown below) or maybe when you want to have the assignment group on the change request approve.

Advanced Approvers Script (Approval Groups for all Change CIs)

The ServiceNow Graphical Workflow mechanism also allows you be even more complex in the selection of approvals for your change requests. You can use script with GlideRecord queries to return any users or groups you want to have approve. The one thing to keep in mind with these scripts is that you need to return group records if your workflow activity is a Group Approval type and user records if your workflow activity is a User Approval type.
One common request I’ve seen before that requires a script is to add approval groups based on the Configuration Items associated to the change request. Chances are you’ll have multiple CIs associated on the ‘Affected CIs’ related list for the change. This script queries for those records and then adds the groups from the ‘Approval Group’ field on each CI.

//Initialize an answer array to be returned
var answer = [];

//Add the primary CI approval group to the array
answer.push(current.cmdb_ci.change_control);

//Add the Affected CIs list approval groups to the array
var affCIs = new GlideRecord('task_ci');
affCIs.addQuery('task', current.sys_id);
affCIs.query();
while(affCIs.next()){
answer.push(affCIs.ci_item.change_control);
}

Advanced Approvers Script (Approval Groups for all Impacted Change CIs)

There are some rare cases where clients want to pull approval groups from other CIs that will be impacted by the change based on CI relationships. For these cases you can use the CIUtils2 script I created to walk the CI relationship tree and find the impacted CIs that you need to add approvals for. In order to use these scripts you’ll need to add the CIUtils2 script include to your system first. You’ll also want to use this type of approval method sparingly since it involves a sometimes resource-intensive traversal of your CMDB (if you have hundreds of thousands of CIs). It’s also pretty expensive process-wise as well. Do you really want to require approval from every single group in your company when your network team needs to make a change to the core router? Maybe so, maybe not, but either way you’re probably talking about a lot of approvals because that CI impacts so many other CIs in your environment.

//Initialize a variable for the CIUtils2 Script include
var ciu = new CIUtils2();
//Initialize an answer array to be returned
var answer = [];//Add any impacted business services for the change
var allCIs = ciu.cisAffectedByTask(current);

//Query for all CIs and return Approval Groups
for (var i = 0; i < allCIs.length; i++) {
var cis = new GlideRecord('cmdb_ci');
cis.addQuery('sys_id', allCIs[i]);
cis.query();
if (cis.next()) {
answer.push(cis.change_control);
}
}

//Initialize a variable for the CIUtils2 Script include
var ciu = new CIUtils2();
//Initialize an answer array to be returned
var answer = [];
//Initialize an array to gather and store all impacted CIs
var allCIs = [];

//Add the primary CI to the CI array
allCIs.push(current.cmdb_ci);

//Add the Affected CIs list to the CI array
var affCIs = new GlideRecord('task_ci');
affCIs.addQuery('task',current.sys_id);
affCIs.query();
while (affCIs.next()) {
allCIs.push(affCIs.ci_item);
}

//For each directly affected CI on the change, add any impacted business services
for (var i = 0; i < allCIs.length; i++) {
allCIs = allCIs.concat(ciu.cisAffectedByCI(allCIs[i]));
}

//Remove duplicate CIs from the array
allCIs = checkDuplicates(allCIs);

//Query for all CIs and return Approval Groups
for (var j = 0; j < allCIs.length; j++) {
var cis = new GlideRecord('cmdb_ci');
cis.addQuery('sys_id', allCIs[j]);
cis.query();
while (cis.next()) {
answer.push(cis.change_control);
}
}

function checkDuplicates(a) {
//Check all values in the incoming array and eliminate any duplicates
var r = []; //Create a new array to be returned with unique values
//Iterate through all values in the array passed to this function
o:for(var i = 0, n = a.length; i < n; i++){
//Iterate through any values in the array to be returned
for(var x = 0, y = r.length; x < y; x++){
//Compare the current value in the return array with the current value in the incoming array
if(r[x]==a[i]){
//If they match, then the incoming array value is a duplicate and should be skipped
continue o;
}
}
//If the value hasn't already been added to the return array (not a duplicate) then add it
r[r.length] = a[i];
}
//Return the reconstructed array of unique values
return r;
}

Ensuring someone approves

One of the big problems you may encounter is what happens if the approvers don’t exist or aren’t active. The behavior in ServiceNow is to mark the approval activity as ‘Approved’ if no approvers are returned by the activity.

// Set the variable 'answer' to a comma-separated list of user/group ids or an array of user/group ids to add as approvers.
//
// For example:
// var answer = [];
// answer.push('id1');
// answer.push('id2');var answer = [];
//Requested by and assignment group manager approval
if(current.requested_by.manager.active){
answer.push(current.requested_by.manager.sys_id);
}
if(current.assignment_group.manager.active){
answer.push(current.assignment_group.manager.sys_id);
}

//Ensure 'Change Admins' group gets added if no other approvers (optional)
if(answer.length == 0){
var grpName = 'Change Admins';
//Query for change admins group
var cGrp = new GlideRecord('sys_user_group');
cGrp.get('name', grpName);
answer.push(cGrp.sys_id);
}

Making a specific person the key approver

Some approval scenarios may also require that a specific individual has the full approval/rejection responsibility even as a member of a group. Even though others can approve or reject, a single person has the final say. Once they approve or reject, we move on from the activity. The following script can be used in an ‘Approval – User’ workflow activity to facilitate this type of setup.

Key Person Approval workflow activity
This script should be placed in the ‘Approval Script’ field in a ‘Approval – User’ workflow activity. The ‘Approval Script’ field displays when the ‘Wait for’ field is set to ‘Condition based on script’ as shown in the following screenshot.

//'keyApproverID' must approve or reject to advance approval
//Set the 'keyApproverID' variable to the sys_id of the user record of the key approver
var keyApproverID = '97000fcc0a0a0a6e0104ca999f619e5b';
if (approvalIDs) {
if (approvalIDs['approved'].indexOf(keyApproverID) > -1) {
answer = 'approved';
}
if (approvalIDs['rejected'].indexOf(keyApproverID) > -1) {
answer = 'rejected';
}
}

The post Change Management Workflow Approval Scripts in ServiceNow appeared first on ServiceNow Guru.

current.addQuery('caller_id', parent.caller_id);

But what happens when we set the Caller field with an empty value?

current.addQuery('caller_id', parent.caller_id);
current.addNotNullQuery('caller_id');

Adding the ‘addNotNullQuery’ line gives us the result we would expect at the bottom of our incident form.

current.addQuery('task', parent.sysapproval);
current.addNotNullQuery('task');

var qc = current.addQuery('table_sys_id', parent.sys_id);
qc.addOrCondition('table_sys_id', parent.request_item.sys_id);
qc.addOrCondition('table_sys_id', parent.request_item.request.sys_id);
current.addNotNullQuery('table_sys_id');

//Current record Attachments
var qc = current.addQuery('table_sys_id', parent.sys_id);//Request Attachments
qc.addOrCondition('table_sys_id', parent.request.sys_id);

//Catalog Task Attachments
var tsk = new GlideRecord('sc_task');
tsk.addQuery('request_item', parent.sys_id);
tsk.query();
var tskIDArr = [];
while(tsk.next()){
tskIDArr.push(tsk.sys_id.toString());
}
var tskIDStr = tskIDArr.join();
qc.addOrCondition('table_sys_id', 'IN', tskIDStr);

//Approval Attachments
var app = new GlideRecord('sysapproval_approver');
app.addQuery('document_id', parent.sys_id);
app.query();
var appIDArr = [];
while(app.next()){
appIDArr.push(app.sys_id.toString());
}
var appIDStr = appIDArr.join();
qc.addOrCondition('table_sys_id', 'IN', appIDStr);

//Do not include attachments not associated with a record
current.addNotNullQuery('table_sys_id');

//Add attachments for the approval task
current.addNotNullQuery('table_sys_id');
var qc = current.addQuery('table_sys_id', parent.sysapproval);//Add parent task attachments based on the approval task type
var appTask = '';
if(parent.sysapproval.sys_class_name){
appTask = parent.sysapproval.sys_class_name;
}
if(appTask != ''){
var tsk = new GlideRecord(appTask);
tsk.get(parent.sysapproval);

//Check for approval task type and add necessary queries
if(appTask == 'change_task'){
//Query for attachments from the associated change
qc.addOrCondition('table_sys_id', tsk.change_request);
}
else if(appTask == 'sc_task'){
//Query for attachments from the associated item and request
qc.addOrCondition('table_sys_id', tsk.request_item);
qc.addOrCondition('table_sys_id', tsk.request_item.request);
}
else if(appTask == 'sc_req_item'){
//Query for attachments from the associated request
qc.addOrCondition('table_sys_id', tsk.request);
}
else if(appTask == 'sc_request'){
//Set up a variable to store item sys_ids
var items = '';
//Query for attachments from the associated request items
var ritm = new GlideRecord('sc_req_item');
ritm.addQuery('request', parent.sysapproval);
ritm.query();
while(ritm.next()){
items = items + ',' + ritm.sys_id.toString();
}
if(items != ''){
qc.addOrCondition('table_sys_id', 'IN', items);
}
}
}

The post Defined Related Lists appeared first on ServiceNow Guru.

In most cases, it’s enough just to have an activity formatter on the task tables. You may find it necessary to add an activity formatter to a different table in your implementation. Recently I had a client who wanted to see all of the sent and received emails for approvals associated with a change request. Normally, sent and received emails are displayed as part of an activity formatter but since the Approval (sysapproval_approver) table isn’t a task table it doesn’t have an activity formatter. Since the approval table is audited you can view the history of each record, but you can’t see sent and received emails from that view. After just a few clicks, the client was able to add the formatter to the approval table and see the information they needed. Click here to see the wiki documentation explaining how to add an activity formatter to any table.

The post Adding an Activity Formatter Section to any Table appeared first on ServiceNow Guru.