Mobile — What Employees Get

Mobile — What Employees Get

1. What it is

The mobile experience gives employees access to the platform from their phones through two channels: a native iOS/Android app (available in the App Store and Google Play) and a mobile-optimized web surface at /m/ that any phone browser can reach. Both show the same content — the same apps the admin has enabled, the same dashboard widgets, the same notifications — rendered in a lightweight layout designed for one-handed use.

• Enablement: Mobile access is a platform capability, not a licensed app. Every tenant has it from day one. There is nothing to turn on — employees with a phone can sign in as soon as they have an account.
• What it is not: This is not a separate product with its own data. Mobile shows the same business data as the desktop. An admin does not configure “the mobile app” — they configure apps, permissions, and branding once, and mobile reflects those choices.

2. Standing it up

1. Employees download the native app from the App Store (iOS) or Google Play (Android) and sign in with their organization’s URL (the same {business}.workforce.mangoapps.com domain).
2. Employees who use a phone browser instead of the native app are automatically redirected to the mobile-optimized /m/ surface when they visit a paired page. No configuration is needed — the platform detects the phone’s User-Agent and redirects.
3. To customize the mobile look, go to Admin → Theme Settings (under General Settings). The Mobile section lets you set header background, header text, footer background, active tab icon color, and inactive tab icon color. If left blank, the mobile header inherits the desktop sidebar rail color, then the brand primary color.
4. Confirm it works: open your organization’s URL on a phone. You should see the mobile login screen, then the mobile dashboard with widgets and a bottom tab bar.

Silent-until-paired: Only apps that have a dedicated mobile view appear in the mobile app grid. Apps without a mobile view still work — tapping them from the tab drawer or a notification opens the desktop version inside the native app’s WebView — but they are not listed in the grid to avoid confusion. Whether an app has a mobile view is determined by its route registration — no manual list to maintain. App Builder plugins with at least one record schema also get an automatic mobile renderer.

3. How it fits together

Two channels, one access model — The native app and the mobile web surface (/m/) use identical access checks. An app that is enabled for the tenant and accessible to the employee on desktop is accessible on mobile. The mobile app grid, the bottom tab bar, and every in-app screen all run the same enablement and per-user visibility checks the desktop uses, so an admin never has to configure mobile access separately.

Auto-redirect — When an employee visits a desktop URL on a phone, the platform automatically redirects them to the mobile equivalent. Tablets stay on desktop. The redirect fires only on GET requests so a form submission from a phone never loses its data. Employees can opt out for the rest of their session by appending ?desktop=1 to any URL (or ?mobile=1 to switch back). This preference is session-sticky — it persists until the session ends.

Native app vs. mobile browser — The platform distinguishes between the native app WebView and a standalone phone browser. When running inside the native app, the mobile layout suppresses its own bottom tab bar (the native app provides its own navigation chrome). When running in a phone browser, the web tab bar shows: Home (dashboard), up to three pinned apps from the desktop sidebar, and a More button that opens the full app drawer.

App grid — The full app directory is available at /m/ (the “Browse all apps” screen). Apps are organized into categories — AI & Automation, AI Agents, Shifts & Scheduling, HR & People, Performance & Growth, Recruiting, Operations & Facilities, Procurement & Finance, Communication & Engagement, and Documents & Compliance. Each category is filtered to show only apps enabled for the tenant and accessible to the current user. If every app in a category is disabled, the category itself disappears from the grid.

Dashboard and widgets — The mobile dashboard at /m/dashboard renders the same widget engine as the desktop dashboard, stacked in a single column. There are 95 mobile-native widget templates covering the full breadth of the platform — schedule, attendance, leave, timesheets, notifications, tasks, recognitions, service desk, forms, training, and more. Widget data comes from the same backend services, so an admin managing widget configuration on desktop simultaneously controls what employees see on mobile.

Multi-workspace support — Employees who belong to more than one workspace can switch between them from the profile screen at /m/me. If an employee taps an app that is enabled on a different workspace but not the current one, the screen tells them to switch workspaces rather than showing the generic “App Not Enabled” message.

4. Running it

Branding the mobile experience

Go to Admin → Theme Settings. Under the Mobile section, set:

• Header background — the color of the top bar. Inherits from the desktop sidebar rail color if not set.
• Header text — auto-detected from header background luminance (light text on dark backgrounds, dark text on light) if not set.
• Footer background, active icon, inactive icon — control the bottom tab bar appearance.

Brand colors, fonts, and border radius from the main theme also apply to the mobile layout. Custom Google Fonts set in the theme (Inter, Roboto, Open Sans, Lato, Montserrat) are loaded on mobile too. In dark mode, the header defaults to a neutral dark tone regardless of the brand color.

The mobile layout also supports a maintenance banner — if a maintenance window or read-only mode is active, employees see a prominent bar at the top of every mobile screen explaining what is happening.

Managing what appears on mobile

No separate mobile configuration exists. To change what employees see on mobile:

• Enable or disable apps at Admin → Apps & Marketplace. The mobile app grid and tab bar reflect this immediately.
• Pin apps to the desktop sidebar rail. The first three pinned apps also appear as tabs on the mobile bottom bar.
• Set audience or visibility rules on apps. Mobile enforces the same per-user access rules — audience groups, visibility rules, and license seat limits.

Mobile login

Employees sign in on mobile using the same credentials as desktop. Three authentication methods are available:

• Email/username and password — standard credential login at /m/login.
• Sign in with code (OTP) — a 6-digit code sent to the employee’s email (preferred) or phone. Available when the Sign in with code setting is enabled (on by default). Employees can identify themselves by email, username, phone number, or employee ID. Codes are 6 digits and rate-limited to 3 requests per 5 minutes, with a maximum of 5 verification attempts per code.
• SSO — any SSO provider configured with mobile support appears as a button on the mobile login screen. SSO providers must have their channel support set to Mobile only or Both to appear.

Two-factor authentication, if enabled for the user, redirects to the standard 2FA verification flow before completing the login.

The native app authenticates via a signed WebView token — it calls the API, receives a short-lived token, and opens /m/login/native to establish a session without the user re-entering credentials.

Password reset is also available on mobile at /m/forgot-password — the employee enters their email or username and receives a reset link. The flow is identical to the desktop password reset.

Mobile onboarding

New employees who sign in on mobile are taken through the same onboarding wizard as desktop, rendered in the mobile layout. Steps, validations, and ordering are identical — only the look changes. Desktop users who accidentally land on /m/onboarding are bounced back to the desktop wizard, and vice versa.

Mobile inbox

Notifications appear at /m/inbox with folder chips (All, Action Required, Announcements, Archived, etc.) and infinite scroll (25 notifications per page). Each notification links to the mobile version of its target page. A Messages entry row at the top links to the direct-messages surface when the Messages app is enabled. Employees can mark individual notifications or all notifications in the current folder as read. When the Communications app is enabled and accessible to the user, a tab bar appears at the top of the inbox for switching between the notification feed and the communications surface.

Mobile profile

Employees can view and edit their profile at /m/me. Editable fields are governed by the same field-level permission system as desktop — by default, only preferred name and phone are employee-editable. The edit screen accepts JPG or PNG photos up to 5 MB. When Employee Data Management is enabled and self-service editing is off, non-admin employees cannot edit their profile on mobile.

Mobile settings

Employees manage their notification channel preferences at /m/settings — toggling email, push, SMS, and voice on or off. Channels that the admin has disabled at the business level, or that are blocked for the user (bounced email, unverified phone), appear as disabled and cannot be turned on.

Desktop→mobile URL rewriting

Notification action URLs and widget links are stored as desktop paths. On mobile, the platform automatically rewrites these to their /m/ equivalents before rendering, so tapping a notification (for example, an approval request) opens the mobile screen rather than the desktop page inside the WebView.

Expired session handling

When an employee’s session expires while using the mobile surface, they are redirected to /m/session-expired instead of the desktop login page. The native app detects this and can re-authenticate silently. In a phone browser, the employee sees a dedicated session-expired screen with a sign-in button.

5. Settings

Setting	Where	Default	What it changes
Mobile header background	Admin → Theme Settings → Mobile	Inherits from sidebar rail color or brand primary	Top bar color on the mobile layout
Mobile header text	Admin → Theme Settings → Mobile	Auto-detected from background luminance	Text color on the mobile top bar
Mobile footer background	Admin → Theme Settings → Mobile	White (light) / dark zinc (dark)	Bottom tab bar background color
Active tab icon color	Admin → Theme Settings → Mobile	Brand primary	Color of the currently selected tab icon
Inactive tab icon color	Admin → Theme Settings → Mobile	Muted gray	Color of unselected tab icons
Sign in with code (OTP)	Admin → Security Settings	On	Whether employees can log in on mobile using a 6-digit code
Employee self-service editing	Admin → Employee Data Management	On (when app enabled)	Whether non-admin employees can edit their own profile on mobile
SSO channel support	Per-SSO provider configuration	Both	Whether an SSO provider appears on the mobile login screen (set to Mobile only or Both)

6. More help

• Notifications — Channels, Defaults & Opt-outs — how the notification channels employees toggle on /m/settings work platform-wide
• Security & Sign-On — SSO setup, two-factor authentication, and the OTP login setting
• Ask AI — the assistant answers questions about mobile access from these articles.