Mobile app links

So you have developed a really nice configuration for the Now Mobile app, it has been tested by multiple users, the texts have been aligned by the communication specialists, the internal marketing is running, … Everything seems like a great achievement! Congrats!

Oh, but one more thing – wouldn’t it be nice if users reading email notifications on the mobile device are redirected to the mobile app instead of the mobile browser when tapping on a link? Or when chatting with someone who provides them with an approval link, wouldn’t it be faster to open the app with the approval screen?

Things like that are often forgotten during the mobile configuration development and only come out of the shadows once the configuration has been deployed and users start complaining that they have to login in the mobile browser again when they have already done so in the mobile app. ServiceNow has a solution for this! But first, let’s define some common terms

Definitions

When to use them?

Now this can be tricky. Both link types have some valid use cases, but none of them can be used separately. Enough to say that universal link uses the deep link. It makes sense when you think of it. But both of them miss a very important point – has the user installed the app? Is the user logged into the instance? These points can be handled, at least to some extent, with the custom solution I will propose. But first, let’s see the pros and cons of provided solutions.

Universal link

The universal link seems like a great promotional tool and is pretty easy to configure – requires a single line of script and a regex to work properly. But it comes with a cost – you can’t configure the banner:

You can’t alter the icon, the text, the description. You have some control over the View link, but it’s still far from ideal. This solution assumes that all of your users have the mobile app installed. If not, they will see an error about unhandled protocol after using the link.

Deep link

The deep link is described as:

This is true, they can be used like that. But are they actually useful? When you create your first deep link you will soon notice that it has one big flaw – it can’t be used in desktop browser:

So can you put it in the notifications? You could. But then you will also have to add a message like this link is for the desktop and hey, we also have a mobile app! already using it? use this link instead! What about text messages? Same story, same problems.

It doesn’t really solve the issue, because users will still use the regular link with no indication that they can use the mobile app. Unless you add the universal link. But then you have to ensure they will have the app installed. You havae MDM? Great, use that! But what if you don’t?

Learning how to use the deep links is, however, essential. You can use them in the push notifications or other mobile screens. And this is the only way if you want to allow users some alternative navigation. The deep links are also essential part of the more universal solution I have developed.

Notifications – existing solutions

The only existing solution to cover the notification link use case is this one on the community. It is great and inspired me to create my own, but has one big flaw – requires you to update all of your notifications with a new mail script. This can be not worth it and you may be temted to drop the subject and simply tell that it’s not possible, dear customer. But this is not something I like.

I don’t think there is a perfect solution to this problem:

Mobile configuration deployed
No MDM to force mobile app installation
Lots of non-technical users

If you are in a similar situation, here’s what I did.

My solution – custom widget

Since the issue appears on the mobile browser level accessed from the notification link, let’s develop a widget. Something similar to the universal linking solution, but with more control and a little bit smarter.

Issue #1 – how to detect a mobile browser?

You may find multiple solutions to this problem online. Some more, some less complex. I took the simplest one with window.matchMedia method, as shown here. It has the additional flexibility of defining a width for your mobile-only logic.

Issue #2 – Apple or Android?

This will be good to know if you want to redirect users to the proper store in case they haven’t downloaded the app yet. It’s another simple check on the navigator.userAgent string. I know that it can be easily spoofed, but honestly, who does that on mobile devices?

Issue #3 – who has the app?

That’s the hardest one. There is no definite answer to that. And the question must have been asked so many times in the past that ServiceNow has even release a KB article explaining the issue. Basically you can never know for sure who has downloaded the app before the connection to the instance (obviously). But once the connection has been established, the table sys_push_notif_app_install will have a record of it (I am not yet sure if it will be gone if the user does not agree to receive push notifications – but for now, it is our best bet that someone has the app installed and has connected to the instance).

Solution

Create a widget
In server script, check if the user has active entry in sys_push_notif_app_install table
In server script, generate a deep link to current page (form, KB article, survey, approval, …)
In client script, check if the user is using mobile browser
In client script, check if the user is using Android or Apple
Based on that, generate a message to the user with correct links

This combination of custom scripting and deep links is flexible enough to handle most of the cases with mobile access to the platform as well as we can achieve it. At least in my opinion. Got any better solution? Let me know!