This video demonstrates the steps for building a list app for the ServiceNow Agent mobile app.
Linked time codes for these topics appear in the YouTube description for this video.
You can easily build a mobile list app allowing users to retrieve a list of related records...
... view details for each record…
… access a related URL, and call an associated phone number.
For our example, we are building an app for Technicians to see the active Change Requests assigned to them.
They can review details of each record, call the requester...
... or review a related KB article right from the assignment record.
First, let’s look at the architecture of mobile apps.
When you build applications for the ServiceNow platform, they must be built within a scope...
... and are thus called scoped applications.
This keeps them separate, and allows you to restrict access to their files and data.
A scoped application serves as a container for your mobile app.
Within that mobile app, you create folders to hold related mini applications, called applets.
Here’s the overview of the architecture for the mobile app we’re going to build now.
Let’s get started!
We build all mobile app components in Studio, which is the ServiceNow IDE, or Integrated Development Environment.
We start by creating the scoped application.
Now we create the mobile application file, in which we define the properties for our mobile app.
We enter the app name that appears in the application list of the ServiceNow Agent,…
… select an icon and color for the icon…
…and a description that describes what the application does.
We can edit these properties here, anytime.
Now we’re ready to create folders within the application file, which are containers for related applets.
This particular folder will contain all applets for use by technicians.
In this folder we create an applet that automatically retrieves a list of active, scheduled Change Requests assigned to the logged-in user.
Now we define a data item for the applet’s primary screen.
We set up this data item to query the Change Request table, for all active Change Requests...
… assigned to the logged-in user, ...
…that are in the Scheduled state.
We navigate back to the New Applet tab and select our new data item.
Now we can select the fields to display on the data card for each Change Request, as shown here in the sample data card.
Let’s see what other options we have.
Clicking Change Item List brings up a list of available formats for the items we want to display.
Let’s try this one.
For our example, we want E1 to display the date the Change was opened...
... E2, the state...
... E3, the short description...
... E4, the number...
... E5, the user who opened the Change...
... and E6, the location.
We can move these fields up and down if we want to move things around.
Let’s save the record, and configure the next screen.
The details section displays what users will see when they click on a record from the list.
We could change the header for a different layout, …
… but let’s go ahead and replicate the data displayed on the primary card...
... and add different details to the body.
Here we want to display the description, …
… category…
… location…
…and the requester’s business and mobile phone numbers.
We could stop here, but we also want technicians to be able to call the requester, and look up a KB article.
We add these functions, called Smart Buttons, here from the Explorer.
The Type field determines what native functionality will be launched when the user clicks the button.
We enter a description stating what the button does.
This button will use a record…
…from the Change Request table, …
…to call the mobile phone number stored in the Requester’s user record.
This functionality will not be available offline…
…and it will only display if the Requesters mobile phone is available.
Now we can add the Smart Button to the applet, here in the Functions tab.
Now let’s add the Smart Button for looking up a URL – in this case, a KB article.
This button will use a record…
…from the Change Request table, …
…to display a KB article, …
… relative to this instance.
Here we enter a search string for the KB article, ...
…using the short description as a search parameter.
See this video for a quick demo to show you how to find a relative link.
And here we set a condition that our new smart button will display only if a KB article is available.
Let’s add the Smart Button to the Details screen, in the Top Menu.
Now let’s test our app!
We’ve set up a demo user to test the app – a technician, with several assigned and scheduled Change Requests.
We start by logging in and accessing our new mobile app in the applications list.
Here’s the mobile app description we entered, …
Here’s the folder we created, Technicians, with the list applet we built within it, My Scheduled Worklist, ...
…and here's the list applet description.
And here’s the list of change requests.
The technician can open a record, …
… call the requester, …
…and look up an associated KB article.
For more information, please see our product documentation, knowledge base, or podcast.
Or ask a question in the ServiceNow Community.