Skip navigation

If you are upgrading your instance prior to Berlin to a later release, you’ll need to activate the Engine Based Notifications, which is not activated by default. These give you a much easier way to design and implement notifications with 38 base-system notifications that trigger automatically when records are inserted or updated.

 

But before you activate your plugin, you’ll first need to save your personalized notifications so these are not overwritten by the engine-based notifications. These notifications range from Appointment Invites and Change approved to Incident Resolved. You can view the full list of notifications here.

 

To save your changes, you should export any modified email notifications prior to activating the Engine Based Notifications plugin, and then re-import your customized notifications. Or, if that's not an option, you can use of the platform's versions feature to recover previous customized notifications.

How to recover previous customized notifications using the versions feature:

  1. Navigate to System Policy > Email > Notifications.
  2. Open any customized email notification that was overwritten by activating the plugin.
  3. Right-click the form header and select Personalize > Related Lists.
  4. Add the Versions related list.
  5. Use the Version related list to review and revert changes that were caused by the plugin.
  6. Repeat as necessary.

 

Screen Shot 2015-02-25 at 11.45.27 AM.JPG

 

For more information on notifications and your upgrades, see:

"Speaking for myself, I spend a good ten minutes a day deciding whether or not to read the results of new surveys, and, once I have read them, a further five minutes deciding whether or not to take them seriously."

- Craig Brown

 

No matter how you feel about surveys, the Fuji release of ServiceNow provides some great new survey functionality to work with when trying to obtain feedback or information. The Survey Designer enables users with the survey_admin role to create, configure, manage, and distribute high-quality surveys from a single centralized location. Following are very basic instructions for creating, configuring, and publishing a survey in Fuji.


How to create a Survey:

 

  1. Navigate to Survey > Survey Designer.
    The Survey Designer opens in a new tab or window.
  2. Type a Name for the new survey.
  3. Create a question by dragging a question type from the Controls palette on the left to the survey on the right.
    survey_designer1.jpg
  4. In the question header, click the gear icon to configure the question.
    survey_designer2.jpg
  5. Repeat steps 3 and 4 to create additional questions.
  6. To see what the survey looks like, hover over the menu icon and select Preview.
    survey_designer3.jpg
  7. Make any necessary changes.
  8. Click Save.


How to configure and publish a Survey:

 

  1. Navigate to Survey > Survey Designer.
  2. Hover over the menu icon and select Load Survey.
  3. Click the lookup icon and select a survey.
  4. Click OK.
  5. Click Configuration.
    survey_designer4.jpg
  6. Make changes that apply to the whole survey. For example:
    • Allow users to take the survey without revealing their names by selecting the Anonymize responses option
    • Write some opening text or instructions in Introduction
    • Add some closing information or a thank you message displayed for users after they take the survey in End note
    • Set a limit on how long the survey can be taken in Duration
  7. Click Save.
  8. Hover over the menu icon and select Save and Publish.
    survey_designer5.jpg

How to view Sample Surveys:

 

If you'd like to jump in and start playing around with surveys, there are several sample surveys to view, edit, and test.

 

  1. Navigate to Survey > View Surveys.
  2. Click a survey Name.
    Tip: The Service Desk Satisfaction Survey contains a good set of survey responses to view.

The Survey Designer contains many more useful and powerful features including:

  • categories for organizing groups of questions on a survey and reporting scores separately
  • dependencies for creating special conditions that must be met for specific questions to appear on the survey
  • option for setting mandatory questions
  • randomizer for displaying answers in a different order
  • templates for creating questions consistently and quickly
  • retakes for resubmission of survey answers
  • different view options for survey results, including color-coded scorecards - here is a sample scorecard
    survey_designer6.jpg

For more information about the Survey Designer and detailed instructions for creating and managing surveys, see Survey Designer in the product documentation.

"The reality, I believe, is that all change starts small. The big picture is just too unwieldy, too incomprehensible and seemingly immovable. But give us something individual, quantifiable and personalize-able and, suddenly, our perspective shifts to the one." 

- Mick Ebeling

 

With the Fuji release, you can now personalize forms just for yourself. Yes, you can personalize the fields that appear on a form view and no one else is affected by your changes.


Personalizing a form is different than configuring a form. When you personalize the form, you choose fields from the Personalize Form list to change how the form appears to you. Users with the itil role can personalize forms. Configuring a form changes the way the form looks for all users. Administrators and users with the personalize_form role can configure forms.


How to personalize a form:

 

  1. Open a record. For example, an incident, problem, or change record.
  2. Click the gear icon personalize_form1.jpg.
  3. Do one of the following:
    • Clear the check box next to a field in the Personalize Form list (the list shows only the fields that the form is configured to display)
    • Click the hide icon personalize_form2.jpg next to a field

      For example, to hide the Subcategory field, click the hide icon next to the Subcategory field or clear the Subcategory check box in the Personalize Form list.
      personalize_form3.jpg

      Note that any check boxes in the Personalize Form list that are grey and selected cannot be hidden. These fields are either required or are hidden by a UI policy or client script. For example, in the list below the Close code and Close notes fields cannot be hidden.
      personalize_form4.jpg
  4. To save your changes, click anywhere outside the Personalize Form list.

 

Here are a few tips when personalizing forms:

  • After personalizing a form, your form changes are retained for the future.
  • The first time you personalize a form, all available fields appear in the Personalize Form list. If you hide any fields using the Personalize Form list, those fields will no longer appear in the list. Reset the form to see all fields in the list again.
  • You can reset the form to the default settings at any time by clicking the gear icon and then clicking Reset.

 

ServiceNow offers additional resources for personalizing your forms in Fuji:

View Management

Administering Form Personalization

Dot-walking and personalizing forms

Someone asked me how they could send an actual document with a notification and not just a link to it.  That's pretty easy now, with the "Include attachments" field on the Notification record.  However, in this particular case, the document was not being attached to a task or other type of record - it is a PDF document that contains the company's Terms of Service.  They wanted to send the PDF out to users in certain situations, such as when ordering a catalog item.

 

So, instead of manually attaching the document to multiple records whenever it needed to go out, this is how it can be handled, limiting the amount of scripting and maintenance required.

 

Step 1 - Create a new Event in the Registry

Select the "Registry" module in the "System Policy" application and create a new record.  I called it "u.terms.of.service" (remember to prefix any custom events with "u." in order to avoid issues with SN adding a new event with the same name) and set the Table field to "Knowledge [kb_knowledge]":

Custom_Window_Title.png

 

 

Step 2 - Create the Notification

Create a new notification, and set it to go out when the "u.terms.of.service" event is fired:

Test_-_Terms_of_Service.png

 

Make sure the "Event parm 1 contains recipient" field is checked as we will send the sys_id of the user in the event in step 4 below (you may have to switch to the Advanced view to see the field):

Test_-_Terms_of_Service.png

Make sure the "Send to event creator" field is checked as well to ensure the email will go out.

 

The important part of the notification is to select the "Include attachments" field:

Test_-_Terms_of_Service.png

 

Fill in the Subject and Message fields with whatever you want in the email message.

 

 

Step 3 - Create a new Knowledge Article

This step allows you to create a record that will contain the attachment(s).  Create the article and attach the document to the record.  I use the event name as the Short description.  You can limit who can see the article by adding the "admin" role to the "Roles" field.  You do not even have to publish the article in order for this to work, so only your admin and KB admins would even see it.  You can also create a new Topic and Category combination for these documents if you want to separate them from all the other "normal" KB articles.

 

NOTE:  You will need to export the article from your development instance and import it into production or just recreate the article in production as the KB table is not tracked in Update Sets.

 

 

Step 4 - Fire the event

This can be from a Business Rule or even a Workflow - all depends on the requirements:

 

(function() {
    var gr = new GlideRecord("kb_knowledge");
    gr.addEncodedQuery("workflow_state=published^short_description=u.terms.of.service");
    gr.query();
    if (gr.next()) {
       gs.eventQueue("u.terms.of.service", gr, current.getValue("caller_id"));
    }
})();

 

The script queries the KB table for a record with a Short description the same as the event name (or however else you may want to search for it).  It then adds the event to the queue if it finds a record, passing along the event name, the GlideRecord object of the KB article (gr) and the user who should receive the document (current.getValue("caller_id")).  You will probably have to change where you are getting the value for that last parameter based on your situation (my example is sending the email to the Caller on an Incident record).

 

The nice thing about doing it this way is you can easily update the attachment on the KB article record and the new document will go out from then on.  The condition on line 3 of the script checks for a published KB article - that way you can retire the article and the notification would no longer go out because the event would not fire as the article would not be found in the query, all without having to change any code.

*** Please Like and/or tag responses as being Correct.
And don't be shy about tagging reponses as Helpful if they were, even if it was not a response to one of your own questions ***

Often times, when viewing a record in the instance that is not behaving as expected, the issue may be related to client side issues. For example, you may have an incident where your client scripts and/or UI policies do not seem to be processed correctly. A good give away that the issue is a client side issue, is that it will involve things like buttons not working, or the right click menus no longer appearing, or the form does not completely render.

 

If a client side scripting is processed as a form is loading and there are errors in the script then it can break all subsequent client side processing. Since UI policies are processed after client scripts this can break all UI policies. Checking the browser console for client side errors can be very helpful in diagnosing why UI policies are not working as expected.

 

For this walk through let's assume that an OnLoad client script had been created for incidents called "Test Script" with the following code:

 

function onLoad() {
//Type appropriate comment here, and begin script below
var myMessage = test;
alert(myMessage);
}

 

In this case the myMessage variable is not defined correctly so it will throw an error in the java script window causing the client processing to fail including the UI scripts. Use the example below to find out why.

 

Example of Debugging a Client Side Error

This example assumes that you are using the Chrome browser but the other browsers have java script consoles. I recommend you use Chrome when it comes to debugging and troubleshooting as it is pretty simple and easy to use.

 

1) In Chrome, bring up the record that is not showing the UI policy changes you expected

 

2) Go to Tools > Javascript console in the Chrome menu. Depending on which version of Chrome you are on, it may be in a different location but usually clicking the wrench icon in the upper right will get you to this option.

 

3) Right click inside the console tab that opens and choose "Clear Console" so that you have a fresh start

console_clear.jpg

 

4) Reload the record that is having the issue. You can use Reload Form from the record header menu or right click on white space inside the record and choose "Reload Frame" from the Chrome menu.

 

5) Check for any red messages in the console. For the script example I provided above we would see the following:

console_error_sample.jpg

 

6) Click on the link that is directly across from the red error. In this case the link is incident.do:1313 in the screenshot.

 

7) This will take you to the line of Java Script that failed. where you will see the failing line directly above a red highlighted error as shown below:

 

console_error_sample2.jpg

 

8) Take a look at the script below the end of the current function:

 

addRenderEventLogged(onLoad_75d0114d47e1750067638d90f70935ab, 'onLoad Test Script');function onLoad_b5d0114d47e1750067638d90f70935ab() {

 

From this you can see that this was an onload script called "Test Script." You could now go to that client script and correct any errors found there. If you were not able to find the script name in the script window (perhaps due to a really long script) then you can also do a client script search where script contains the offending text. So in this case the client script filter would look like:

 

script contains myMessage

 

Client side scripts could also be coming from UI scripts or the script sections in UI policies so if you do not find the code from the error in the client scripts check those other places as well. The bottom line here is that when you have a form that is not behaving as you expect, take a moment to check the browser console. Often times it can provide clues to help you resolve your client side errors.

user interface.jpg

The Knowledge Base is kept current with frequent edits and additions. Find out what is new and stay up-to-date on the latest ServiceNow Knowledge Base articles by reviewing the weekly KB digest.

 

 

 

Recently added and updated articles on User Interface:

 

UI Policy


Create and manage the user interface with UI policies (Click to see all UI Policy Knowledge Base articles)

 

 

General


Find solutions to general ServiceNow UI related problems. (Click to see all General Knowledge Base articles)

 

 

User Interface (UI)


Customize, personalize and manage the way users view and interact with your organization or company’s interface using UI. (Click to see all User Interface Knowledge Base articles)

 

 

Visual Task Boards


Transform the navigation of lists and forms into an interactive graphical experience with Visual Task Boards (Click to see all Visual Task Board Knowledge Base articles)

 

If your requests are leaving you rejected without a reason, this is probably because the UI Policy Comment mandatory is not working properly in Eureka. This policy requires the approver to provide a reason for rejecting a request. When the state is changed to Rejected, a warning sign should immediately pop up alerting the user to fill out the Comments field:

 

 

Comments_mand_3.JPG

 

 

If the UI is able to bypass this and still reject your request, this may be because the Comments mandatory UI Policy script is not up to date.

 

To update the Comments mandatory UI Policy script:

 

  1. In the navigation filter, enter UI Policy.
  2. Open Comments mandatory, and click the Scripts tab.
  3. Replace these lines in the script:

 

In Execute if true, replace the line:

 

$("status.sysapproval_approver.comments").addClassName("mandatory");

 

Change to:

 

g_form.setMandatory('comments',true);

 

 

 

In Execute if false, replace the line:

 

$("status.sysapproval_approver.comments").removeClassName("mandatory");

 

Change to:

 

g_form.setMandatory('comments',false);

 

Comments_mand_image_2.JPG

 

You should now be able to view exactly why you have not been approved for your request.

 

For more information, see:

Approvals: Comments are not set to mandatory on rejection

Creating a UI Policy

"Everyone has a "risk muscle." You keep it in shape by trying new things. If you don't, it atrophies. Make a point of using it at least once a day."

-Roger von Oech

 

In a blog post a couple of months ago, I talked about ServiceNow system properties, specifically how to use them and how to create them. Our new Fuji product release contains 17 new and useful system properties that you should know about. Here's a bit about each.

 

System PropertyDescription

com.glide.loader.allow_along_column_names

Controls if header names in imported files can exceed 30 characters.

glide.discovery.software_sccm_managedDesignates if Discovery populates the CMDB with Windows software for computer CIs that are already managed by SCCM.
glide.email.inbound.calendar_behaviorSpecifies how the system stores calendar data.
glide.email.inbound.conver_html_line_attachment_referencesSpecifies whether to convert inbound email HTML so email images appear in the activity formater and email HTML body preview.
glide.email.outbound.max_body_bytesSets the maximum body size in bytes allowed per outbound email.
glide.import_set_insert_serialized_when_no_coalesceControls the processing of web service import sets that have no coalesce fields defined.
glide.knowman.search.articles_per_pageControls the maximum number of results that can appear on a single page when searching a knowledge base.
glide.knowman.search.pinned_articles_max_numberControls the maximum number of pinned articles that can appear on a single page when searching a knowledge base.
glide.rest.apis.disabledControls which REST APIs are available on the instance, along with glide.rest.apis.enabled.
glide.rest.apis.enabledControls which REST APIs are available on the instance, along with glide.rest.apis.disabled.
glide.rest.outbound.debugLogs all stages of outbound REST processing, including processing times.
glide.rest.outbound.ecc_response.timeoutThe maximum amount of time to wait for a response when sending an outbound REST message.
glide.rest.outbound.ecc_response.timeoutTruncates legend labels for left or right legend alignment for all chart sizes except large charts. Prevents shrinking of charts in case of long labels.
glide.chart.label.legend.truncate_to.largeTruncates legend labels for left or right legend alignment for all chart sizes except large charts. Prevents shrinking of charts in case of long labels.
glide.ui.list.detail_rowEnables or disables detail rows in lists.
glide.ui.personalize_form <--Enables or disables the form personalization feature.
glide.ui.personalize_form.role <--Determines which roles users must have to personalize forms.

 

In addition to new properties, 12 existing properties have been modified in the Fuji release:

 

System PropertyDescription and Fuji Changes
com.glide.email.max_body_bytesSets the maximum body size in bytes allowed per inbound email. Starting with the Fuji release, the new default value is 1048576.
com.snc.pa.chart_default_color_schemaDefault chart color scheme. For new ServiceNow instances starting with the Fuji release, the default value is Default UI14.
glide.email.reply_subject_prefixSpecifies the list of prefixed in the subject line that identify an email reply. Starting with the Fuji release, the new default value is: re:,aw:,r:,Accepted:,Tentative:,Declined:
glide.imprt_set_insert_serialized. <table name>Controls the processing of web service import sets. Starting with the Fuji release, this property replaces the glide.soap.import_set_insert_serialized. <table name> property.
glide.ldap.binary_attributesList of LDAP attributes that should be converted from binary format to encoded64 strings. Starting with the Fuji release, you can set this property for a MID Server to import BLOB data through a MID Server.
glide.pop3.reply_separatorsSpecifies the comma-separated list of separators that cause the instance to disregard everything below the text string in the message body. Starting with the Fuji release, unicode encoding is supported.
glide.report.use_charting_v2Enables or disables the new charting engine when the plugin is activated. Starting with the Fuji release, Report Charting v2 is automatically used on upgrading your ServiceNow instance. Therefore, the system property glide.report.use_charting_v2 is deprecated.
glide.report.new_home.heavySets the number for the top reports that take the most time to be generated. Starting with the Fuji release, these are displayed on Heavy tab of the report_admin's homepage.
glide.report.new_home.most_usedSets the number for the top most used reports. Starting with the Fuji release, these are displayed on Most used tab of the report_admin's homepage.
glide.report.new_home.unusedSets the number for unused reports. Starting with the Fuji release, these are displayed on the Unused tab of the report_admin's homepage.
glide.soap.import_set_insert_serialized. <table name>Controls the processing of web service inserts, including REST imports. Starting with the Fuji release, this property was replaced with import_set_insert_serialized.<table name>.
glide.soap.request_processing_timeoutSpecify the maximum number of seconds an inbound SOAP request has to finish processing before the connection times out. Starting with the Fuji release, the default is 60.

 

For more details about these new and changed system properties, see Available System Properties in the product documentation.


There are also some new and changed service catalog properties in the Fuji release. If you are interested in learning more about them, see Service Catalog Properties in the product documentation.


I recently found the need to create a fully custom UI page, that didn't involve using the framework page template. The user interface had to be dynamic and easy to identify problems, tasks and source code changes that we need to prioritize.

 

I put together a tree map visualization for our team that gives us an easy way to see:

Screen Shot 2015-01-22 at 1.42.43 PM.png

  • Source Code changes
  • Closed Problems
  • Open Incident Tasks

 

I put it up on a TV we have hanging over our team area at ServiceNow and it constantly refreshes with the latest changes so we always know how old something is and what category it is under. It looks really cool if I do say so myself.

 

I modeled the UI page after newsmap.jp . The size and color of the boxes represents the category and age of each item.

 

Let me know if this is something you are interested in getting more information on! Maybe I'll detail the project in another blog post and include the source code.

 

Making a UI page without using a framework page template

 

Before I even started to build the user interface, I knew I didn't want all of the platform html, javascript, and CSS wrapping that came with using the regular framework page template. I wanted this to be a very customized UI. In fact, I wanted total control over everything in the page source.

 

The Glide platform wraps every UI page in a standard html_page template which gives you everything from basic CSS to UI scripts. You can see that here:

 

UI page framework template servicenow.jpg

 

The key to building it on your own: ?sysparm_direct=true

 

To make a UI page without that page template you can add ?sysparm_direct=true when you request your UI page. In this case: instance.service-now.com/my_ui_page.do?sysparm_direct=true.

 

UI PAGE script custom.jpg

 

Easy enough yes? Let me know with a comment if you would like me to post a second blog to follow up with this that includes the source code!

Filter Blog

By date: By tag: