Goal

You changed a setting in Mobile App Manager, hit save, and the app running on your phone still shows the old value. It’s frustrating, but almost always fixable in a couple of minutes. This article walks through the three usual causes — in the order worth checking them — and how to make the app pick up your change.

Here’s the short version up front: your setting almost certainly did save. What you’re running into is one of two things — either the app is showing you cached data it hasn’t re-fetched yet, or the value got saved against the wrong role, so the user you’re testing with is still falling through to the old global value.

Prerequisites

- Admin access to **Mobile App Manager** for the affected app.

• The app installed on a device (or in a simulator) where you can reproduce the problem.
• Knowing which setting you changed and what value you expect to see.

Background: why a saved setting can look “stuck”

Two things about how MAM Suite works explain nearly every “it didn’t change” report you’ll ever see.

1. The app runs on cached data. Your app doesn’t check your WordPress options live, the way a web page would. When it launches, it fetches one bundle — the phone data payload, meaning the package of settings and content the server builds from your current configuration — and everything you see in the app is rendered from that bundle. Until the app goes back for a fresh copy, it just keeps showing you whatever it loaded last. So the setting you just saved won’t show up until the app fetches phone data again.

2. Settings cascade from a global default down to per-role overrides. Every time the app reads a setting, it checks in a specific order: first for a value saved against the signed-in user’s role, and only if there isn’t one, it falls back to the global value (internally the mam-all role). Which means the same setting can have two stored values at once — one per-role, one global — and the app shows whichever one applies to the person you’re testing with. Edit the global value while your test user has a role-specific override sitting on top of it, and your edit is real, it’s saved, it’s just invisible to that user.

Worth holding onto both of these as you work through the steps below.

Steps

1. Confirm the value actually saved

First, rule out the simplest explanation. Go back into Mobile App Manager and re-open the setting you changed. Confirm the field shows the new value after a fresh page load — not just in the moment right after you clicked save.

- If the field has reverted to the old value, the save didn't take. Re-enter it, save, and reload the settings page to confirm it sticks before going further. A save that won't stick is a different problem from a cache problem — stop here and treat it as a save failure.

• If the field shows the new value, the setting saved fine. The problem is downstream — keep going.

2. Check the role you saved against

This is the single most common cause of all, so check it before you touch anything related to caching.

If your app uses roles — you’ll know because the settings page shows a role selector above the settings — values can be saved per role, and that’s usually where things go sideways. Confirm two things:

- **Which role was selected** when you saved the change. A value saved while a specific role was selected applies *only* to users in that role.

• Which role the test user has. The app shows each user the value for their own role, falling back to the global default when no role-specific value exists.

If those two don’t match, you’ve found your answer. Now decide whether you meant to change the value for all users or just one role:

- To change it for everyone, select the **global / all-roles** option in the role selector, set the value there, and save.

• To change it for one role, select that role, set the value, and save — then test with a user who actually has that role.

Note: a per-role value always wins over the global value for users in that role. Changing the global value won’t override a role that already has its own saved value sitting on top of it. If you want a role to fall back to the global value again, you’ll need to clear that role’s value directly — changing the global one alone won’t do it.

If your app doesn’t use roles at all, every value is effectively the global value, and you can skip this step entirely.

3. Force the app to re-fetch its data

If the value saved correctly and the role checks out too, the app is simply holding onto cached data. Here’s how to force it to go get a fresh copy:

- **Fully close and re-open the app.** Don't just background it — close it completely (swipe it away) and relaunch. Backgrounding often resumes from the cached bundle without re-fetching.

• If the change still doesn’t appear, sign out and back in, which forces the app to rebuild its data for the current user.

If the change shows up after either of these, nothing was ever actually wrong — the setting was right all along, the app was just holding old data.

4. If users keep seeing stale settings, turn on Force Reload on Open

Steps 1 through 3 will fix a one-time stuck change. But if your app regularly needs settings to take effect right away, and asking users to fully relaunch every time isn’t realistic, there’s a setting built for exactly that: it makes the app re-fetch on every open.

In Mobile App Manager, find Force Reload on Open (a Yes/No setting in the general settings) and turn it on. With it on, the app fully reloads its configuration and content every time it’s opened, instead of leaning on cached data. From then on, your saved settings reach users the next time they simply open the app — no manual sign-out, no reinstall needed.

There’s a related option, Reload on each home screen action, which reloads the home screen each time the user navigates back to it. This one is narrower: it refreshes home-screen content only, not the whole configuration bundle. So it’s the right fix for stale home-screen content specifically, but it won’t solve a general “my setting didn’t apply” problem.

Trade-off: turning this on removes the caching that makes app launches feel fast. Every open re-fetches the full bundle, so launches get slower and the app uses more data. Turn it on when getting fresh settings matters more than launch speed to you; leave it off (the default behavior) for apps where launch speed matters more and settings rarely change.

5. If it’s a form that’s stale, not a setting

One more thing worth ruling out: if what “won’t change” is actually a form — a registration, profile, contact, or listing form still showing old fields, colors, or behavior after you edited it — you’re looking at a different mechanism entirely. Forms are cached separately from app settings, and that cache clears on its own triggers (a form save, for instance). A form still showing its old version after an edit usually just means that cache wasn’t cleared for that particular form. Sorting that out is outside the scope of this article — see the related form-cache reference below, or contact support if a form edit isn’t taking.

Quick reference: which cause is it?

Related

- *App Setting Reference: Force Reload on Open*

• App Setting Reference: Reload on each home screen action
• Form cache and invalidation (for stale forms specifically)
• App settings overview — the settings cascade and how reads resolve

What’s next

If you’ve confirmed the value saved, confirmed it’s saved against the right role, and a full app relaunch still won’t show it, you’re past caching and cascade issues — something else is going on. At that point, jot down the setting name, the value you saved, the role you saved it under, and the role of the user you tested with, and open a support ticket so we can trace it through the phone-data build.