* Salesforce Mobile *

Hi Jeff, since logging out and back in fixes it, the app is most likely holding an access token that Salesforce no longer accepts, and the silent refresh isn't working for that user. The mobile app talks to Salesforce through the REST API like any other OAuth client, which is why you only find this error in integration threads. Because it's one user and it happens daily, I'd look at what is different about that user's session rather than at the org: 

- Profile session settings. A profile can override the org-wide session timeout (and other session settings). If this user's profile has a shorter timeout than everyone else's, the token will die every day. 

- Connected app policies for Salesforce for iOS / Android. In Setup > Connected Apps OAuth Usage (or Manage Connected Apps), check the refresh token policy and any timeout value set on the app. Also check whether the app is set to admin-approved users only and the user's profile or permission sets still grant it. 

- Login History for that user around the time of the error. Look for Remote Access 2.0 / refresh entries with a failed status, which usually tell you why the refresh was refused. 

- Session Management in Setup. See if the user has a pile of sessions from several devices, or if something (a login flow, another admin, a security tool) is ending sessions on a schedule. 

- Session security level. If any search result object or page requires a High Assurance session and the mobile session is Standard, access can be refused until a fresh login. 

Quick test on the device side: have the user revoke the app under their personal settings (Connected Apps / OAuth), uninstall, reinstall and log in once. If the error stops for a while and then returns, it points to a policy or timeout. If it never returns, it was probably a stale token stored on that device.

Try this, set up and deploy Salesforce My Domain with customized login branding, which allows users to authenticate directly through your corporate identity provider or login screen without manually typing your community domain. Verify success by launching the Salesforce Mobile App on a test device and confirming it immediately presents your custom login page instead of prompting for a community domain. 

Next, configure SAML or OpenID Connect Single Sign-On (SSO) via a Connected App, enabling mobile users to authenticate seamlessly through your organization's central identity provider. Verify this is working by attempting a login with a test user account to ensure it authenticates through your IdP without intermediate routing screens. 

Then, utilize deep linking by distributing direct URLs that pass your My Domain parameters programmatically when launching the Salesforce Mobile App. Verify success by opening the deep link on a mobile device and ensuring it launches the app pre-configured to your correct environment.

Hi Bobbie — this comes down to a couple of documented mobile-app behaviors rather than a single setting: 

1. The mobile Activity Timeline is capped per section. In the Salesforce mobile app it shows up to 8 activities in the "Upcoming & Overdue" section and up to 8 in the "Past" section by default (so a record can show up to ~16 combined). That's why mobile never shows the full history that desktop does — desktop pages through everything; mobile is capped. Your "11" is both sections combined, the "6" is a record with fewer qualifying activities. 

2. Einstein Activity Capture (EAC) activities don't render on the mobile timeline. Emails and events captured via EAC show on the desktop timeline but are not displayed on the mobile activity timeline. If your org uses EAC (very common), that alone explains "several more activities on desktop." And because each account has a different mix of EAC-captured vs. manually-logged activities, the visible mobile counts differ account to account — exactly the inconsistency you're describing. 

3. The split matters: "Upcoming & Overdue" holds open/past-due tasks and events, while "Past" holds completed ones. An account with lots of overdue open tasks can look busier than one whose activities are mostly completed, even though both are subject to the same cap. 

4. Filter and search aren't supported in the mobile timeline, so you can't expand or re-query it the way you can on desktop. 

Net: it isn't one configurable number — it's the 8-per-section mobile cap combined with which activities are EAC-captured (hidden on mobile) vs standard. To reconcile a specific account, open it on desktop and check whether the "extra" activities are Einstein Activity Capture emails/events — those are the ones that won't cross over to mobile. 

Source: What's Different or Not Available in the Salesforce Mobile App (Productivity Features) —

Yes - we wanted just one license to try it out and the request for a temporary/courtesy license was refused. The only offer was to buy a few at full retail price - it took several days of working with Salesforce Support before they found that it's effectively non functional until we staff of to do the work ourselves... at which point I figure it might be simpler to just build our own custom Android/iOS App leveraging briefcases and save all the cost of the "Mobile+" license. 

I support users around the world where there's low connectivity; but even in the US there is "airplane mode" that is necessary regularly. Offline access is not an edge case. It's a core use case.  

Meanwhile Field Service Mobile works offline and even has offline flow capabilities - but has it's own licensing cost that's prohibitive outside of it's primary use cases.

@David Hastie

Reiterating 3 years later. I have license, system permission, briefcase assigned to my user and profile, Salesforce for Android app assigned to briefcase. Briefcase Run As User shows that the briefcase is assigned to my user.  

But when in Salesforce mobile app in Offline Mode, the only records that sync are Assets. Everything else says "We hit a snag. We couldn't download your records." 

The downloadable app logs show that only recently viewed records are fetched and it says 

"usingBriefcase":false