Skip navigation

Developer Community

7 Posts authored by: John Armstrong Employee

This list represents the Mobile UI Known Errors with the highest number of incidents associated with them.  If you are affected by any of these incidents.  Please take advantage of the new subscribe feature to stay informed of any updates or fixes for that KE. The majority of these known issues are found in the Eureka and Fuji Releases, and a few in Dublin.

 

Please note, some articles may require you to log in to HI. See this link for information on how to  subscribe to Known Error articles.

 

 

TitleNumberDescription
Mobile App does not work with SAML on EurekaKB0551083[Mobile App] When a customer is upgraded to Eureka and tries to use the IOS mobile app with SAML, the application hangs with no indication of why it is failing. The mobile app is hanging because it did not trust the customer's certificate.
Smartphone Mobile UI - Word wrap does not work for description fieldsKB0551128In the mobile UI, word wrap does not work for description fields.
g_form.getReference does not work on Mobile UIKB0551077

When using g_form.getReference, nothing happens, as there is an error in the background:

"Could not load onChange client script 'script_name': SyntaxError: Unexpected token"

Issues with advanced reference qualifiers in the mobile user interfaceKB0541017Cannot set field values on redirect to a form for the mobile UI. Also cannot use script include calls in advanced reference qualifiers for the mobile UI.
Default value for Select Box variable is ignored in mobile service catalogKB0551088When accessing Service Catalogs within the Mobile UI, the default value for the select box variables is ignored.
The action.setRedirectURL does not work in mobile UI actionsKB0533278[Dublin] action.setRedirectURL doesn't work in Mobile UI Actions
Mobile interface showing duplicate icons for [sys_ui_home_favorite], [sys_ui_home_section] and [label] records for some usersKB0546754Mobile interface showing the duplicate icons for [sys_ui_home_favorite], [sys_ui_home_section] and [label] records for some users.
Entering text in to the password field on the mobile login page causes the screen to blank on iPhoneKB0551129Unchecking the "Remember Me" option on the mobile login screen and then entering text into the password field causes the screen to go blank on the iPhone.
Cannot scroll Incident form on iPad in portrait modeKB0551082[Tablet] The user cannot scroll horizontally on the incident form on iOS. The form does not resize correctly on the iPad.

 

The majority of these issues have been fixed in available releases, which are specified in the associated Knowledge Base articles.  If you are experiencing any of the above issues that are not yet fixed, you can now subscribe to Known Error articles to be notified of any changes and updates made to the "fixed in," "seen in," "workaround" and "steps to reproduce" sections.

 

If you're experiencing a product issue not covered in Known Error or Knowledge Base articles, please post the bug to the community.  Our members and internal employees will do our best to offer guidance and document as necessary.

Sometimes your Client Scripts, UI Policies, and other client side scripting doesn’t work as expected.  This can be especially frustrating when you don’t have access to debugging tools like your browser’s developer console, which allows you to see any errors being thrown and what's triggering them.  Fortunately there are a number of ways to see what’s going on under the hood in the mobile UI.  Listed below are a few ways to see what’s happening in your scripts.


Accessing the Mobile and Tablet UI from a Desktop Browser

Most of the time, an issue occurring on your mobile UI will be reproducible by using the Mobile UI on your desktop browser.  Using the mobile UI on a desktop browser will allow you to find any potential issues you may encounter within the mobile UI.  This is also useful as it allows troubleshooting on a full sized monitor and keyboard, as well as eliminating the need for a physical mobile device when testing.  This is also the simplest way to see any client side errors being generated while using the mobile UI.  Since we’re on a desktop browser, you have access to the developer console and tools that are available in all major browsers.

 

The mobile and tablet UI can be accessed by using the following URLs:

  • Mobile UI:  https://<instance_name>.service-now.com/$m.do
  • Tablet UI:  https://<instance_name>.service-now.com/$tablet.do

 

At some point, you’re going to want your desktop UI back.  The following link will get you back from either mobile or tablet.

Desktop UI:  https://<instance_name>.service-now.com?sysparm_device=doctype

 

While the look and feel won’t be exactly the same, you will be able to interact with the instance in the same way you would on a mobile device.  Right-clicking can be used to simulate a “tap and hold” action.

 

A Note on Impersonation

Impersonation options are only visible in the desktop UI.  This does not mean that will not be able to impersonate, you’ll just need to do so before switching to an alternate UI.  Impersonate as normal, then browse to one of the above links.  Alternately, you can impersonate on a physical mobile device by first using the desktop link, impersonating, and then using one of the mobile links to get back.  While doing this does allow you to see the desktop UI on a mobile device, it’s not recommended that you do so for anything other than impersonation.  The full desktop UI is not designed to run on the more limited mobile hardware, and is not supported.

 

 

The Developer Console

Now that you're in your UI of choice, you can use the developer console to check for any client side errors you may be getting.  You may already be familiar with your browser’s dev console, but if not, here’s how to find it on our supported browsers.

 

Chrome

PC:  Click ≣ → More Tools → Developer tools, or press Control + Shift + I

Mac:  Click ≣ → More Tools → Developer tools, or press Option + ⌘ + J

 

Firefox

PC and Mac:  Click ≣ → Developer → Browser Console


Internet Explorer

Press the F12 key or Click "F12 Developer Tools” under the Tools menu

 

Opera

From the menu, open Tools → Advanced → Developer tools

 

 

Mobile Device Emulation

If you’d prefer a closer match for the appearance of a mobile device for testing.  There are a couple of options that can be used to more closely emulate a mobile device.

 

Chrome (Mac and PC)

 

Chrome has mobile device emulation built into it’s developer tools.  This  This can be accessed using the following steps:

1. Access the developer tools:

     In Windows: Control + Shift + I

     In Mac: Press option + ⌘

2. Press escape, then select the “Emulation” tab.

3. Here there are a number of options, but the “Model” selector will allow you to quickly emulate a number of devices.

 

XCode (Mac Users)

XCode is an IDE suite for OSX and iOS that includes an iOS simulator. Due to an issue with the way XCode handles it’s user string, this option may not work on Eureka Instances, but will perform as expected in Fuji, as well as instances still using the legacy mobile UI.

 

 

Debugging a Physical Mobile Device with a Desktop Computer.

It’s rare, but you at some point encounter an issue that is only reproducible on a physical mobile device.  Fortunately, iPad, iPhone, and Android mobile devices can be connected to a desktop via a USB cable, using the desktop browser’s console tools to troubleshoot issues.

 

iOS

iOS devices can be connected to a PC/Laptop and debugged with the Safari browser.  Unfortunately  was introduced in Safari 6, after Apple stopped updating Safari on Windows.  So, you’ll need a mac using OSX 10.7.4 or later to do this.

  1. Connect your iPhone / iPad to your computer using a USB cable.
  2. Open Safari on your Mac
  3. Browse to Safari → Preferences
  4. Click on the Advanced tab
  5. Check the checkbox next to “Show Develop menu in menu bar"
  6. On your iPhone, open your browser and log onto your instance.
  7. On your Mac, Click on Develop → iPhone → <site name>

This will open the Web Inspector, while will allow you to inspect elements of the page, as well as view console logs.


Android

Android devices can also be connected to PC/Laptop via USB and debugged using the Chrome desktop browser

 

 

The above information should help identify mobile problems you encounter. Finding where specifically an issue is occurring will help speed the process troubleshooting any client side issues you run into while developing your mobile and tablet UI.

If you’re using the Mobile UI for the first time, you'll want to make sure your custom scripts function the way you expect as part of your testing process.  There are some limitations in the Mobile UI that may require changes in any custom created scripts, or scripts that have been modified from their out of box versions.


Where to Look

The differences between the two UIs are on the client side (scripts running on your browser as opposed to the server).  The following elements make use of client side scripting, and may need changes to work as expected in the Mobile UI.

 

  • Client Scripts (Including Catalog Client Scripts)
  • UI Policies
  • Navigator Modules
  • UI Actions

 

Note that the out of box versions of these elements have either been updated to work in the Mobile UI, or marked to only run in the UI in which they function.  When you start using the Mobile UI, you'll be looking for customized  elements, which won't necessarily be compatible.

 

 

What to Look For

The first thing we need to do is find deprecated methods, unsupported methods,  and unsupported browser objects in the existing scripts.

 

Deprecated Methods

  • getControl
  • getElement
  • getFormElement
  • getOption

Unsupported Methods

  • showRelatedList
  • hideRelatedList
  • showRelatedLists
  • hideRelatedLists
  • flash
  • getSections
  • enableAttachments
  • disableAttachments
  • setReadonly (Note that setReadOnly is available)
  • getParameter

Unsupported Browser Objects

  • Window
  • jQuery or Prototype ($, $j, or $$)
  • Document

 

Multiple Functions

The Mobile UI expects a single function within a client script.  Each Client script contains an onChange, onCellEdit, onLoad, or onSubmit function, depending on it's type.  All script in a client script needs to be contained within this function.  Additional functions are allowed, as long as they're contained within the top level script.

 


What To Do About It

Deprecated Methods

Deprecated methods are not available in the Mobile UI, but their functionality has been replaced with new methods.  Unsupported Methods and Objects do not have replacement methods, and should not be used in the Mobile UI.  For example, while getControl cannot be used, methods like g_form.hasField g_form.addDecoration can be used to achieve the same goals.

 

The complete list of methods added for use in the Mobile UI can be found in the Mobile GlideForm API Reference in the wiki.

 

Unsupported Methods

Unsupported are method that cannot be used due to the limitations of the Mobile UI.  When run in mobile, these methods will perform no action, so nothing will happen when they are run.  Unlike the deprecated methods, there are not mobile equivalents of these methods.

 

Unsupported Objects

Direct access to the Document and HTML elements are not allowed in the Mobile UI, as a result, the objects listed above are not supported.  Attempts to get values from these objects will return values of 'undefined'.

 

Multiple Functions

Functions of than the onLoad function (or whichever one is used) can be created, but need to be contained within the top level function.

 

Specifying Desktop or Mobile UI (or Both)

While the Mobile UI has it's own Navigator Modules and UI Actions, it shares it’s Client Scripts and UI Policies with the Desktop UI.  Fortunately, you can specify which UI Type these execute in.  You can have these execute in both UI types, which will save you time when a script is valid in both Mobile and Desktop.   You can also set scripts only to run in one UI or the other.  That way you can have a script that uses the full functionality of the Desktop UI, and maintain a separate script for the Mobile UI that works within Mobile's limitations.

 

Client Scripts

Client scripts have a field called 'UI Type' which can be set to Desktop, Mobile, or Both.


UI Policies

UI Policies have a field called "Run scripts in UI type" which can be set to Desktop, Mobile, or Both.

 

 

Let's Take an example script that has been made usable in the Mobile UI.  The Example we're using is the out of box client script  "(BP) Set Location to User."  This script is triggered when the Caller field on the incident form is changed.  It checks the for the new Caller's location, and updates the Location field on the incident form to match.

 

This has already been fixed in Dublin and up, but here's how it originally looked in Calgary, back before the Mobile UI was introduced:

 

function onChange(control, oldValue, newValue, isLoading) {
   if (isLoading)
      return;

   if (newValue == '') {
      g_form.setValue('location', '');
      return;
   }

   if (!g_form.getControl('location'))
      return;

   var caller = g_form.getReference('caller_id', setLocation);
}

function setLocation(caller) {
   if (caller)
       g_form.setValue('location', caller.location);
}






 

 

There are a few things that needed to be changed to make this compatible with the Mobile UI.  Here's what we did.

 

 

Replace getControl

Our First issue is on line 10, we check to see if the location field is on the form using getControl.  This is one of those methods we can't use in mobile.  Fortunately there's a working alternate called hasField we can use instead.  So, we need to change line as shown below.  (Note that in instances Fuji, this has already been done).

 

From:

if (!g_form.getControl('location'))






 

To:

if (!g_form.hasField('location'))






 

Make getReference calls Asynchronous

The next issue is on lines 13-19.  On line 13, the script uses getReference to get the value of the caller_id field.  It a function called setLocation as a callback function.  This is good idea in general, but especially important in mobile, where it is required. The function itself is on lines 16-19.

 

While the asynchronous call is already handled, there's an issue, which is that the setLocation function is outside the onChange function, which is another thing that we can't do in Mobile.  The easiest solution is to just copy the setLocation function into the onChange function, so it appears after the place where it's called on line 13, but before the bracket that ends the onChange function on line 14.

 

Change the UI Type

Now that we've got a compatible script, we need to change the UI Type field.  By default, it's set to "Desktop," but now that we've made our changes we can set it to "Both" so it will run on either UI.

 

Here's how the script looks with the changes in place:

 

function onChange(control, oldValue, newValue, isLoading) {
    if (isLoading)
        return;

    if (newValue == '') {
        g_form.setValue('location', '');
        return;
    }

    if (!g_form.hasField('location'))
        return;

    var caller = g_form.getReference('caller_id', setLocation);



    function setLocation(caller) {
        if (caller)
            g_form.setValue('location', caller.location);
    }
}






This is a simple example, but Illustrates a lot of the above points.  The links below provide additional information and instruction, as well as a few documented problems to be aware of.

 

 

Further Reading

Product Documentation

 

Knowledge Base

  • KB0551285:  Using Asynchronous Calls in Mobile UI Scripting
  • KB0551074:  Mobile View Basics
  • KB0549860:  Client Script or UI Policy is not running.
  • KB0551212:  Mobile UI limitations

 

Community

One of the important differences to note about scripting in the Mobile UI is that synchronous javascript or glideRecord calls are not allowed.  In practice, it's pretty easy to script around, and the product documentation provides examples why this is done, and how it works.

 

All Javascript run on a browser shares a single thread, meaning everything that executes has to wait in line.  If something in a script takes a second or two to complete, your browser needs to wait.  If this goes on long enough, it may seem like your browser is hung.

 

The way to get around this is to make an Asynchronous call.  This allows us to move requests we've made to another thread.  Your browser has a pool of threads it uses specifically for asynchronous calls like this.  Meanwhile, your browser can move on to it's next task.  When the request is finished, a callback function is triggered to handle the results of the request.  Here's an example of the mobile platform not allowing synchronous JavaScript calls. The g_form.getReference() method must now have the callback parameter defined.

 

 

var userName = g_form.getReference('assigned_to').user_name;
g_form.setValue('u_assigned_user_name', userName);

 

 

Above, we're making a g_form.getReference  call to get the a user name based on the contents of the assigned_to field.  Once that's done, we're setting the u_assigned_user_name field to that value.  The problem with this is that we're waiting for that getReference call to process.  This might only be a fraction of a second, but it might go a bit longer. But, you might have more that one of these in your script, and several scripts that execute on your form.   This can add up!

 

Here's the asynchronous version:

 

 

g_form.getReference('assigned_to', function(gr) {
     g_form.setValue('u_assigned_user_name', gr.user_name);
});

 

 

Here, we've added a second argument to getReference.  This second argument is an anonymous function, and has an argument called gr, which stores the results of our getReference call.  Within that function, a setValue call assigns a value to u_assigned_user_name, just like the second line of our first example.  This function will execute whenever the getReference call finishes.  Since this is now in another thread, the browser can move on to other things.

 

 

Further Reading

Mobile Client GlideForm (g_form) Scripting

Client Script Best Practices

Mobile GlideForm (g_form) API Reference

As you may have noticed when navigating the smartphone mobile interface, the URL format is significantly different from what’s used in the Desktop and Tablet UI.  This is important for a few reasons.  In additional to being able to identify where you're looking on the instance using the URL, this information can also be used to create links and modules specifically for use in the Mobile UI, as will be shown in the examples below.  I hope to better explain the URL structure, including information on how to apply filter options and auto-populate field data using the URL. Filter options and field data in the URL can be helpful both when viewing existing URLs to understand their content or in creating your own URLs to use in scripts.

 

 

This is the basic schema for a mobile URL:

https://<base URL>/$m.do#/<list/form>/<table>/q:<query>^<query>^EQ

 

Elements of a mobile URL include:

$m.do#This is where the mobile interface is specified.  Browsing to $m.do in any supported browser will display the Mobile UI.
<list/form>Using either “list” or “form” here will specify whether a list of form will be displayed by the URL.
<table>This is the table being accessed, such as “incident” or “change_request."
q:<query>^This is how queries are created.  These begin with q: and are separated by the carat (^) symbol. Examples below:
  • /$m.do#/list/incident: displays a list of all incidents
  • /$m.do#/list/incident/q:active=true: displays a list of all incidents where the “active" field is true
  • /$m.do#/!list/incident/q:active=true^priority=1:  displays a list of all incidents where the “active" field is true and the priority field is 1.
  • /$m.do#/form/incident/d71da88ac0a801670061eabfe4b28f77Displays the form for the incident record where the sys ID matches the sys ID “d71da88ac0a801670061eabfe4b28f77”.  As with desktop URLs, form URLs in mobile use the record’s sys ID.
  • /$m.do#/form/incident/-1:  As with the Desktop UI, a -1 can be used in place of a sys ID to create a new record.
^EQThe EQ denotes the end of the Query.

 

 

Generating a Record with a URL Link

Forms in mobile can be displayed with pre-populated fields, as they can in the desktop UI.  This can be useful, for example, when creating modules for your mobile UI.  For, example, take the "Create New" mobile module used to create new incidents in the mobile UI. 

 

You can find this on your instance by navigating to System Mobile UI → Navigator Apps, then selecting the "Incident" Application Menu.  In the Modules related list you'll see "Create New"

 

If you look at the Path field for this item, you'll see the URL used to create a new incident in the Mobile UI.

 

form/incident/-1

 

 

Let's say, for example, we wanted to create a module that created new incidents with pre-populated priority, short description, and assignment group.  This is an example URL we could use to accomplish that:

 

/$m.do#/form/incident/-1/priority=2^short_description=MY TEST^assignment_group=d625dccec0a8016700a222a0f7900d06

 

 

Let me break this down for you a bit:

/$m.do#/form/incident/-1/As with the desktop URL navigation, using a sys_id of -1 directs the instance to a new record form.
priority=2This sets the priority to "2 - High."  When setting values for choices, the value (2) is used rather than the label.
^As with list filters, each field is separated by a caret(^) symbol.
short_description=MY TESTThis sets the short description to "MY TEST."  Spaces are allowed, but characters that have meaning within a URL, for example a " \ " character, will not work and will break the URL.
assignment_group=d625dccec0a8016700a222a0f7900d06This last field is a reference field.  In this case, we're setting the Assignment Group to "Service Desk."  For a reference field like this one, we use the sys_id of the records being referenced, which, in this case is the is a sys_user_group record.

 

 

An Example of Use within ServiceNow

For an example of when something like this can be helpful, let’s take a look at "Create Incident” record producer.  On this record producer is a script that first detects whether or not the scripts is being run in the Mobile UI, and then provides an appropriate link based on that information.

 

var isMobile = GlideMobileExtensions.getDeviceType() == 'm';

var link = isMobile ? '#/list/incident/q:active=true%5Ecaller_id=javascript:gs.user_id()%5EEQ' : 'home.do';

 

In the above script, when the Mobile UI is detected, a link using the URL formatting for mobile is selected. This will link to a list of active incidents where the Caller ID field matches the current user:

generate record.jpeg

 

As we've seen above, knowing the URL format for mobile will allow you to create links and modules for use in the Mobile UI.  With this information, you'll be able to create content on your instance specifically for mobile use, and provide a better experience for your mobile users.

 

A quick note about javascript used within mobile links:  While the example above works as expected, the Mobile UI does not support dynamic urls which direct to a form (specific record).

Being able to debug your scripts on the desktop can save a lot of time. Troubleshooting the mobile user interface on a desktop gives you access to your desktop’s full sized keyboard and monitor, and browser's developer tools. Using your desktop to debug your mobile interface issues makes troubleshooting easier in situations where a physical mobile device is not available to you. I will show you how to access the supported Mobile and Tablet user interface on a desktop browser, as well as some information on tools that can be used to help with the troubleshooting process.

 

 

Using the Mobile UI on a Desktop Browser

Both the Mobile and Tablet UI can be accessed on any supported desktop browser. Going through the steps on a desktop will give you all of the functionalities of the desktop but on the limited interface of the device. Sounds like a strange approach? Not quite. Using your company's mobile interface on a desktop can help find any holes in functionality or troubleshoot issues that arise.

Mobile+on+Desktop.jpg

    Above:  The ServiceNow Mobile UI within a Chrome desktop browser

 

 

You can access the mobile device interface by using these URLs, just add your instance name where indicated:

  • If you want the smartphone mobile UI add /$m.do to the end of your instance name: https://<instance_name>.service-now.com/$m.do
  • If you want the tablet interface, you add $tablet.do to the end: https://<instance_name>.service-now.com/$tablet.do

 

Once you're in either of these alternate UIs, you can get back to the desktop UI by using the sysparm_device=doctype, like this:

https://<instance_name>.service-now.com?sysparm_device=doctype

 

While the look and feel won't be exactly the same, you will be able to interact with the instance in the same way you would on a mobile device.  Right-clicking can be used to simulate a 'tap and hold' action.

 

 

Mobile Device Emulation

There are a couple of options that can be used to more closely model a smartphone or tablet's appearance and behavior. This can be important when you want an accurate representation of how something will look on a mobile device.  These options allow you to do things like set the display to a phone's native resolution, or to jump between landscape and portrait format without manually resizing you browser window.  Chrome and Xcode provide developer tools for Macs and PCs to emulate different devices. Using these options provides a more accurate representation of how your changes will appear on your device of choice.

 

debugging mobile.jpg

Above:  The XCode iOS Simulator

 

 

Chrome (Mac and PC)

Chrome has mobile device emulation built into its developer tools. This can be accessed using the following steps:

  1. Access the developer tools:
    1. In Windows: Control + Shift + I
    2. In Mac: Press option + ⌘ + J
  2. Press escape, then select the “Emulation” tab.
  3. Here there are a number of options, but the 'Model' selector will allow you to quickly emulate a number of devices.

Chrome Mobile Emulator.png

Above:  The Chrome Developer Tools window, with the Emulation tab shown

 

 

XCode (Mac Users)

XCode is an IDE suite for OSX and iOS that includes an iOS simulator. XCode can be used to simulate a variety of iPhone and iPad devices.  Due to an issue with the way XCode handles its user string, this option may not work on Eureka Instances, but will perform as expected in Fuji, as well as instances still using the legacy mobile UI. Details on the use of this tool can be found on Apple’s developer site.

 

 

Debugging a Physical Mobile Device with a Desktop Computer (Mac Only).

In some rare cases, you'll run into an issue that isn't reproducible on the desktop browser, but does occur on your phone or tablet.  In these cases, iOS devices can be connected to a PC/Laptop and debugged with the Safari browser's Web Inspector.  Unfortunately  was introduced in Safari 6, after Apple stopped updating Safari on Windows.  So, you’ll need a mac using OSX 10.7.4 or later to do this.

 

  1. Connect your iPhone / iPad to your computer using a USB cable.
  2. Open Safari on your Mac
  3. Browse to Safari → Preferences
  4. Click on the Advanced tab
  5. Check the checkbox next to “Show Develop menu in menu bar"
  6. On your iPhone, open your browser and log onto your instance.
  7. On your Mac, Click on Develop → iPhone → <site name>

 

This will open the Web Inspector, while will allow you to inspect elements of the page, as well as view console logs.

Safari Develop Tools.png

Above:  The Safari Develop Menu.  With the connected iPhone highlighted

 

In the image above, you can see the connected iPhone listed in the Develop Menu.  Note that just above it is the iOS Simulator mentioned earlier.  If you're using the Simulator, you can also use Safari’s developer tools to debug the iOS simulator using the same steps.

 

debugging on mobile.jpg

  Above:  The iOS Simulator alongside the Safari Web Inspector

 

More information see Web Inspector.

 

The above information should allow you to access the Mobile and Tablet UI on your desktop, giving you the ability to test and debug on your instance.  This should speed up your development process and make it much easier to identify and correct client side issues that come up during the creation of new content for mobile.

 

Related Articles

 

KB0549598:  Known Error:  console.log statements can cause errors in Internet Explorer 9 if the browser console is not open.

KB0546854:  Info on troubleshooting UI Policies.  Examples include the use of the developer console to find an error.

KB0547069:  Determining if there are client script errors on your instance.

KB0550574:  Troubleshooting form issues

Using the Smartphone Interface - ServiceNow Wiki

Understanding how filtering works within the Mobile user interface is helpful as it will allow you to customize the available options for filtering, and ensure that users accessing your instance on the go can find the information they need quickly.  The mobile UI has a more streamlined subset of the filtering options, designed to be usable within the more limited hardware and screen space and of a mobile device.  As a result, there are some differences in the way filtering functions.

 

 

Accessing the List Filter on a mobile device

The desktop UI has a “funnel” icon above the list to see filter options.  In mobile, filtering is done by tapping the list's table name, which appears in blue in the upper left above the list.

 

Here you’ll see a list of available fields used for filtering (Not all fields will be visible, as they are in the Desktop UI, more on that below).  Clicking on any of these fields will then display a list of operators.  Tapping on an operator will display a list of appropriate options, or a text box for manual input.  There are some limitations and differences on the mobile version of the filter detailed below.

Filter_Location.png

 

You will notice that there is no 'or' condition when trying to filter in the mobile interface. Mobile filtering is a little less comprehensive, so there’s not a method to add 'or' to your conditions yet.  To get around this, consider using the “is one of” operator to filter for multiple choices.

 

 

Selecting multiple options on the same field

For operators like “is one of,” a text box is displayed rather than a list of available items.  The text box can be used to enter multiple comma-separated items.  The example below shows the selection of two categories for the incident table.

Screen Shot 2015-08-13 at 10.07.33 AM.png


Where are the rest of the fields in filter options?

The fields displayed in the mobile filter options are the same fields that appear on that table’s list using the mobile view.  There are a few other fields shown in addition to these, for example Sys ID and Updated.

 

For example, take the incident table.  In the desktop UI, open the incident list and select the mobile view.  Out of box, you’ll see the Number, Category, Short Description, and Priority fields.

Screen Shot 2015-08-13 at 10.16.54 AM.png

These are the same fields we see as filter options in mobile view.  Configuring and adding fields to this list will also make them available as filter options in the Mobile UI.  The only exception here is dot-walked fields, which currently do not show in mobile filter options (this is being addressed in problem PRB613371).  Other than this exception, any fields added to this list will become available as filter options for your mobile lists.

 

 

 

Sorting is done using the field drop down

Currently sorting is limited to the drop down located just above the search box.  The fields available in this box are also limited to the ones on the mobile list for that table, as discussed above, so adding fields to the table’s mobile view list will also make them visible here.  Tapping the drop down text will also reverse the sort order.

Screen Shot 2015-08-17 at 1.26.51 PM.png

 

 

There are a few known issues with filtering in the Mobile UI.  Remember, the mobile interface is designed to be usable within the more limited hardware and screen space and of a mobile device. Not everything you can do on a desktop can be done from a mobile device. We have condensed the experience to make it easier to use from a go-anywhere perspective.

 

 

 

With the above information, you should have an understanding of filtering within the mobile UI, be able to customize the field availability on your mobile lists, and ensure that your users have the information they need available to them.

Filter Blog

By date: By tag: