#Mobile21 diskutieren mit

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.

Hi Erkan - short version: MobilePush in-app message templates don't have a native countdown-timer widget, so a real-time ticking timer comes down to either custom HTML/JS or letting the app render it. The options, best-to-quickest: 

1. Custom HTML in-app message with JavaScript (best for a true real-time timer). MobilePush lets you use custom in-app content, so you can drop in a small countdown that runs client-side - a setInterval that ticks down to your offer's end timestamp and updates the display every second. That gives you an actual live, second-by-second timer inside the message. Pass the end time in (or set it per campaign) and the JS counts down to it. 

2. App-side native rendering (most robust). Because in-app messages are drawn by the MobilePush SDK inside your app, the most reliable approach is to send the offer's end timestamp as a custom key/payload on the message and have your app's own code render a native countdown UI. Sturdiest for a real-time timer, but it needs your mobile dev team. 

3. Dynamic countdown GIF as the message image (quickest, lowest-dev). Services like NiftyImages or Sendtric generate an animated countdown GIF from a target date, and you use that as the in-app image. Fast, no code - but two caveats for in-app: animated-GIF rendering isn't guaranteed across every in-app SDK/OS, and images can be cached or pre-fetched, so it's more of a 'looks like it's counting' animation than a guaranteed-accurate live clock. Great for email, a bit less dependable in-app. 

For flash sales, I'd go with option 1 (custom HTML + JS) if you want a genuine real-time countdown a marketer can manage, or option 2 if you want it rock-solid and have app-dev support. Option 3 is the fast path if a close-enough animated countdown is acceptable. 

One tip whichever you pick: drive the timer off the offer's actual end timestamp (not a duration from open), so it stays accurate no matter when the user sees the message. 

Hope that helps!