Service Now Business Rules Assignments

BUSINESS RULES:-

1) Create a after update business rule on incident table such that, when ever the incident goes into "Closed" state, we will trigger a email saying to caller of the incident -

Hi <caller first name>,

We are happy to Help you.

Please contact us for any more details.

Thanks.

2) Create a before query on business rule on incident table, such that users who are having itil role, should see only ACTIVE incidents.

3) Create a before insert business rule on incident table, such that one user should not be able to raise more than 4 incidents in a day.

4) Create a ASYNC insert business rule on user table, such that whenever user's last_login time changes, user should be notified with an email saying "Your account has been logged in at : <updated last_login time>".

5) Create a before update business rule on problem table, such that only user's having role - (problem_manager) should be able to update it.

How to work with Events in Service Now ?

·        One use for system events in the ServiceNow platform is to control email notification for system activity, such as when incident records are updated, or change requests are assigned.

·        There are  number of useful OOB events that provides you with a broad view of application activity

·        If existing events do not meet your needs, you can create your own events to watch for specific changes to ServiceNow records.

·        Administrators can create a custom event to send an email notification if an existing business rule does not provide the necessary event. For example, you might want to notify people who initiate a service catalog request whenever a comment is added to that request.

·        For checking if an event can be used or not, first it needs to be registered under: “Event Registry”

·        Events can be called from various Server Side operations like: Business Rules, Script Includes or Workflows

·        A Sample script is as below:

if (current.operation() != 'insert' && current.comments.changes()) {

gs.eventQueue("incident.commented", current, gs.getUserID(), gs.getUserName());

}

·        An event when triggered from any of these scripts, can either trigger a notification or execute an event script

The gs.eventQueue function takes the following parameters:

How Client Scripts works in Service Now ?

What is Client Script ?

Client scripts are shipped to the client (the browser) and run there instead of on the server. Users who know JavaScript can define scripts to run in the client browser. Several types of scripts are supported:

1. Scripts can run on the server, client and browser.
2. As Servers have direct access to database; server scripts are used to generate events.
3. Clients have direct access to forms; client scripts are used to make customization on forms.
4. Types of client scripts:
5. On load - This loads in the background when the form is clicked.
6. On Change: This runs when the user changes the value on the form.
7. On submit: this runs when the user submits the form. Used to validate the values that user added.
8. On celledit scripts: They are like on change. But except they run when the user changes values from the list view drop down.
9. Client scripts control the changes to the form by an API called Glideform.
10. The script calls the glide form API using g_form object.

G_user object is used to provide information about the current user.
G_user methods and properties :

- Makes calls to the database using the server without using the sql. This api uses the gr object.

- GlideAjax APi passes work to the server using scriptinclude.

Best practices of client scripts: 
1. We get a load of client scripts already in the system. So always keep a copy of the original before making any changes to it.
2. Client scripts take a bit time to load the data from server. So, use as less number of get.reference() functions to reduce the load on the server.
3. Write lengthy scripts on server side.
4. Call them using the script include.

What is Glide Form ? How it works ?

Glide form is normally use to customize the global applications and template applications which we have in the service now instance .With the use of Glide records we can control the applications form more like delete ,edit ,create ,change etc..

 The validations are done using Client Scripts. g_form is a global object in the Glide Form class. Client Scripts is the best place to excite the G_form objects. With the onload type of client script we can execute the form whenever we load the form. By the on submit type we can submit the form and post the values into the tables .With the on change type we can create a script that we can inter link one field with other field for auto changes .

The methods which we are discussing in the below can make custom changes to the form view of records.

·         G_form.setVisible = this method is use to hide and show the particular field in the form.

·         G_form .setDisplay= There is a little difference in between setVisible and setDisplay .We can maintain the hidden field space with using the setVisible method but with setDisplay we won’t have the space in between the hidden field .

·         G_form.addDecoration = with these we can highlight the particular field with start mark or with popup massage.

·         G_form. Flash = we can highlight the field with color and blinks or flash with particular no of times.

·         G_form.setLablelof =this method is required that user have to be” itill “role, so we can update the project name or whatever the text.

·         G_form.setValue = this method is use to check project status with check marks.

·         G_form.setReadonly =With this method we can make a particular field that will become as read only field, we can’t edit that field .

·         G_form.isnewRecord = to check the record which we are using that new record or old record.

How to display variables on Task Form from Request Item

This is very common and most useful requirement when working with Service Catalog Items.

Out of box, whenever any catalog item is submitted, all the variables will be presented / shown on request item. It will be very difficult for the fulfiller who are working on respective task associated to given request item to see all the variable. fulfiller has to go back to request item and has to come back to task form again.

Requirement : Copy all the variables presented on Request Item form to Task form corresponding to the Request Item.

Implementation :


- Open the catalog item.

- Open the Work flow corresponding to catalog item.

- Open the task where you want to see all the variables.

- Select the variables that you want to see on task form, shuffle to right hand side as shown below.

How to add custom text and icon to fields based on specific conditions in Service Now

Requirement -
1. Based on 'Caller' attribute on Incident form, Display a text(Public Sector Employee) in red color right below the 'Caller' field

2. Display 'Red Color' icon next to 'Caller' field on 'Incident' List view

Solution

1. Create a Client script as shown below

2. Write below script
function onChange(control, oldValue, newValue, isLoading) {
var callerLabel = $('label.incident.caller_id');
var callerField = $('sys_display.incident.caller_id');
if (!callerLabel || !callerField)
return;

if (!newValue) {
callerLabel.setStyle({backgroundImage: ""});
callerField.setStyle({color: ""});
return;
}
g_form.getReference('caller_id', vipCallerCallback);
}

function vipCallerCallback(caller) {
var callerLabel = $('label.incident.caller_id').down('label');
var callerField = $('sys_display.incident.caller_id');
if (!callerLabel || !callerField)
return;
var bgPosition = "95% 55%";
//check for VIP status
if (caller.vip == 'true') {
g_form.showFieldMsg("caller_id", "VIP", "error");
if (document.documentElement.getAttribute('data-doctype') == 'true')

callerField.setStyle({color: "red"});
}
// Check for federal status
else if(caller.u_company_cd == '198'){

g_form.showFieldMsg("caller_id", "Public Sector Employee", "error");
if (document.documentElement.getAttribute('data-doctype') == 'true')

callerField.setStyle({color: "red"});
}

else {
callerLabel.setStyle({backgroundImage: ""});
callerField.setStyle({color: ""});

}
}

3. Create a below style , to show 'red color' icon next to 'Caller' field in Incident List view.

How to Display Custom icon images on Incident Form and in List View in Service Now

This blog explains how to display special icons on Incident form (Caller field) based on user profile settings.

Example :

If 'Affected Person' belongs to 'VIP' then display 'VIP' icon image in 'Users' List view as well as on 'Incident' form

Solution

- Create a Client Script as shown below

- Upload the required icon image to System UI -> Images
- Write down below code under script.

if (caller.vip == 'true') {
callerLabel.setStyle({backgroundImage: "url(images/icons/vip.gif)", backgroundRepeat: "no-repeat", backgroundPosition: bgPosition, paddingLeft: '30px' });
}
- Whenever 'Affected Person' field value is selected, if the selected user belongs to 'VIP' then 'VIP' flag will be shown on Incident as shown below.

- To display the icons in List view , Below are the steps
- Goto Sytem UI -> Field Styles
- Create new one as shown below

- Below is how shown in List view.

How to modify the favcon Icon in Service Now Portal and Console

This blog explains about how to modify the 'Favcon' icon in Service Now Portal


Solution

1. Open Active Service Portals ( Service Portals -> Portals)

2. Click on 'Icon' , Select the .gif image that you wanted to use as a favcon

3. Save



Follow below steps to add favcon in Service Now Instance

1. System UI -> Images
2. Add a image , which you wanted to display as favcon
3. System Properties -> Properties
4. As shown below, click on 'Mirror' image and select the favcon image that you have uploaded in above step 2.

How to Auto Close 'Resolved' Incidents after 7 days in Service Now

This blog explains about how to  to auto  Close any 'Resolved' incidents after 'certain (7 days)' period of time.

Step 1 : Create a Schedule Item as shown below

Step 2 : Create a Business Rule as shown below

Step 3 : Write below script in 'Advanced' tab of above business rule

// This script automatically closes incidents that are resolved
// and haven't been updated in the specified number of days.
// This number is a property in System Properties.
// To place a comment in the incident, uncomment the "gr.comments" line.

autoCloseIncidents();

function autoCloseIncidents() {
var ps = gs.getProperty('glide.ui.autocloseincident.time');
var pn = parseInt(ps);
var queryTime = new GlideDateTime();
queryTime.addDaysUTC(-pn);

if (pn > 0) {
var gr = new GlideRecord('incident');
gr.addQuery('state', 6);
// gr.addQuery('sys_updated_on', '<', queryTime);
gr.addQuery('sys_updated_on', '<', gs.daysAgo(pn));
gr.query();
while(gr.next()) {
gr.state = 7;
//  gr.comments = 'Incident automatically closed after ' + pn + ' days in the Resolved state.';
gr.active = false;
gr.closed_by = gr.resolved_by;
gr.update(); 
}
}
}

Step 4 : Create below System Property (sys_properties.list) for glide.ui.autocloseincident.time 

Schedule Script triggers above business rule every hour and find out any 'Resolved' Incident more than 7 days, it will change the state to 'Closed'

How to Enable 'Create New Filter' for anyone

Problem : Allow anyone to 'Create New' filter in Service Now

What is Filter ?

A filter is a set of conditions applied to a table in order to find and work with a subset of the data in that table. Users can apply, modify, create, and save filters. The current filter is indicated by a hierarchical list of conditions—breadcrumbs—at the top of the table. Read More


Implementation

- Make sure you have 'security_admin' role associated .

- Enable 'Elevate Roles'

- Create a new ACL as per below screenshot

- Impersonate with any other role, make sure now you are able to create new filter

How to Email output of a specific report as an PDF attachment Periodically

Scenario : Capture outcome of a specific report into PDF and send out email as an attachment to specific group or users in Service Now

Solution

- Create a report

- Create a new schedule job, Select 'Automate the generation and distribution of a report' as shown below

- Enter the required fields as shown below

- Select the type as shown below

- Save the Schedule job

How to clear Cache in service now instance

This blog explains about how to clear cache in Service now instance

Solution

<Service Now URL > /cache.do - Paste this on your browser.

Eg : fmdev.service-now.com/cache.do - This will clear the cache and gives you stats.

How to share a report to specific role / group / user in Service Now

This blog explains about how to share a report created by specific user to either a group or role or other user in Service Now (Istanbul)

- Create a Report
- Click on 'Save' drop down as shown below and click on 'Sharing'

- If you want to share to 'Groups' or 'Users' then select ' Groups and Users' radio button , Then select the group or user that you want to share.

- If you want to share the report to specific Role, then select ' Everyone' radio button, then select the Role that you want to share

- Click on 'Save' button.

Reports should be accessible to group  or role or user now.

How to Retire all the CI(Configuration Items) which are 120 days old in CMDB

This blog explains about how to retire all the CI's which are 120 days old in CMDB

Solution

- Create a Schedule Job
- Configure how frequently you want to run this job
- Add below script

How to troubleshoot and fine tune Service Now Instance Performance

The perceived performance of your ServiceNow instance is made up of these components.

Ø  Application Server response: Time for the application server to process a request and render the resultant page

Ø  Network latency and throughput: Time for the network to pass your request to the server and the response back

Ø  Browser rendering and parsing: Time for your browser to render the HTML and parse/execute Javascript

Ø  Instance Cache: The amount of system resources available for processing

This document will outline basic troubleshooting steps to try to isolate the source of slow response times.

1.        Poor Network Performance: A fairly common scenario, users may experience poor network performance especially when there are multiple locations, in an on-premise installation, where the users must VPN in or where additional devices such as firewalls or proxies come into play.

Symptoms

• One or more users will report intermittent degraded performance
• If multiple users report issue it may only occur at specific times or locations
• If a single user reports issue it may only happen at specific locations

Verifying The Issue 

• Logout, completely clear cache, delete all cookies and try logging in again
• Log in from a different browser
• Log in from a different machine on the same network

If the issue still persists it may be an issue with the network. To verify:

1.      Navigate to Transaction Logs (All User)

2.      Find all transactions for a particular users session

3.      Find all transaction where the Client response time or Network time is excessive (>5000ms)

4.      If there are excessively high Network times then those should be flagged and you should look for additional logs around the same time

5.      If additional log entries are found this trend will likely point to a network issue

6.      If there are excessively high Client response times you should compare this time to the other “time” fields (excluding Browser Time)

7.      If the sum of the other time fields does not closely match the Client response time then it is likely a network issue.

Once you have determined you have a network issue it is necessary to look for trends to isolate the problem.

·        Do affected users have the same location or network?

·        Is the issue isolated to a specific time of day?

·        Do any users access ServiceNow through a proxy?

·        Is the issue intermittent or consistent?

Potential Root Causes

• Overloaded or malfunctioning networking equipment – This would almost certainly affect other applications as well.
• Overloaded proxy – If users access ServiceNow through a proxy, is the machine correctly configured and will it support the current load?
• Insufficient bandwidth.
• Poor wireless signal.

Fixes

• Unfortunately for networking issues there is not much that can be done from ServiceNow. Infrastructure may need to be upgraded or reconfigured to support the load.

2. Mis-Configured ACL: Usually occurring for non-admin users or those with specific roles, mis-configured ACLs can impact forms but especially lists where ACLs run multiple times.

Symptoms

• One or more users will report excessively long load times for lists or forms.

Verifying The Issue

1. Navigate to Transaction Logs (All User).
2. Find all transactions for a particular users session.
3. Find all transaction where the ACL time is excessive (>100ms).
4. For ACLs even a fraction of a second is a very long time.
5. Search for any other transactions for the same URL.
6. If the same URL has a trend of long ACL times there may be a mis-configured ACL.

Validate the ACL is mis-configured

1. Based on the URL you should be able to find the affected table. Usually it will be in the name however if it is not a standard List or Form page (for instance a UI Page) you may need to look through the contents of the page to see the source table(s).
2. View the ACLs for the table.
3. Look for any ACLs with Scripted Conditions.
4. Verify the Script does not have nested for loops or any other violations of best practice.

Potential Root Causes

• Poorly written Scripted ACLs
• Excessive number of records being accessed

Fixes

• Scripts should be re-written to be as efficient as possible.
• Lists and queries should be properly limited where necessary.
• Additional filters can be added to lists to cut down on the number of records returned.
• Potentially re-structuring tables or columns to simplify the script.

3. Mis-Configured Business Rule: A very common scenario is when Business Rules are not written correctly or several rules are written poorly and stack up to create a poor user experience. Most commonly when a user creates or updates but this can occur any time a business rule runs with the exception of asynchronous types.

Symptoms

• One or more users will report excessively long wait times saving or loading a record.

Verifying The Issue

1. Navigate to Transaction Logs (All User).
2. Find all transactions for a particular users session.
3. Find all transaction where the Business rule time is excessive (>2000ms).
4. Find all transaction where the Business rule count is excessive (>10).
5. Search for any other transactions for the same URL.
6. If the same URL has a trend of long Business rule times or counts there may be an issue with the BRs.

Validate incorrect Business Rules

1. Open the Business Rules for the particular table.
2. Look for Business Rules which match the conditions reported by user (when saving, when creating).
3. Look for all After or Before rules (Async rules will not apply since they do not stop the user session).
4. Verify there are not an excessive number or rules.
5. While having many Business Rules is not bad or uncommon the efficiency of those rules needs to increase with the number. Otherwise many rules that are somewhat slow can add up to a long wait time for end users.
6. Verify the content of the Business Rules.
7. Like ACLs you should avoid making an excessive amount of queries or nested queries in a BR.

Potential Root Causes

• Multiple poorly written Business rules
• Example: 10 or more rules which each take 250ms will end up 2.5 seconds for the user, this is only a part of the process though so the over all time may end up being excessive.
• Single poorly written Business rule
• A single rule taking more than 1000ms will directly impact the users experience

Fixes

• Scripts should be re-written to be as efficient as possible.
• Minimizing the number of GlideRecord queries and number of results returned.
• Potentially moving some scripts to asynchronous where possible

4. Under-performing Node: A very uncommon scenario but also one that is not fixable except by ServiceNow. This will usually involve ServiceNow restarting and possibly decommissioning the node.

Symptoms

• Multiple users will report excessive wait times performing any action in the system
• Issue will usually be intermittent
• Issue will occur more frequently at peak times

Verifying The Issue

1. Navigate to Transaction Logs (All User).
2. Find all transactions where the Response Time is excessive (>5000ms).
3. Add the System ID column
4. Verify that no other cause (Network, BR, ACL) is affecting the performance.
5. This may manifest as a longer Session wait time, Semaphore Wait time or SQL time
6. You may also try to eliminate transactions that are expected to take longer, such as those with larger outputs (Output length)
7. You may also eliminate those requests which affect multiple System IDs
8. If there is a node (System ID) which is constantly under-performing and where the same requests execute quickly on other nodes it may be isolated to that node.
9. You may open a HI server ticket to confirm the node is not functioning correctly

Potential Root Causes

• If the issue consistently happens even after restarting the node hardware may be defective
• Many other causes are unknown especially since we do not have access to the back-end

Fixes

• Ask ServiceNow to restart the node via HI ticket or Support

5.Browser Performance: A very common scenario especially for environments with older browser (specifically Internet Explorer). Poor performance is almost exclusively limited to IE but there are scenarios where Chrome and Firefox will not work correctly.

Symptoms

• One or more subset of users will report a performance issue especially loading forms or custom pages
• Issue will be consistent and easily reproduced
• Issue will only occur on a certain browser or machine

Verifying The Issue

Before verifying check that the user is actually using a Browser on their desktop or laptop and it is not related to a mobile device.

1. Navigate to Transaction Logs (All User).
2. Add the User Agent column.
3. Find all the Transactions for a particular users session who is reporting the issue.
4. OR Find all transactions where the Response Time is excessive (>5000ms).
5. Eliminate any transactions which can be explained by other issues.
6. Try to correlate any poor performance to a particular User Agent.
7. Look up the Users User Agent string to determine which browser they are using. UserAgentString.com

Validate the browser is not running in “Compatibility Mode”

1. For Internet Explorer ask the User to verify their version by going to “About Internet Explorer”
2. If the user reports a version which does NOT match the User Agent reported in the transaction log they may have compatibility mode on which should be disabled.

Validate the Browser is supported

1. Older versions of Internet Explorer (<10) generally do not perform well enough to have a good User Experience in ServiceNow
2. Versions of Internet Explorer (<9) may not work at all

Validate extensions are not interfering

1. Ask the user to disable extensions OR run an instance of the browser in private browsing mode (this usually disables all extensions)
2. If the issue does not persist with extensions disabled review the extensions to see if any may be causing an issue
3. Disable extensions one a time to verify.

Validate no errors are being reported

1. Ask the user to verify there are no errors in the JavaScript console. Most browsers have a developer console which will output all JavaScript errors.
2. Believe it or not some errors are expected but an excessive amount especially those which report missing resources could be affecting the user experience.

Potential Root Causes

• Unsupported Browser.
• Browser running in compatibility mode.
• Browser extension impacting performance.
• GPO pushing browser setting which impacts performance.
• GPO pushing system setting which prevents caching.
• Cache disabled through browser setting.
• Browser unable to reach resources – this may also manifest as the UI appearing strange.

Fixes

• Upgrading to the latest browser version.
• Disabling Compatibility Mode.
• Removing or resolving extension or browser configuration.
• Verifying network configuration (firewall or proxy) allows users machine to retrieve correct resources.

6. Excessive and Incorrect Client Side Scripts: Another common scenario is for the user to see poor performance due to too much form automation on the client side. Offloading some work to Business rules or re-architecting it for performance will usually resolve these.

Symptoms

• One or more users will report an issue with forms taking a long time to load.
• Users may reports jittery or unresponsive form when changing values.
•  

Verifying The Issue

1. Navigate to Transaction Logs (All User).
2. Find all transactions for the table or form where the issue is reported which have an excessive (>2000ms) Client script or UI Policy time
3.  Note that these values will only include those scripts run when loading.
4. If script time is consistently long there may be an issue with the number or efficiency of the script.

Validate the script is impacting performance

1. For either/both UI Policies and Client Scripts disable all scripts.
2. Enable each script testing the form.
3. Take note of the load time. If a single script increases the load time dramatically there may be an issue with the script.
4. If each script or policy increases the load slightly resulting in a long load time, there may be an issue with the quantity of scripts.

Validate the form layout

1. Validate there is not an excessive amount of fields,tabs, related lists or embedded lists on the form.
2. Validate there are not custom Formatters present.
3. If there are an excessive amount of controls on a form it will directly impact the load time for the user.

Potential Root Causes

• Too many Scripts or Policies.
• Poorly written Scripts.
• Excessive amount of AJAX transactions in scripts.
• Some AJAX is OK, but while those transactions are occuring synchronously the user is unable to do anything.
• Synchronous AJAX should only be used when the result is NECESSARY for the user to proceed.
• Too many fields present on form.
• Too many lists or embedded lists.

Fixes

• Re-writing Scripts to be more efficient.
• Refactoring or combining UI Policies.
• Changing synchronous AJAX to asynchronous where possible.
• Changing some form automation to run as Business rules where possible.
• Removing fields or creating additional views to only show necessary fields.
• Removing unnecessary fields or lists.

7. Incorrect User Exception: A perfectly valid expectation is that every page will respond quickly but not every page in ServiceNow is equal. Sometimes 5, 10 or even 30 seconds is reasonable when the system is crunching 1000s or rows to display in a report.

Symptoms

• User reports performance issue for particular pages.

Verifying The Issue

1. Navigate to Transaction Logs (All User).
2. Find all the transactions for the users session.
3. Find any excessively long transactions (>5000).
4. Take note of the URL.
5. If the user is loading home.do or a report it may be valid to expect wait times greater than 5 seconds.

Potential Root Causes

• User is loading a Report or Dashboard.
• User is loading too many records on a list. 

Fixes

• Explain to the user the wait times are valid.
• Reconfigure the report to have additional conditions.
• Reset the user preference to display less rows.
• Change the users Home page if possible.