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 problem:

Here’s an example that most likely exists in your system (and certainly does in ServiceNow demo systems) to help illustrate the problem. If you go to your system and open an emergency change record, you’ll probably notice that it displays the ‘Emergency’ view in the top-left corner of the change form. That’s great, but when you click the reference icon for the ‘Requested by’ or ‘Assigned to’ fields, you’ll see that the system applies that view name (even though it doesn’t exist for that table) to the referenced record form. Then if you click on the ‘Company’ or ‘Department’ referenced record on the user form, you’ll notice that the ‘Emergency’ view name is carried over there as well!

It’s important to note, that the system is not actually creating new views as this happens. It’s simply cascading the previous form view to any other record you navigate to. The label of ‘Emergency’ is actually the smaller, cosmetic-only, issue. The larger issue is when you decide personalize that user or department form as an admin. You’ll most likely end up creating a brand-new view named ‘Emergency’ that applies to your user table! Now you’ve got an extra view and your changes won’t show up in the right place anyway because you meant to customize the ‘Default’ view instead…and you better hope nobody decides to reference that new, garbage view in a module or list definition and have it end up propagating the problem even further.

So, in short, this is a HUGE problem, and one that I’ve struggled with for the past 6+ years. It’s one ‘feature’ of ServiceNow that I’ve never understood, and this alone always makes me very hesitant to recommend the use of views to any of my clients. Fortunately there are a couple of things you can do to work around this…one that’s been around for as long as views have, and one that I came up with yesterday that easily allows you to override view inheritance for any table in the system.

Option 1: View rules

I’m a big fan of view rules and I’ve used them (primarily in change management) for a long time. They allow you to force a particular view on a particular table, for a particular subset of records. To use the change example again, you could set up a view rule to force the Default, Emergency, and Routine form views to display Comprehensive, Emergency, and Routine changes in their own respective views with their own sets of fields and related lists.

This is extremely handy, and can help break view inheritance because it forces a particular view for records in a table. The downside of this is that it’s not really practical to set up a view rule for every record table referenced from the change table just so you can overcome this problem. You could end up with a separate view rule for hundreds of tables!

Option 2: A better way…

Shown below is an example script that we’ve started using at Crossfuze in our Change turnkey product. This script runs on load of a particular table (Change request for example) and manipulates the form to remove any trace of a given view from the reference or related list links. A single client script can solve this issue for you on any table where you choose to set up custom views!

function onLoad() {
//Override all non-default change view inheritance for records referenced on change
overrideViewInheritance('routineChange', '');
overrideViewInheritance('emergencyChange', '');
}function overrideViewInheritance(oldView, newView) {
try{
//Override reference field link view inheritance
if($('sysparm_view').value == oldView){
$('sysparm_view').value = newView;
}

//Override related list link view inheritance
$('related_lists_wrapper').select('a.linked').each(function(elmt) {
elmt.href = elmt.href.gsub('sysparm_view=' + oldView,'sysparm_view=' + newView);
});
}catch(e){}
}

The post Overriding ServiceNow Form View Inheritance appeared first on ServiceNow Guru.

Today, I’m writing in response to a user on the ServiceNow community, and a few users in the advanced admin course I was observing earlier in the week. In the advanced admin class, they show how you can click a UI action on the change form to show a workflow in progress. They also show you how you can view a timeline for a workflow context. These UI actions (and corresponding popups) can provide valuable information to both administrators and technicians to determine the status and process of a particular workflow. The only problem (in the case of the timeline) is that it can’t be accessed from the change directly. You have to navigate to the workflow context record first.

In this post I’ll show you how to create a UI action script to display a workflow timeline popup directly from any task form in the system.

If you’re familiar with the default UI action in the system, the code below should look familiar. It is initiated from the client, gets the sys_id of the workflow context, constructs a URL to the timeline, and then pops a new window up showing the timeline. The real trick in this case is getting the correct sys_id from the workflow context record. You should be able to create the following as a UI action on your task table. It will display for any itil user on a task that has an associated workflow.

function showTimeline() {
var wf = new GlideRecord('wf_context');
wf.addQuery('id', g_form.getUniqueValue());
wf.query();
if(wf.next()){
var url = new GlideURL('show_schedule_page.do');
url.addParam('sysparm_stack', 'no');
url.addParam('sysparm_page_schedule_type', 'workflow_context');
url.addParam('sysparm_timeline_history', wf.sys_id);
var w = getTopWindow();
w.popupOpenFocus(url.getURL(), 'show_workflow_timeline', 950, 700, '', false, false);
}
}

The post Show a Task Workflow Timeline appeared first on ServiceNow Guru.

I’ve written before about UI macros, and different types of popups on SNGuru. I’ve also written about how your change management process can be a valuable input into your other ITIL processes such as incident management. You can refer to those posts if you’re interested in more detail on some of the ideas used in this article.

The real magic of this solution is how you can create this calendar report ‘on-the fly’ simply by constructing the correct URL. This is something that a colleague of mine, Bobby Edmonds, tipped me off to a couple of years ago. The URL contains several ‘sysparm_’ parameters that point to the fields on the report form. Once you know those, you just have to pass them the correct values. The URL for the calendar report needs to look something like this…

sys_report_template.do?sysparm_table=change_request&sysparm_type=calendar&sysparm_cal_field=end_date&sysparm_from_list=true&sysparm_manual_labor=true&sysparm_query=^end_date%3Ejavascript:gs.endOfLastMonth()'^cmdb_ci=YOUR_CI_SYS_ID_HERE

You might be asking, “Why don’t you just point directly to the existing change calendar report URL?”. You could certainly do that, and avoid all of the above, but the requirement in this case is to have the calendar report filtered based on the CI chosen in the field, so it needs to be dynamic.

Because this URL will be initiated from a UI macro (for this example) we’ll need to escape the ampersands and you can see that I’ve done that in the code below. The rest of the code is almost identical to the out-of-box ‘user_show_incidents’ UI macro that you see on the incident ‘Caller’ field. Once the URL is constructed we can use ‘popupOpen’ to display the report in a popup!

Your UI macro should look like this. Once set up, it can be added to the CI reference field of your choice by adding the ‘ref_contributions=ci_show_change_calendar’ attribute to the dictionary entry ‘Attributes’ field of that CI reference field.

<!--?xml version="1.0" encoding="utf-8" ?-->



<script>
function showCIChangeCalendar(reference) {
   //Construct the calendar report URL
   var url = 'sys_report_template.do?sysparm_table=change_request$[AMP]sysparm_type=calendar$[AMP]sysparm_cal_field=end_date$[AMP]sysparm_from_list=true$[AMP]sysparm_manual_labor=true$[AMP]sysparm_query=^end_date%3Ejavascript:gs.endOfLastMonth()^cmdb_ci=';
   
   var s = reference.split('.');
   var referenceField = s[1];
   var v = g_form.getValue(referenceField);
   url = url + v;
   //Open the popup 
   var features = "width=700,height=650,toolbar=no,status=no,directories=no,menubar=no,resizable=yes,scrollbars=1";
   popupOpen(url, 'show_calendar', 700, 650, features, true);
}
</script>

Add a Change Calendar Macro to a Catalog Reference Variable

You can use a similar technique to add a calendar macro icon next to a catalog reference variable. The big, additional challenge in the service catalog is that reference field macros are not supported for catalog variables. In order to add one you have two options. The first would be to create a UI page or UI macro-type variable similar to the example above. The big drawback would be that the icon wouldn’t appear right next to the reference variable without some clever client scripting.
The second option (which I chose) is to use a catalog client script to construct the macro on-the-fly and place it in the correct spot next to the reference field. This technique is based on a previous solution I wrote about in another SNCGuru article about placing macros next to non-reference fields.

Your catalog client script should look like this. Just add the name of your CI reference variable in the ‘ciVarName’ line below.

function onLoad() {
//The reference variable name to put the icon next to
var ciVarName = 'cmdb_ci';//Add the icon decoration to the reference field
var ciEl = 'lookup.' + g_form.getControl(ciVarName).id;
$(ciEl).insert({
after: '<a id="cmdb_ci_calendar_macro" style="padding-right: 4px;"></a><img title="CI Change Calendar" src="images/icons/dayview.gifx" alt="CI Change Calendar" />'
});
//Add the 'onclick' event
$('cmdb_ci_calendar_macro').observe('click', showCIChangeCalendar);

function showCIChangeCalendar(){
//Construct the calendar report URL
var url = 'sys_report_template.do?sysparm_table=change_request&sysparm_type=calendar&sysparm_cal_field=end_date&sysparm_from_list=true&sysparm_manual_labor=true&sysparm_query=^end_date%3Ejavascript:gs.endOfLastMonth()';
if(g_form.getValue(ciVarName) != ''){
url = url + '^cmdb_ci=' + g_form.getValue(ciVarName);
}

//Open the popup
var features = "width=700,height=650,toolbar=no,status=no,directories=no,menubar=no,resizable=yes,scrollbars=1";
popupOpen(url, 'show_calendar', 700, 650, features, true);
}
}

function onLoad() {
//The reference variable name to put the icon next to
var ciVarName = 'cmdb_ci';

//Add the icon decoration to the reference field
var ciEl = 'lookup.' + g_form.getControl(ciVarName).id;
$(ciEl).insert({
after: '<a id="cmdb_ci_calendar_macro" class="icon-calendar btn btn-default sn-tooltip-basic" style="padding: 6px 10px; vertical-align: text-bottom;" title="" data-original-title="CI Change Calendar"></a>'
});
//Add the 'onclick' event
$('cmdb_ci_calendar_macro').observe('click', showCIChangeCalendar);

function showCIChangeCalendar(){
//Construct the calendar report URL
var url = 'sys_report_template.do?sysparm_table=change_request&sysparm_type=calendar&sysparm_cal_field=end_date&sysparm_from_list=true&sysparm_manual_labor=true&sysparm_query=^end_date%3Ejavascript:gs.endOfLastMonth()';
if(g_form.getValue(ciVarName) != ''){
url = url + '^cmdb_ci=' + g_form.getValue(ciVarName);
}

//Open the popup
var features = "width=700,height=650,toolbar=no,status=no,directories=no,menubar=no,resizable=yes,scrollbars=1";
popupOpen(url, 'show_calendar', 700, 650, features, true);
}
}

When you’re done, your catalog variable will have a calendar link next to it that looks like this…

The post Building a CI Change Calendar Macro – On The Fly appeared first on ServiceNow Guru.

This setup allows you to track a primary CI or Business Service against a given task in the field on the form, and it also allows you to track multiple Affected CIs against a task if necessary in the related list. What I don’t like about this setup is that these are managed independently so there’s not a single place to see ALL of the Affected CIs in your environment. My solution to this problem has always been to centralize all of this information into the ‘Affected CIs’ related list by copying the ‘Configuration Item’ field value into it. This simple idea gives you a much better look into your Affected CIs for reporting, and allows for more proactive troubleshooting through CI Business Service Maps as an input into your task processes.

This customization is pretty simple and can be accomplished through the application of two business rules. The first business rule sits on the ‘Task’ table and should be configured as follows…

if(previous.cmdb_ci){
   removeCI();
}
if(current.cmdb_ci){
   addCI();
}

function removeCI(){
   //Get Affected CI records for this task and delete the CI if necessary
   var rec = new GlideRecord('task_ci');
   rec.addQuery('task', current.sys_id);
   rec.addQuery('ci_item', previous.cmdb_ci);
   rec.query();
   while(rec.next()){
      //Delete the Affected CI record
      rec.deleteRecord();
   }
}

function addCI(){
   //Get Affected CI records for this task and add the CI if necessary
   var rec = new GlideRecord('task_ci');
   rec.addQuery('task', current.sys_id);
   rec.addQuery('ci_item', current.cmdb_ci);
   rec.query();
   if(!rec.next()){
      //Create a new Affected CI record
      var ci = new GlideRecord('task_ci');
      ci.initialize();
      ci.task = current.sys_id;
      ci.ci_item = current.cmdb_ci;
      ci.insert();
   }
}

The second business rule sits on the ‘CIs Affected’ (task_ci) table and should be configured as follows…

//Check the parent task to make sure that the CI is not listed there
if(current.ci_item && current.operation() == 'delete' && current.ci_item == current.task.cmdb_ci){
   //Disallow removal
   gs.addInfoMessage('You cannot remove this CI since it is the primary CI on the associated task.</br>Please change or remove the CI from the task form.');
   current.setAbortAction(true);
}
if(current.ci_item.changes() && current.operation() == 'update' && previous.ci_item == current.task.cmdb_ci){
   //Disallow modification
   gs.addInfoMessage('You cannot change this CI since it is the primary CI on the associated task.</br>Please change or remove the CI from the task form.');
   current.setAbortAction(true);
}

Harnessing the power of the CIs Affected (task_ci) table

Once this is done, any change to the ‘Configuration Item’ field on a task record will automatically result in the creation of an ‘Affected CIs’ entry for that same CI. Now you can set up all of your reports for this area against this table. One of the most powerful things you can do with this data is to set up a BSM Map Action icon that can be displayed to show people from within a BSM map which CIs are being affected by different tasks in the system. There’s a great example on the ServiceNow Wiki that shows you how you can do this.

The post Track Affected CIs in One Place appeared first on ServiceNow Guru.

The out-of-box iCalendar integration for Change requests relies on a few different pieces. Most of the pieces are actually standard email notification business rules, events, and templates. The real mystery to this integration lies in the start/end date mappings for the meeting request. These are important because they define the fields on the task that the email template pulls its dates from. Once you get this set up correctly all you’ve really got to do is set up some standard email notifications with a template that I’ll show you below.

Setting up the start/end date field mappings

–Navigate to the legacy ‘Import Export Map’ table by typing ‘sys_impex_map.list’ in your left navigation filter.
–We’ll create a new entry that ends up looking like this…

–Create the map entry as shown in the image above
–Click the ‘New’ button on the ‘Field maps’ related list to create 2 field maps for your start and end dates
–Select the ‘Mapping to a database field’ option from the wizard

–Map your start and end dates as shown in the images below. For the Change task table, I’ve decided to use the ‘Expected start’ field for my start date and the ‘Due date’ field my end date. You MUST use ‘dtstart’ and ‘dtend’ for the external names for iCalendar integrations.


Once you’ve got the legacy Import/Export map configured, the rest is really just a standard email notification setup. You’ll need an event trigger, an event, and a notification that responds to that event. I’m not going to go over the specifics of setting up an email notification here. You can reference the ServiceNow wiki for that.

The out-of-box Change request setup uses a section of code in the ‘change events’ business rule. Even though you can trigger an event from lots of different places in the system, I think the business rule setup is going to work the best for most scenarios. The great thing about borrowing the code from the Change request table is that it already takes care of all of the different conditions for you. All you have to do is modify the field and event names in the script to go with your custom setup. I’ve modified the below to work with the ‘Expected start’ and ‘Due date’ fields from the Change task table. I’ve also modified the script to trigger 2 new events (which you’ll need to create), called ‘change_task.calendar.notify’ and ‘change_task.calendar.notify.remove’.

if (current.expected_start.changes() || current.due_date.changes() || current.assigned_to.changes()) {
if (!current.expected_start.nil() && !current.due_date.nil() && !current.assigned_to.nil()) {
gs.eventQueue("change_task.calendar.notify", current, current.assigned_to, previous.assigned_to);
}// Remove from previous assigned to, due to assigned_to changing
if (!previous.assigned_to.nil()) {
if (!current.assigned_to.nil() && current.assigned_to.changes() &&
(!previous.expected_start.nil() && !previous.due_date.nil())) {
gs.eventQueue("change_task.calendar.notify.remove", current, current.assigned_to, previous.assigned_to);
}
}
// Remove old calendar from current assigned to, due to date changing
else if (!current.assigned_to.nil()) {
if ((current.expected_start.changes() && !previous.due_date.nil()) ||
(current.expected_start.changes() && !previous.due_date.nil())) {
gs.eventQueue("change_task.calendar.notify.remove", current, current.assigned_to, current.assigned_to);
}
}
}

Once you set up your event trigger and corresponding events, you need to set up your notifications to be triggered by those events.
The final step then (and probably the most important) is to set up your email messages or templates. Again, I’m not going to go into specifics here about how to set up an email notification. It doesn’t matter if set up your message in the notification or template, but since the out-of-box Change request iCal setup has this in email templates I’ve decided to do the same for this one for consistency. The ‘Subject’ here is strictly a label. The real subject is actually populated through the ‘Summary’ line in the body of the email.

If you’ve set up your variable mappings correctly in the steps above you shouldn’t have to customize this piece at all. Just paste the contents of each of the sections below into the ‘Message’ box on your notification or template setup, set the correct table, and go. You’ll most likely want to have 2 notifications, one for an event request and one for cancellation.

If you need a guide you can look at the ‘Notify Change Calendar’ and ‘Notify Change Calendar Remove’ Email Notifications on the ‘change_request’ table (along with their associated templates).

BEGIN:VCALENDAR
PRODID:-//Service-now.com//Outlook 11.0
MIMEDIR//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VEVENT
ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:${to}
ORGANIZER:MAILTO:${from}
DTSTART:${dtstart}
DTEND:${dtend}
LOCATION:${location}
TRANSP:OPAQUE
SEQUENCE:${sys_mod_count}
UID:${uid}
DTSTAMP:${dtstamp}
SUMMARY:${summary}
DESCRIPTION:${description}
PRIORITY:${priority}
X-MICROSOFT-CDO-IMPORTANCE:${priority}
STATUS:CONFIRMED
CLASS:PUBLIC
END:VEVENT
END:VCALENDAR

BEGIN:VCALENDAR
PRODID:-//Service-now.com//Outlook 11.0 MIMEDIR//EN
VERSION:2.0
METHOD:CANCEL
BEGIN:VEVENT
ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:${to}
ORGANIZER:MAILTO:${from}
LOCATION:${location}
TRANSP:OPAQUE
DTSTART:${dtstart}
DTEND:${dtend}
SEQUENCE:${sys_mod_count}
UID:${uid}
DTSTAMP:${dtstamp}
DESCRIPTION:${description}
SUMMARY:${summary}
PRIORITY:${priority}
X-MICROSOFT-CDO-IMPORTANCE:${priority}
STATUS:CANCELLED
CLASS:PUBLIC
END:VEVENT
END:VCALENDAR

That’s it! If you’ve done everything correctly you should be able to send calendar invites from your change task table just like you can for change requests.

Can I send To Do Tasks or Notes too?

ServiceNow can send them if you modify the email template with the correct ‘VTODO’ or ‘VJOURNAL’ tags, but most email clients (including all from Microsoft) don’t support it. So, you can send all day, but chances are your email client won’t handle it!

The post Sending iCalendar Invites from any Task table 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.

The scripts below can be pasted into the ‘Wait For condition’ activity script field as shown here…

//Query for all tasks to see if they are inactive
var rec = new GlideRecord('sc_task');
rec.addQuery('request_item', current.sys_id);
rec.addQuery('active', true);
rec.query();
if(rec.hasNext()){
answer = false;
}
else{
//Continue
answer = true;
}

//Query for all tasks to see if they are inactive
var rec = new GlideRecord('sc_task');
rec.addQuery('request_item', current.sys_id);
rec.addNotNullQuery('wf_activity');
rec.addQuery('active', true);
rec.query();
if(rec.hasNext()){
answer = false;
}
else{
//Continue
answer = true;
}

//Query for all tasks to see if they are inactive
var rec = new GlideRecord('change_task');
rec.addQuery('change_request', current.sys_id);
rec.addQuery('active', true);
rec.query();
if(rec.hasNext()){
answer = false;
}
else{
//Continue
answer = true;
}

//Query for all tasks to see if they are inactive
var rec = new GlideRecord('change_task');
rec.addQuery('change_request', current.sys_id);
rec.addNotNullQuery('wf_activity');
rec.addQuery('active', true);
rec.query();
if(rec.hasNext()){
answer = false;
}
else{
//Continue
answer = true;
}

The post Wait for Closure of all Tasks in Graphical Workflow appeared first on ServiceNow Guru.

The following method works in much the same way, but it copies by performing an insert against the current record (rather than starting from a brand new change record and supplying each value). Because of this, you’re concerned about overriding any of the values (such as start and end dates) that you DON’T want to be copied over from the record you are copying. This method works better if you know you want to copy over all (or the majority) of the field values from a given change.

copyChange();
function copyChange() {
	//Get the current sys_id value for querying
	var chgID = current.sys_id.toString();
	//Initialize new change for insertion
	var newChange = current;
	newChange.number = getNextObjNumberPadded(); //Get next change number
	newChange.requested_by_date = 'NULL';
	newChange.start_date = 'NULL';
	newChange.end_date = 'NULL';
	newChange.calendar_duration = 'NULL';
	newChange.opened_at = current.opened_at;
	newChange.opened_by = current.opened_by;
	newChange.sys_created_on = current.sys_created_on;
	newChange.sys_created_by = current.sys_created_by;
	current.insert();
	
	//Copy attachments for this change
	if (typeof GlideSysAttachment != 'undefined')
		GlideSysAttachment.copy('change_request', chgID, 'change_request', newChange.sys_id);
	else
		Packages.com.glide.ui.SysAttachment.copy('change_request', chgID, 'change_request', newChange.sys_id);
	
	//Copy associated tasks and CIs
	copyTask(chgID);
	copyCI(chgID);
	gs.addInfoMessage('Change ticket ' + newChange.number + ' created.')
	action.setRedirectURL(newChange);
}

function copyTask(chgID) {
	//Find the current change tasks and copy them
	var tasks = new GlideRecord('change_task');
	tasks.addQuery('change_request', chgID);
	tasks.query();
	while(tasks.next()){
		var taskID = tasks.sys_id.toString();
		var newTask = tasks;
		if (typeof GlideNumberManager != 'undefined')
			newTask.number = GlideNumberManager.getNumber('change_task');
		else
			newTask.number = Packages.com.glide.db.NumberManager.getNumber('change_task'); //Get next change task number
		newTask.change_request = current.sys_id;
		tasks.insert();
		
		//Copy attachments for this task
		if (typeof GlideSysAttachment != 'undefined')
			GlideSysAttachment.copy('change_task', taskID, 'change_task', tasks.sys_id);
		else
			Packages.com.glide.ui.SysAttachment.copy('change_task', taskID, 'change_task', tasks.sys_id);
	}
}

function copyCI(chgID) {
	//Get the task record being copied
	var tskRec = new GlideRecord('task');
	if(tskRec.get(chgID)){
		//Copy over the affected CI list
		var cis = new GlideRecord('task_ci');
		cis.addQuery('task', chgID);
                cis.addNullQuery('u_ci_group'); //Added to ensure that copying does not duplicate Group CIs
		if(gs.getProperty('change.conflict.mode')=='advanced' && tskRec.cmdb_ci!=''){
			//Prevent duplicate CI from being added
			cis.addQuery('ci_item', '!=', tskRec.cmdb_ci.toString());
		}
		cis.query();
		while(cis.next()){
			var newCI = cis;
			newCI.task = current.sys_id;
			cis.insert();
		}
	}
}

One other method for copying a change (or any other ticket) is to reference the record to copy and copy from the referenced record. You could use the script below to copy a change that is pulled from a reference field on any form. Just provide the name of the field to grab the change from in line 3.

//Get the current sys_id value for querying
//Provide the name of the reference field to copy change from
var chgID = current.your_change_reference_field.toString();
var rec = new GlideRecord('change_request');
rec.get(chgID);
copyChange();

function copyChange() {
	//Initialize new change for insertion
	var newChange = rec;
	newChange.number = getNextObjNumberPadded(); //Get next change number
	newChange.requested_by_date = 'NULL';
	newChange.start_date = 'NULL';
	newChange.end_date = 'NULL';
	newChange.calendar_duration = 'NULL';
	newChange.opened_at = current.opened_at;
	newChange.opened_by = current.opened_by;
	newChange.sys_created_on = current.sys_created_on;
	newChange.sys_created_by = current.sys_created_by;
	rec.insert();
	
	//Copy attachments for this change
	if (typeof GlideSysAttachment != 'undefined')
		GlideSysAttachment.copy('change_request', chgID, 'change_request', newChange.sys_id);
	else
		Packages.com.glide.ui.SysAttachment.copy('change_request', chgID, 'change_request', newChange.sys_id);
	
	//Copy associated tasks and CIs
	copyTask(chgID);
	copyCI(chgID);
	gs.addInfoMessage('Change ticket ' + newChange.number + ' created.');
	action.setRedirectURL(rec);
}

function copyTask(chgID) {
	//Find the current change tasks and copy them
	var tasks = new GlideRecord('change_task');
	tasks.addQuery('change_request', chgID);
	tasks.query();
	while(tasks.next()){
		var taskID = tasks.sys_id.toString();
		var newTask = tasks;
		if (typeof GlideNumberManager != 'undefined')
			newTask.number = GlideNumberManager.getNumber('change_task');
		else
			newTask.number = Packages.com.glide.db.NumberManager.getNumber('change_task'); //Get next change task number
		newTask.change_request = rec.sys_id;
		tasks.insert();
		
		//Copy attachments for this task
		if (typeof GlideSysAttachment != 'undefined')
			GlideSysAttachment.copy('change_task', taskID, 'change_task', tasks.sys_id);
		else
			Packages.com.glide.ui.SysAttachment.copy('change_task', taskID, 'change_task', tasks.sys_id);
	}
}

function copyCI(chgID) {
	//Get the task record being copied
	var tskRec = new GlideRecord('task');
	if(tskRec.get(chgID)){
		//Copy over the affected CI list
		var cis = new GlideRecord('task_ci');
		cis.addQuery('task', chgID);
                cis.addNullQuery('u_ci_group'); //Added to ensure that copying does not duplicate Group CIs
		if(gs.getProperty('change.conflict.mode')=='advanced' && tskRec.cmdb_ci!=''){
			//Prevent duplicate CI from being added
			cis.addQuery('ci_item', '!=', tskRec.cmdb_ci.toString());
		}
		cis.query();
		
		while(cis.next()){
			var newCI = cis;
			newCI.task =
			rec.sys_id;
			cis.insert();
		}
	}
}

The post ‘Copy’ UI action for Change requests (Part 2!) appeared first on ServiceNow Guru.

calcChangeDates();

function calcChangeDates(){
//updateChange flag so we do not update unless necessary
var updateChange = false;

//Get the parent change to be updated
var chg = new GlideRecord('change_request');
chg.get(current.change_request);

//Query start times
var ts = new GlideRecord('change_task');
ts.addQuery('change_request', current.change_request);
ts.orderBy('expected_start');
ts.query();
while(ts.next()){
if(ts.expected_start && ts.expected_start.getNumericValue() != chg.start_date.dateNumericValue()) {
chg.start_date = ts.expected_start;
updateChange = true;
break;
}
}

//Query end times
var te = new GlideRecord('change_task');
te.addQuery('change_request', current.change_request);
te.orderByDesc('u_expected_end');
te.query();
while(te.next()){
if(te.u_expected_end && te.u_expected_end.getNumericValue() != chg.end_date.dateNumericValue()) {
chg.end_date = te.u_expected_end;
updateChange = true;
break;
}
}

//Update the parent change request if necessary
if(updateChange == true){
chg.update();
}
}

The post Calculating Change Dates From Change Tasks appeared first on ServiceNow Guru.