8.3 Salesforce Mobile Navigation, Actions, and Page Design

Design for the mobile job

A mobile user is usually trying to complete a specific task under constraints. A sales rep may need to check an account address before a meeting, log a visit afterward, update opportunity stage, scan recent activities, or call a contact. A service manager may need to review a high-priority case, approve an exception, or check a dashboard during travel. If the admin simply exposes the full desktop page, the mobile experience becomes slow and hard to scan.

Mobile design starts with the question: what should the user be able to do in less than a minute? The answer drives navigation, actions, compact layouts, page components, and field placement. The first fields shown on a record should identify the record and next action. Related lists should support common mobile decisions, not every possible relationship. Actions should be specific and safe. A mobile quick action for Log Visit may be better than asking users to open a full task editor.

Admins configure pieces in several places. App navigation is managed in App Manager for Lightning apps and through Salesforce mobile app navigation settings where applicable. Compact layouts are managed in Object Manager. Quick actions are created globally or on objects and then placed on page layouts or Lightning pages depending on the action type and experience. Lightning App Builder lets the admin activate pages by app, record type, profile, and form factor. The right setup path depends on the symptom.

Testing by form factor is not optional. A record page that looks clean on a laptop can be frustrating on a phone if the important fields are buried below several components. A screen flow with many required fields can be hard to complete outdoors. A custom component can work in desktop Lightning but fail or perform poorly in the mobile app. Admins should preview mobile form factors and, for important workflows, test on actual devices with representative users.

Mobile security and support workflow

Mobile is a security boundary because Salesforce data leaves the desk environment. The admin should coordinate with identity, security, and device management owners when mobile use involves sensitive records. Login policies, multi-factor authentication, session settings, connected app controls, IP restrictions, and mobile device policies can affect whether users can access the app and how often they must authenticate. The exam-level point is that productivity never overrides access control.

A mobile rollout checklist:

1. Identify the mobile personas, such as field sales, executives, service managers, or partner-facing users.
2. List the top tasks each persona must complete from a phone or tablet.
3. Confirm object permissions, field permissions, record access, and approval access for those tasks.
4. Configure navigation, compact layouts, quick actions, and Lightning pages for the relevant apps and form factors.
5. Test with realistic data, slow network conditions, and at least one user from each permission model.
6. Document login, device, notification, and support expectations.
7. Monitor adoption through activity creation, mobile-specific feedback, and support tickets.

Support questions should be diagnosed systematically. If a user cannot see an object in the mobile app, check app navigation, app assignment, object permission, tab visibility, and profile or permission set access. If the user can see the record but cannot edit a field, check field-level security, page layout, dynamic visibility, validation rules, and record ownership. If an action is missing, check whether it is a global or object-specific action, where it is placed, whether the page is activated for mobile, and whether the action type is supported in that context.

Performance is part of usability. Large record pages with many related lists, report charts, rich text components, and custom components can load slowly on mobile. Admins should keep mobile pages focused and use component visibility to show what matters. Do not hide critical required fields so deeply that users abandon the workflow. Conversely, do not place every field at the top because one team may occasionally need it. Mobile page design is about priority.

Mobile notifications can help time-sensitive work, but they should be governed like Chatter notifications. An approval request, high-priority case assignment, or meeting reminder may be useful. Frequent low-value notifications train users to ignore the app. The admin should coordinate notification behavior with process owners, especially when Flow, approval processes, and collaboration features send messages.

Hands-on practice: create a mobile-focused Lightning record page for a custom object in a playground. Add a compact layout with status, owner, and next action. Add a quick action that captures a short visit note and follow-up date. Activate the page for phone form factor if your setup supports it, then preview and test with a lower-permission user. The goal is to see how page design, permissions, actions, and adoption fit together.

Study trap: do not answer every mobile complaint with a custom app. Salesforce standard mobile configuration often solves navigation, page density, and quick-action problems. Custom development may be appropriate for specialized offline, barcode, geolocation, or device-native needs, but the administrator should first use standard app, action, page, and security controls.