Troubleshooting ServiceNow Mobile Experience: A Practical Guide

Identifying mobile app and experience problems

ServiceNow Mobile Experience delivers ServiceNow functionality to mobile devices through native apps or responsive web interfaces. Problems manifest as the app crashing, not loading data, not receiving notifications, or behaving incorrectly compared to web interface. IT directors supporting mobile users need to distinguish between app problems and server problems. An app that crashes on certain devices may have a device compatibility issue. An app that never connects may have a server configuration issue. An app that loads slowly may have network or server performance problems. Start investigation by gathering information from users: which device model, which OS version, which app version? Are multiple users affected or just one? Has this ever worked or never worked?

Mobile app crashes and device compatibility

Mobile applications are built for specific device types and OS versions. An older app may not work on the latest iOS or Android. A newer app may not work on older devices lacking required capabilities. When crashes are reported, check the app version and device OS version. Ensure the user is running the minimum supported OS version. If the crash happens on the latest app but not older versions, the problem may be a bug introduced in the new version. If the crash began with a particular app version, record that version, because a fault in one release looks different from a device problem. If the crash is reproducible, collect a crash dump from the device. Crash dumps contain stack traces that show exactly where the app failed. Provide this to ServiceNow support for analysis. Common crash causes: out of memory on the device, incompatible library, corrupted local cache. Clearing the app cache and re-installing may fix transient issues. If crashes persist after reinstalling, the issue is likely a bug in the app or incompatibility with the device.

Network connectivity and data loading

Mobile apps depend on network connectivity to load data. A mobile device on weak Wi-Fi or poor cellular signal may appear to hang when loading. This is actually slow network, not an app problem. Help users understand their network strength and move to better signal if possible. For apps that support offline mode, data should load from local cache when the network is unavailable. If the app shows no data when offline, the cache may not be populated. Offline functionality must be explicitly configured: tell the app which data to cache for offline use. Older data caches are not automatically refreshed, so users may see stale data. Instruct users to refresh the cache when returning to connectivity.

Push notifications and messaging

ServiceNow Mobile Experience sends push notifications to alert users of new work items or system events. When users report not receiving notifications, investigate notification configuration and device settings. On the server side, check whether notifications are enabled for the user’s role and the specific notification type. On the device side, check whether notifications are enabled in app settings and OS settings. Users may have disabled push notifications in system settings, thinking it would only disable marketing notifications. Mobile OS also consolidates notification permissions, so disabling notifications for one app may affect all apps. Walk users through checking both app settings and OS settings. If notifications are enabled but still not arriving, check whether the device is registered to receive push notifications. Mobile apps register with push notification services (Apple Push Notification Service for iOS, Firebase Cloud Messaging for Android). If registration fails, no notifications will arrive. This usually indicates a network or authentication issue.

Performance and responsiveness

Mobile apps must be responsive even on slow networks or older devices. When an app is slow to load or laggy when scrolling, investigate whether the problem is the app design, the server, or the network. A simple test: does the same app perform well on a newer device with faster network? If yes, the issue is device or network capability, not the app. If the app is slow on all devices, investigate whether the app is making unnecessary server requests. Some app screens may fetch data for multiple tables unnecessarily. A list view might fetch not just the list items but also related records for each item, multiplying the data transfer. Review app design to minimize data fetching and cache data aggressively. Pagination also helps: load only the first 25 items, not all 1,000, and load more as the user scrolls.

Offline mode and data synchronization

Mobile apps supporting offline mode must cache data locally and re-sync when connectivity returns. When offline mode fails—data is cached but the cache is empty when the network is available—investigate the cache configuration. Offline mode must be explicitly enabled and configured to cache specific tables or views. If it is not configured, the app will not cache anything. After configuring offline mode, test it: go offline, verify that data is still accessible, then go online and verify that data is synchronized. Sync conflicts can occur if the same record is edited both offline and on the server. The app must have a conflict resolution strategy: does the offline edit overwrite the server edit, or vice versa? Document the strategy so users understand expected behavior.

User roles and record access

Mobile apps respect the same access controls as web ServiceNow: a user can only see records their role allows. When a user reports that a record is visible on web but not mobile, investigate whether mobile access is restricted. Some organizations configure mobile apps with more restrictive access than web for security. Check the Mobile app configuration to see if record access filters are applied. Also check that the user is properly authenticated to the mobile app. A user logged into web but never authenticated to mobile may only see records visible to unauthenticated users.

A layered triage order for mobile problems reported by users

Mobile complaints arrive vaguely. A user says the app is broken, which may mean it will not open, the list is empty, alerts have stopped or a button does nothing. Starting from the complaint itself wastes time. A layered order works better: check identity and access first, then the device and app version, then the network path, and only then the platform configuration. Many reports resolve in the first two layers. It is aimed at the service desk lead and the platform support engineer who take these calls.

Capture the facts before changing anything

Ask for the same five facts every time: the device model, the operating system version, the app version, the time of the failure and the record or screen involved. Ask whether the user could do the task before, and whether anyone else on the same site is affected. A ticket without those facts sends the next engineer back to the same questions. Keep the facts in a fixed order in the ticket so a later reader can scan them quickly.

An ordered triage procedure

1. Confirm the user can sign in on the desktop. A desktop failure is an identity problem, not a mobile one, and it changes the owner of the ticket.
2. Compare the user’s roles and access on both channels. A mobile role narrower than the desktop role, which the security and access design covers, can explain many “missing record” reports.
3. Check whether the app version is the current release and whether the device meets the minimum operating system version listed for that release.
4. Reproduce the problem on a test device with the same model and version, using the same account type. The testing checklist is the place to look for test scenarios worth reusing. If it does not reproduce, the cause is probably local to the user’s device or network.
5. If it reproduces, collect the device log and the failing request time, and pass both to the mobile release owner with the ticket facts.

When to stop and escalate

Stop troubleshooting at the desk and escalate once a fault reproduces on a clean device, affects more than one user on the same version, or appears to involve a data exposure. Do not ask users to reinstall repeatedly as a way of buying time when the pattern points to a release problem, because repeated reinstalls destroy the local evidence the release owner needs.

Signs the triage is working

Many tickets close in the first two layers, with the cause recorded as identity, access, device or network. Repeat reports from the same version are grouped and sent to the release owner as one item. The service desk can tell a user what changed in their situation without guessing, and the time spent on each call falls as the team learns the common patterns.

When this order does not fit

A confirmed outage affecting many users should skip the per-user order and go straight to the platform status process. The layered order is for individual and small-group reports, where the cause is still unknown.

Frequently asked questions for mobile support teams

Why does a user see records on the desktop that they cannot find on the phone?

Usually the mobile role is narrower than the desktop role, or a list filter saved on the desktop does not carry over to the phone. Compare the two channels for the same user and the same list before assuming a fault.

How do we tell a device fault from an app fault?

Reproduce on a second device of the same model. If only one handset fails, the problem is on that device. If several fail on the same version, the app is the likely cause.

Should the service desk ask users to reinstall the app first?

Not as a first step. Reinstalling removes the local state that shows what went wrong, so collect the facts and the device log first, and reinstall only when the release owner asks for it.

What should a support engineer tell a user while the ticket is open?

Say what has been checked, what is being checked next and when the user will hear again. Avoid guessing at the cause until a test has reproduced it.

Next step

For the habits that reduce repeat tickets in the first place, the mobile best practices guide is a useful companion.