We're reclaiming inactive PDIs to keep them available for active builders. Learn what's changing, who's affected, and how to protect your work. Read More

Replacing native Settings tab in Now Mobile with custom Preferences screen

erraadithya
Tera Contributor

yesterday

We're building a custom Now Mobile app (Mobile App Builder) for a client, and they want the bottom navigation to show a custom "Preferences" tab instead of the native "Settings" tab.

We've confirmed:

The native Settings tab is a reserved tab type (no destination/launcher screen field — only Label, Active, and Icon), so it can't be repointed to a custom screen.

Our workaround is removing the native Settings tab and adding a new Launcher tab pointed at a custom-built Launcher screen that mimics the native Preferences UI (Language, Notifications, Security, Theme, Start my week, Analytics, Banners, Chart accessibility, Swipe from edge).

Our questions:

Are any of these native Preferences fields backed by exposed, bindable ServiceNow data (e.g., on sys_user or a mobile preference table) that we could wire into a custom Record/List section? Specifically Language and Notifications.

We found KB2987877 indicating Theme is controlled via UX Theme/UX Style records rather than user-level data — can this be exposed as a live, user-facing switcher in a custom MAB screen, or is it strictly an admin-configured, fixed setting?

For settings like Security (PIN/biometric), Start my week, Analytics, Banners, Chart accessibility, and Swipe from edge — are any of these exposed via API/table access at all, or are they purely native-shell/device-level with no ServiceNow-side hook?

Has anyone fully replaced the native Settings tab in a production Now Mobile deployment, and if so, what was your approach for handling the settings that don't have an accessible data layer?

0 Helpfuls
  • 42 Views
1 REPLY 1

Vikram Reddy
Tera Guru

an hour ago

Hello @erraadithya,

 

After digging into this: Language is the only one of these fields with a genuinely clean, confirmed data hook. Everything else on your list drops off fast, and a couple have no ServiceNow-side hook at all.

  • Language: confirmed on two layers, preferred_language on sys_user, and a sys_user_preference row with name user.language. Both are ordinary GlideRecord-readable and writable, so a Record or List section bound to either is low risk. One catch worth knowing before you build: there's documented drift between the two, changing one doesn't automatically update the other, so pick a source of truth and sync it with a business rule.
  • Notifications: there is a real table, sys_push_notif_app_install, which links a device install to a user and carries an Active flag that flips on login/logout. But that's push registration data, not the notification-category on/off switch shown in native Preferences. Binding to it tells you whether a device is receiving pushes at all, not the granular toggle UI.
  • Theme: KB2987877 is good news here, not a limitation. It confirms admins add custom options under Settings > Preferences > Theme by creating UX Theme and UX Style records and associating them. So the native picker is already a live, user-facing switcher, it's just choosing among admin-published UX Theme/Style records rather than reading a per-user field. I found no supported client-side call that lets a custom Launcher screen change a user's active theme association at runtime, so treat this as admin-curated, not user-owned.
  • Security (PIN/biometric): governed by instance-wide properties, glide.sg.require_mobile_application_pin and PINIdleTimeout, plus device biometric APIs. Admin-scoped configuration, not per-user instance data.
  • Start my week: no exposed table or property tied to this specific mobile preference. The closest platform control is glide.ui.filter.first_day_of_week, which sets a system-wide calendar default, not a per-user field you could bind.
  • Analytics: documented in the mobile admin guide as an enable/disable toggle for user-journey tracking, but no backing table or property is documented anywhere I could find, so treat it as native-shell state.
  • Banners and Swipe from edge: no documentation or exposed data layer for either, purely native-shell or device behavior as far as I could confirm.
  • Chart accessibility: real and documented, it renders charts with patterns instead of color, but it sits at the rendering layer, not behind any table or endpoint I could find.

On full production replacement: budget real time for a gap analysis with your client before promising parity. Language gives you a clean hook, Notifications gets you partway, and the rest is UI mimicry with no backing state, which turns into a support headache the first time someone asks why a toggle doesn't persist across devices.

One caveat: the docs I pulled these behaviors from span the Utah through Zurich release bundles, so sanity-check field availability against your client's actual instance version before you commit to the build.

 

Thank you,
Vikram Karety
Octigo Solutions INC

0 Helpfuls