Skip navigation

Developer Community

7 Posts authored by: April McGehee Employee

yoda browser.jpeg

It can be frustrating trying to figure out which browsers are our friends and which browser are our foes. When working with the Geneva release, some of the application and features actually stray from general ServiceNow browser support.


With the release of Geneva there are new requirements for which browsers will be compatible with UI16, certain applications and features in this release will not work with some browsers so keep this in mind before you file a ticket with customer support! When in doubt switch browsers!


Browser support for System Properties in Geneva


This property enables or disables the display of a confirmation message when a form has unsaved changes and the user leaves the form in any way beside a submit ( like using the back arrow, any form button, etc.)

    • This property isn't supported in Safari. It could look something like this: leave page message.jpg


glide.ui.html.editor.toolbar.line1 and glide.ui.html.editor.toolbar.line2

These configure the editing toolbar for the HTMl fields. Of the available buttons, this is a comma separated list without any spaces. This property in fullscreen is not supported on Internet explorer


Browser support for Applications in Geneva

Financial Management

This application will not be supported by versions of Internet Explore prior to IE11. All other browsers are expected to work.


Legacy Business Service Management Map

There are more limitations when using internet explorer and the ServiceNow BSM map

  • To access the BSM map using IE 7 or * you must install Adobe Flash Player 10.1 or higher *(Note: Geneva will be the last release we will support IE 7 and 8 on for BSM maps)
  • You cannot export images from the map in IE 7
  • Map view images saved in a browser other than IE 8 might not display properly in Internet Explorer 8.
  • IE 7 can only display the version numbers of saved views and not the images.

Some of you might be experiencing the product defect where your reference fields that were made read-only through a UI Policy or a Client Script can still be edited using the look-up icon (aka magnifying glass). An example of this is may be you've made the User field on your incident form read only. Even though the field is greyed out, when you click on the magnifying glass, it allows you to edit the field. This can be risky business because all of your read-only fields are mostly read-only for security purposes.


There are two work-around paths for this issue:


  • Configure the reference field definition in the dictionary to read-only.
  • Add a read-only ACL to the reference field.



To configure the reference field definition in the dictionary to read-only.

  1. Right click on the field label.
  2. Select Configure Dictionary


  3. Check the read only box.


  4. Click Update


To add a read-only ACL to the reference field

  1. Elevate your privileges by clicking on the lock icon

    security admin.jpeg

  2. In the form access the context menu by right clicking in the header
  3. Select Configure > Security rules

    security rules.jpeg

  4. Create a New ACL



For more information see:

Reference fields set as readonly in Fuji still have working lookup magnifying glass

Seeing double? Double mobile icons that is. Users on a Eureka or Fuji release may be experiencing duplicate icons in their ServiceNow instances on mobile. Icons such as Help, Service Catalog, My Incidents, Contacts, Follow-up, and High Priority, may appear more than once when you are in the mobile UI. The issue is caused by the unintentional creation of duplicate records on the following tables:

  • sys_ui_home_favorite table
  • sys_ui_home_section table
  • label records


Duplicate icons.jpg

When users are removed the records are not getting cleaned up so duplicates are generated in the system.

You may experience upwards of 1,000 duplicate icons if things get messy. Now, that is a sight for sore eyes. Well I've got two troubleshooting paths that will help you remove the home favorite records, home section records, and label records.


To revert your icons to their unique buttons:

Delete the sys_ui_home_favorite records:

  1. Navigate to System Mobile UI > Home Page Favorites.
  2. Filter the list for records where the User field matches the affected user. The filtered list shows the user's favorites. There may be multiple copies of each favorite.
  3. Delete the extra records.

Delete the sys_ui_home_section records:

  1. Navigate to System Mobile UI > Home Page Sections.
  2. Filter the list for records where the User field matches the affected user. The filtered list shows the user's sections. There may be multiple copies of each section.
  3. Delete the extra records.

Delete the label records:

  1. Navigate to System Definition > Tags. (Tags were originally called labels. While the terminology has changed, these records are still stored on the "label" table).
  2. Filter the list for records where the Owner field matches the affected user. The filtered list shows the user's tags. There may be multiple copies of each tag.
  3. Delete the extra records.


This step can also be done by simply running a script in the Scripts- Background.

(function() {
deleteDuplicates('sys_ui_home_section', ['user', 'table', 'label']);
 deleteDuplicates('sys_ui_home_favorite', ['user', 'table', 'label', 'icon']);
 deleteDuplicates('label', ['owner', 'name', 'short_description', 'background_color', 'color', 'icon']);
// table :: string, fields :: [string]
 function deleteDuplicates(table, fields) {
 var current = new GlideRecord(table),
 prior = new GlideRecord(table);
// ordering will not work on records created by snc hop access due to missing sys_user records
 current.addQuery('sys_created_by', 'DOES NOT CONTAIN', '@snc');
 prior.addQuery('sys_created_by', 'DOES NOT CONTAIN', '@snc');
// ditch if there are no fields
 if(fields.length < 1) {
 gs.log('deleteDuplicates requires at least one field');
 return false;

// order by array of fields passed in
 for(i = 0; i < fields.length; i++) {


// bail if the query returns nothing
 if(!current.hasNext()) {
 gs.log('no records returned');
 return true;
// current will always be one ahead of prior
// loop through...
 var dups = 0;
 while(current._next() && prior._next()) {
 var i;
 // ...and compare adjacent records
 for(i = 0; i < fields.length; i++) {
 if( current.getValue(fields[i]) != prior.getValue(fields[i]) ) break;
 if(i == fields.length) {
 //gs.log('duplicate detected: current[' + current.sys_id + '] prior[' + prior.sys_id + ']');
 //gs.log('deleting [' + prior.sys_id + ']');

gs.log("Removed " + dups + " duplicates from " + table);

return true;




This business rule can also be loaded into the affected instance as an XML file to prevent a re-occurrence of the issue until a fix is released. You can download the file from here.


To Import records as XML data:

  1. Sign in as an admin to the instance that should receive the data.
  2. Navigate to any list in the system.
    Any list can be used because the XML file contains the destination table name for the records.
  3. Right-click the list header and select Import XML.
  4. In the import screen, click Choose File and select the previously exported XML file.


  5. Click Upload.


Now that you've fixed your duplicate icons you can cancel that eye appointment use the mobile app with ease!

Are you having problems with your Mobile UI policies, maybe you have some fields showing that should be hidden or maybe one of your read-only fields is editable? This is where troubleshooting your mobile UI policies will come in handy. UI Policies are rules that apply to forms that dynamically change form information or the form itself. These are great becasue they allow you to add controls without having to write any scripts.


We use UI Policies to set fields on a form to:

  • Optional or Mandatory
  • Visible or Hidden
  • Editable or Read-only


When troubleshooting your Mobile UI Policies there are 3 plans of action we recommend you take:

  1. Confirm UI Policy scripts are set to run in the mobile UI
  2. Make sure any client side scripts are compliant with the mobile UI
  3. Make sure any other element aren’t causing the change


Confirm your scripts are running in the Mobile UI

The Run Scripts in UI Type field was added to UI Policy records when the Mobile UI was launched and it provides the options: Desktop, Mobile, or both. But you probably won’t automatically see this field because it isn’t defaulted to appear on the UI policy form so you’ll need to configure your form by:

  1. Right-click the form header and select the appropriate option for your version:
    • Fuji or later: Configure > Form Layout
    • Eureka or earlier: Personalize > Form Layoutpersonalizeform.jpg
  2. Using the slushbucket, select the Run Scripts in UI Type from the available box and add it to the Selected box sluchbucket.jpg
  3. Click Save
  4. Select the UI Policy record
  5. Change the Run Scripts in UI Type to either Mobile or Both




Confirm client side script is compliant with the Mobile UI

Because there are many limitations in the mobile interface, you may be required to make changes to any custom scripts. Scripts using asynchronous calls or unsupported methods may break down, and prevent forms from working the way you intended. This is important for scripts within your UI Policies as well as any other client side scripts that execute on the same form. When client side errors are triggered on a form, scripts stop executing. So if there's a faulty client script executing on the form before your UI policy, then it can potentially stop your UI policies from running.


You should Debug the Mobile UI from your desktop to make sure the client side scripts are compliant with the mobile user interface and to track down any errors is using you browser's developer console


Make sure other elements aren't causing changes

UI Polices are the recommended method to make a field mandatory, visible and conditionally read only but these aren't the only way to control this. Client scripts execute before UI policies so they should override these calls, which can explain why a field is invisible after you've disabled a UI policy that hides it.


Check the client scripts running on the form for any:

  • setVisible
  • setMandatory
  • setReadOnly


These might be conflicting with your policies. It should also be noted that a field could be made mandatory at the dictionary level by using the checkbox on the field's dictionary entry. Also be aware we have a known error related to this if this step still isn't working for you see [Mobile UI] UI Policy executes before client scripts.


Hopefully one of these steps will helps you identify what is causing your UI Policies errors in the Mobile UI. If you need more information refer to the Smartphone Interface and Creating UI Policies pages.

Mobile means more than just being on-the-go — it's the ability to get more work done while moving freely about the office. The mobile user interface and the tablet user interface offer different views. It’s very important to understand the capabilities as well as the limitations you will see while using ServiceNow out of the default view and on your mobile devices (both smartphone and tablet).


First, let's start with what the default view actually is. This is the view that is given to all forms and lists if no other view is specified. For example, you might have an incident form with a default view that has 10 or more different fields that are editable, but this isn't very aesthetically pleasing for mobile users. Creating a mobile view can allow you to select the fields that are most important to you and your organization, making forms more user friendly.


Incident form.jpg

Mobile incident form new.jpg


The mobile view is the default view for forms and list layouts on all mobile and tablet devices. Mobile views need to be set up for all tables or the default view will show on your mobile devices but keep in mind there are unsupported features in the mobile view. Creating a mobile view allows you to do away with unexpected behavior for mobile users by removing the unsupported features you have in your default views. A good example of this is certain variable types are not compatible with the mobile view. Removing the fields that have these unsupported variables is a good practice for ensuring users don't come across any errors.


Important things to remember about the Desktop View vs. Mobile View:

  • Other views for forms are not available (the only exception is when you don’t set up your mobile view so the default view is used).
  • Additional custom views cannot be created.
  • Some features are unsupported (HTML fields, chat, VTB, and embedded lists, etc.).


These UI limitations are built into the mobile UI to limit the amount of information loaded due to the lack of screen real estate. The mobile view allows you to only see the first section on a form. You do have the ability to add additional sections to your form, though it should be noted that this could cause some errors or the inability to save if you do so. This is because you won’t be able to see the additional sections. If you have a mandatory field, you won’t be able to edit it and save. This can also happen if you’re using a default view and there’s a mandatory field on a section other than the main one.


If you don’t want to run into any of these pesky problems, it’s extremely important to set up views for all of the tables you commonly access on your mobile devices.


The UI limitations are also due to limited hardware on mobile devices, as well as making sure we have a set of features that will function on multiple mobile platforms.


The tablet user interface shadows the same rules as mobile. The mobile view is used if it’s been set up and the default view is used otherwise. The big difference between the mobile and tablet views is that the tablet shows more form sections! Don’t get too excited here because the mobile view and tablet view are the same thing. Make sure you still aren’t putting any of those mandatory fields in these additional sections because your mobile users will get an error and won’t be able to save.


If you don’t already know about the favorites functionality of the ServiceNow mobile UI or you just haven’t gotten around to setting them up, you should because it will save you a ton of time and make you more efficient.


The mobile user interface Favorites feature is a list of icons that appears on your mobile homepage. These can be used to create a shortcut to any record, list, form or catalog item. When users log into the mobile UI for the first time, they’ll see some instance generated defaults that can be deleted or modified without affecting any other users. This means that you can skip the filtering and breadcrumbing and go straight to the record you want. If it is a form or catalog item you view often, this can save a lot of hassle much like having your mom and dad on speed dial.


Favorites make accessing your frequently used customized lists easier. For example, let's say you have a list you use on a regular basis and every time you log back into your instance you have to reapply your filters. This can be really frustrating (especially if you have big ol' meaty fingers), using a mobile favorite can eliminate this process. Maybe you also have catalog items you use frequently or a specific record you need to keep an eye on, both of these are also great candidates for your mobile interface favorites list. The easiest way to think about it is like bookmarking and creating shortcuts on your desktop for the sites you use the most often, but in this case they are ServiceNow items.


How to setup your Favorites on your Mobile device:

  1. Browse to the desired record, list, form, or catalog item.
  2. Tap and hold the homepage button on the lower left of the screen. home icon.png
  3. A pop-up will appear where the Title, Color, and Icon of the new favorite can be set.
  4. Pick a color, name your favorite, and click save.

home favorites.png


Setting up default Mobile home page favorites

Your favorites can also be accessed directly through your instance by navigating to System Mobile UI → Home Page Favorites. This list records the favorites for all users. You may notice some records with a blank user field, these are default favorites given to all users.


You can create default favorites for your users by using the process above, then clearing out the user field in the System Mobile UI → Home Page Favorites settings in your desktop UI. You can also manually add favorites here by clicking the New button. Creating a new default favorite won’t automatically push this to existing users. Though you can still manually add these favorites for existing users. This is done by either going to the record and using the Insert to duplicate the record, then adding the users name. Or you can delete the existing users current favorites which will reset them to new default favorites like they're a new user again.


Trying to add favorites to multiple accounts can be a difficult and time consuming process, which is why we don't recommend it. The favorites functionality is designed to set-up customization for individual user by the user. Not everyone accesses the same record, form, or list item throughout a 200-person company.


Setting up your Mobile UI favorites is quick and easy. Taking five minutes to set up your customizations can save you the pain and time of going in a reapplying those pesky filters and searching through your service catalog to find that frequently used item. Now you can use that time for other things, such as a quick game of ping-pong with the co-workers or having a walking a meeting with your team mate.

The Time Ago format is a new UI feature of Fuji that makes reviewing incidents in a related list quicker and easier to access. The "Time Ago" feature can be used anywhere a date/time format is used in ServiceNow. "Time Ago" is one of three ways to represent date and time when reviewing data in your instance. You can set the date/time for "Time Ago," "Calendar date" or even both. A fourth option, "Compact list date/time" is also available and does not show date values for the current year or seconds for the time (does not work if "Time Ago" is enabled).


The "Time Ago" feature allows you to view dates as "6 days ago" or "31 minutes ago." Rather than telling you when the incident was submitted, it will tell you how much time has passed. This gives you a quick look at how long it has been since a user has been helped. Sorting by "Time Ago" allows you to easily see what issues need to be prioritized based on how long ago it was submitted


INT box.jpg

If you are on Eureka or a version prior to Fuji Patch 5, you may be experiencing a problem with setting your date/time to “time ago” or “both” in related lists to the correct time. This error is occurring because the “Time ago” option is calculated based on your system’s current time. You can fix this problem by changing your system’s time zone to match the ServiceNow profile time zone.


To change your ServiceNow System timezone:

    1. Navigate to System Properties > System.
    2. Locate the property called System timezone.
    3. Type a time zone in the field and click Save. This becomes the system time zone. The new time zone automatically cascades to all users who do not already have a specified time zone. If a user selects a different time zone or if the administrator selects a different time zone for them, the user is assigned the selected time zone and does not use the system time zone anymore.


To edit your profile's timezone:

      1. Navigate to Self-Service > My Profile
      2. Locate the property called Time zone.
      3. Select your timezone and Save.


Subscribe to PRB623943: Setting "Time Ago" in related list does not display correct time to get email updates when information in the workaround, seen in, and fixed in sections change.

Filter Blog

By date: By tag: