Introduction
Push notifications are an essential feature in the mobile landscape to notify users of various events. For example, when users are being assigned to work on records (work orders, incidents, etc), when a new work note is added to a record you are working on, when news is pushed, when new articles appear in KBs you are subscribed to, and so forth.
The currently used ServiceNow "Mobile" and "Agent" apps come with a number of out of the box notifications for various use cases that are tied to OOTB functionalities in the products leveraging these Apps. However, there are also use cases to configure your own notifications. For instance when a record is created, kicking off a validation or a data update cascade into an integration, and for which the user desires to be notified through a Push notification.
There are now multiple ways in the platform to configure these Push notifications, so this article aims to give a brief overview of the latest best practices on them. This article accompanies the official documentation and aims to provide a concise guide for the basic use case, as the official docs are not always very straightforward.
Setting up a new notification
As of writing, in Vancouver, upon entering "push" in the navigator various options are shown to the user. In Vancouver, we will use the System Notification > Push menu (not the "Mobile Push Notiifcations" menu!).
This article will describe just a simple text message Push notification without actions or buttons, but will provide some resources for that.
The following tables are involved in push notifications:
| Table label | Table name | Purpose |
| Notifications | sysemail_event_action | Notification record that we will use to trigger the notification and describe who it is delivered to |
| Push Notification Message | sys_push_notif_msg | Push Notification Message body |
| Push Message Content | sys_push_notif_msg_content |
Push message generation script, including a reference to what Screen should be opened |
| Push Application | sys_push_application | List of mobile applications that are registered in this instance |
| Push Action | sys_push_notif_act_script | Quick actions for the notification to act on via the lock screens or notification centers on the mobile devices, such as Accept task or Reject task |
| Push Default Registrations | sys_push_notif_default_reg | Registrations of push notifications to the notification service |
| Push Notification Installations |
sys_push_notif_app_install |
Installations of the app and corresponding registrations to the instance, for the purpose of linking users to devices |
In this article, we will not cover push actions, only setting up a text push notification, so you have the basics and can work from there. We will also cover debugging notifications.
Setting up the main notification
First, let's create the body of the push notification. Via System Notification > Push > Push Messages, we can create a new record in sys_push_notif_msg. Set the following fields:
- Name: description of the push notification
- Push app: select the appropriate app. This will usually either be "ServiceNow Mobile Application" in case of Mobile Agent, or "ServiceNow Request Application" in case of Now Mobile app
- Push Message Content: we will leave this empty for a second and get back to this
- Message: the text body of the push notification. It is possible to use fields and dot-walk here, by using ${field_name} as in any other notification body. E.g.: ${number} - Successfully processed by user ${assigned_to.name}
Now, we will need to create a Push Message Content, which tells the mobile app how to handle this push notification exactly. For the purpose of this article, we will use a simple text message (written above), a deep-link to a record in a details screen, and no actions.
We create a new record in Push Notification Message Content, and we link it to the right Push app. We give it a descriptive name and then a script as follows. In this example, I am creating a new deep link to the "Agent" app, and I tell it to open details screen with sys ID `832c2f7253b0330097a2ddeeff7b1200` (Work Order Task Details Screen), then the record in wm_task with sys ID that I am retrieving from `current`:
(function buildJSON( /*GlideRecord*/ current, /*String*/ message, /*Object*/ attributes) {
var deepLinkGenerator = new global.MobileDeepLinkGenerator("Agent");
var link = deepLinkGenerator.getFormScreenLink("832c2f7253b0330097a2ddeeff7b1200", "wm_task", current.getValue("sys_id"));
return {
"Link": link,
};
})(current, message, attributes);
The sys ID for the Details screen corresponds to a Record screen [sys_sg_form_screen] entry. Find yours by opening Mobile App Studio, opening your respective app, navigating through the Record screens and finding the right sys ID for this Details screen, or alternatively looking in sys_sg_form_screen table directly and identifying the correct record (sometimes difficult as there might be multiple called "Details" for your table in your app).
Now let's to back to our Push Messages record, and in the Push Message Content field, link our newly created message content.
Next up, we will create the Notification record that defines the trigger and recipients. Either via System Notification > Push > Create Push Notification or via same module's menu item Push Notifications, create a new entry in sysevent_email_action with Push Message Only = true.
You will need to set the following fields:
- Name: short description of the notification
- Table: table that drives the notification, i.e. the primary record from which we will read fields, the trigger, etc
- Category: set a descriptive category like "Field Service" or keep it as "Uncategorized", this is for internal administration purposes only
- Active: true
- Push Message Only: true
- When to send: either tick "Inserted" and/or "Updated" according to specific record conditions, or leave it empty and we can switch it to "Triggered" once it has been created. This will allow us to trigger it via a Flow, Business Rule, or otherwise.
- Who will receive: select the appropriate users
- What to send: open the Push Messages list container and add the sys_push_notif_msg record we created before
With all this in place, we will only need to register the notification. Go to the Push Application module, and select the correct parent app. Go into the related list Push Default Registrations [sys_push_notif_default_reg] and add a new m2m record for the newly created Notification.
We are now good to go!
Testing and debugging
In our trigger, which is defined in the sysemail_event_action record under the "When to send" tab, we have defined that it will either send upon a record insert, update, or when it is "Triggered". In case of Trigger, you can easily send it through the "Send Notification" action in flow designer:
Hopefully, the notification should come in! In case it doesn't, there are a few things to check:
- In the table sys_push_notif_app_install, an entry should exist for this mobile device linking it to this user
- In the syslog table, you will find entries with Source = notification.push which contain information about installation, when notifications are marked as read,
- In the syslog table, you will find entries with Source = push which contain information about when notifications are pushed to the provider over REST, to which app (e.g. SkyNowPushApp, etc)
- If after promoting your configurations to other instances the push notifications don't immediately work, remove and re-add the record to the m2m Push Default Registrations table as per the setup instruction. After that, give it a little bit of time, and it should hopefully magically start working again within a few hours.
Conclusion
In sum, it is not very difficult to set up a few push notifications and debug them, but there are multiple architectures that exist concurrently and it's not always clear where to begin. Hopefully, this article clears that up.
From here, it is possible to expand the functionalities using push actions or more complex notification bodies. For that, familiarize yourself with the official documentation at https://docs.servicenow.com/bundle/washingtondc-mobile/page/administer/tablet-mobile-ui/concept/sg-m...
Good luck!
