It’s pretty easy to create a list screen on mobile configuration pointing to the specific screen or triggering a function instance. It gets harder when you want to create a hierarchical list, e.g. a service catalogue view with categories, subcategories and catalog items. Although this has been provided by ServiceNow as an out-of-the-box component, you may want to create one on your own – if you want to change the cards for the list screens or to display other hierarchies, like taxonomy -> topic -> connected content.
Start by knowing your hierarchy
It may be unusual beginning, often omitted, but it is really important to understand your hierarchy. First of all, check if there is a hierarchy at all. Do your items have parent items? How many sub-levels you could go? Is there a unique way to identify a child item? How will you display the items on the mobile configuration? Will you skip some levels? Will you include the descriptions on the cards?
By answering these simple questions you will prepare yourself for the actual development, which will be pretty easy.
Prepare your hierarchy
Now, since you know what you want to show, you still need to prepare the data for being displayed. The easiest way would be by creating a single, parametrised remote table providing parents and leaf nodes. In fact, this is exactly how ServiceNow prepared their examples – check the remote tables called v_st_sc_catalog
, v_st_sc_category
or v_st_sc_cat_item
.
The reason for using a single remote table is very simple – with mobile configuration, your list screen will be recursive and parametrised. It makes perfect sense to use single table which has the same characteristics.
If you don’t know how to start with building remote tables, refer to my previous post.
Prepare your card templates
It really facilitates the development to work on distracting details at the beginning, so I’d recommend to have the card templates already prepared. Thanks to that, you won’t have to loose your focus when traversing the recursive world of mobile list screens, which can be confusing.
Example – service catalogue
I’ll explain how to build your own screen by analysing the out-of-the-box one.
We start off by creating a simple list screen for the top level content. Depending on your use case, it could be either a taxonomy, a root topic or child topics (for flat hierarchies). As explained before, we’ll use our remote table as a data source.
With instances in Washington release, the Mobile App Builder has a really great step-by-step screen when defining new list screen. Just remember to use your remote table as a datasource and add any conditions to determine root hierarchy elements. Once completed, it can look like that:
The example above is used for the simple, flat hierarchy – only one level, parent item with direct children. At this stage, more complex hierarchies will look the same. It’s important to remember that when including recursive functionalities, you only work on the function – because the screen is the same.
This is still pretty basic stuff, just the usual list screen with function trigger on tap of an element. The function is where the fun begins.
Defining the function
The function is the heart of this solution. This is the place where you define what happens when the user interacts with the list element.
Your function should navigate in the context of a record to another list screen. It makes sense when you think of it – you see a list of records, then you trigger another function in the context of specific record. Since we are at the top level and we definitely have some another level in the hierarchy, we open another list screen. But this time, it has to parametrised – with the parent id.
Adding a parameter is quite easy when you remember about some caveats:
- You define your data parameter on the data item component
- You add your data parameter to the condition on the data item component
- You use your data parameter on the list screen component to connect it with the UI parameter
- Finally, you use your UI parameter on the function component to create a redirection destination field
With this order, configuring a parametrised navigation function is quick and easy.
Adding recursive capabilities
Now, having the top level list screen and the 2nd level list screen, it’s time for a conditional 3rd level. It can either be a subcategory or a catalog item.
We are still on the 1st navigational function configuration, adding on tap function instances to the 2nd list screen:
We want to cover multiple scenarios, so we have to add multiple functions – one for each scenario. You may be wondering – where is the condition? How do I set when the functions are triggering? This is done on the function record itself – not the function instance connected with the list item config:
The example above will trigger only when an item on the list that the user interacted with has value of Is leaf
set to false
. Which means that we are tapping on the category and… should redirect the user to 3rd list screen showing the list of categories. This is where the actual recurrence comes – earlier settings were just parametrised list screens facilitating navigation.
Thankfully, when you finally understand what you want, it’s really easy to achieve that. Creating the 3rd list screen and adding appropriate parametrised data item with redirection destination fields is simple. Covering two scenarios, when user taps on a catalog item or a category is as simple as adding two functions to the list item config. The only difference is that on the component tree, recursive function will not have a child node:
With the recursive function added, we still have to configure a scenario when there are no subcategories. And for that… yes, that’s correct, we need another parametrised list screen. But this time, we will be displaying catalog items belonging to dedicated category. You may use the same remote table as you have used so far, just remember to add proper data parameters and conditions.
Now there is only one scenario left – the actual catalog item being tapped. What you want to do then? The simplest way is to redirect user to dedicated mobile portal – mesp. For that, use the URL type function in the context of the record.
Summary
It may seem to be hard at the beginning, but in fact it makes a lot of sense. There’s no need to rush when building mobile configuration – otherwise, you may quickly feel intimidated. Make sure you understand what you need and why. Working with mobile configurations is rather counter intuitive compared to the rest of the platform – there is only one way to achieve what you want.