Alright, let's get the obvious out of the way: the ServiceNow GRC mobile app is, charitably, a "companion experience." Lately, however, it seems to have taken the concept of eventual consistency to a whole new, and frankly unacceptable, level of philosophical interpretation.
Our security team has been flagging a persistent and dangerous issue where the mobile app is displaying mitigation plans that are days, sometimes a full sprint cycle, out of date. The browser interface on desktop will show the approved, current state of a risk with its corresponding mitigation tasks and owners, but several of us, on different devices and OS versions, are seeing the previous quarter's plans. This isn't a minor UI lag; we're talking about referencing control procedures that have been deprecated and task assignments to individuals who have rotated off the program.
Before we get the standard "clear your cache" or "check your version" response from anyone who might be lurking here, we've done the dance. We've uninstalled, reinstalled, toggled every sync setting we can find, and verified our instance is on the latest supported Madrid patch. The problem is intermittent but widespread enough across our user base that it points to something deeper in the data-fetching or caching layer of the mobile app itself.
What I want to know is if this is just our instance being blessed with a unique flavor of chaos, or if others are seeing this silent divergence between the mobile and primary interfaces. More concretely:
* Is the app fetching from a different endpoint or using a different query that might be subject to aggressive, non-invalidated caching?
* Has anyone traced the network calls from the mobile app to see if it's even requesting the correct table updates, or if it's pulling a stale `sys_audit` snapshot?
The risk here is operational and tangible. An auditor or a CISO checking a status on the go is making decisions based on incorrect data. That moves this from a nuisance bug to a potential compliance finding. I'm skeptical of any "mobile-first" claims if the foundational data integrity can't be guaranteed across platforms. If you've encountered this, what, if anything, did you uncover or get from support? The release notes for the mobile app are rarely illuminating, buried in vague "performance improvements."
-- Cam
Trust but verify.
Your mention of the mobile app being a "companion experience" is the core of the issue, I suspect. That term often signals a separate, simplified data pipeline optimized for offline use, not a real-time mirror of the desktop interface. The discrepancy you're seeing isn't lag, it's likely a deliberate, poorly implemented caching strategy where the mobile sync cycle is decoupled from the web client's real-time updates.
Have you checked if the outdated data correlates with a specific mobile sync trigger, like opening the app versus a background refresh? I've seen similar architectures where the mobile app only fetches a full dataset on a manual "pull to refresh," while background updates only fetch delta changes, which can fail silently. The different OSes behaving the same way points squarely to a server-side API or sync configuration problem, not the client.
You've ruled out the client-side basics, so the next step is to instrument the actual data calls. Can you compare the timestamps or revision IDs in the mobile app's data payload against the desktop's? That would prove whether the stale data is being served from the mobile endpoint itself.
That sounds rough, especially with the security implications. When you say it's widespread across different devices, does that mean it's hitting everyone on your instance at the same time, or is it more random?
It makes me wonder about the mobile app's data architecture. Is it pulling from a separate reporting table or a cached snapshot that only updates on a schedule? In AWS, we sometimes see similar lag when a mobile backend uses a read replica with high replication delay. Could something like that be happening here?
Still learning