Goal

A form in your app can act up in one of two ways:

• It shows stale fields — you edited the form (added a field, changed a label, fixed a typo, changed the colors), but the app still renders the old version.
• It won’t submit — the user taps Submit and nothing happens, the form re-appears, or they get an error instead of the confirmation.

Here’s the order worth checking these in, and how to confirm each cause as you go. A MAM Suite form has more moving parts than a plain WordPress form — a cache layer, a required-field validation pass, optional phone-code gating, and (on the Gravity Forms path) a live dependency on Gravity Forms — so which one’s misbehaving is what determines the fix.

Prerequisites

• Admin access to Mobile App Manager for the affected app.
• The app installed on a device or simulator where you can reproduce the problem.
• Knowing which form is affected and what you expect to see or happen.
• For the deeper checks: developer access (PHP, WordPress options) or someone who has it. The admin-facing steps are called out as you go.

Background: how an app form actually works

Three facts about MAM Suite forms explain almost every report.

1. Form definitions are cached. Your app doesn’t read your Gravity Forms (or built-in) form live every time it launches — to keep things fast, the transformed, mobile-ready shape of each form is cached server-side, keyed by the form id plus whatever settings affect its output. Until that cache clears, the app keeps serving the old shape, which is why an edit can look like it “didn’t take.”

2. Submitting runs a validation pass. When someone taps Submit, their submission is POSTed to the server, each field gets processed, and the form has to pass validation — required fields, formats, lengths — before it’s accepted. Separately, certain forms — most importantly the initial form to display, which can gate entry to the app (a registration or profile form) — get re-checked on the way out: a late pass confirms the signed-in user filled every required field, and if they didn’t, it pushes the form back in front of them. So a form that “won’t go away” is usually just this gate doing its job.

3. The Gravity Forms path has a live dependency. If you built your form in Gravity Forms rather than the built-in handler, the app depends on both Gravity Forms and the Mobile App Manager Gravity Forms Manager bridge plugin being active. The bridge is what feeds your Gravity Forms into the MAM form registry — if it can’t fetch the form, submission processing returns an error instead of a confirmation.

Keep these three in mind as you work through the steps.

Steps

1. Identify which symptom you have

Figure out which bucket you’re in before doing anything else — the causes are different for each:

• Stale fields / old form (you edited it, app shows old) → start at Step 2.
• Won’t submit (taps Submit, gets nothing, an error, or the form reappears) → skip to Step 4.

2. Confirm the edit actually saved on the form itself

Before you blame the cache, make sure the edit actually stuck. Open the form in its editor (Gravity Forms, or the form’s admin page for the built-in path) and confirm your change is really there after a fresh page load — not just immediately after you clicked save. If the edit didn’t stick, that’s a save problem, not a cache problem; re-make it and confirm it persists before going on.

If the edit saved correctly but the app still shows the old version, it’s almost certainly the form cache — continue.

3. Clear the stale form cache

Normally the form cache clears itself the moment you save the form. When it doesn’t, the app keeps serving the old shape — and the usual trigger for a missed invalidation is a change made outside the form editor itself: a per-field special-handling toggle, theme colors, or some other setting that affects the form’s output but was never wired to clear the cache.

Here’s how to confirm it’s a cache problem and clear it:

• Admin-facing first: make the app re-fetch its data — fully close and relaunch it (backgrounding it isn’t enough), and sign out and back in if needed. If the new form shows up after a full relaunch, the server-side cache had already rebuilt and the app was just holding onto old data. If it still shows the old form after a clean relaunch, the server-side cache itself is stale.
• Developer-facing: clear the cached definition for that one form. MAM Suite keeps per-form cache entries keyed by form id, so deleting the entry for the affected form forces it to rebuild on the next phone-data pass. If that fixes it immediately, the real bug is a missing invalidation for whatever you changed — note which toggle, color, or setting it was so it can be wired up properly.

Tip: one stuck form is a one-off cache clear. If forms across the app frequently lag behind edits, that points at a missing invalidation trigger for a specific setting, not a broken cache in general — capture the exact setting and report it rather than clearing the cache over and over. See Form cache and invalidation.

If the form now renders correctly but the user still can’t submit, continue to the submission steps.

4. For “won’t submit”: check required fields and the gating form

When Submit seems to do nothing, or the form just reappears, the most common cause is failed validation — a required field that got left empty, either by the user or by the app’s pre-fill.

• Walk through the form and confirm every required field has a value. For a signed-in user, several fields (name, email, phone) are pre-filled from their WordPress profile — if the profile is missing one of those, the pre-fill comes back blank and the corresponding required field fails silently.
• Pay special attention to the name field: it’s split into first and last name, and if the field is required, both parts must be filled. A profile with a first name but no last name will fail the required check.
• If this is the registration or profile form that gates entry to the app, know that it’s deliberately re-checked on every relevant request. A late validation pass confirms all required fields are filled; if any required field is empty, the form is pushed back in front of the user instead of letting them through. That’s why such a form can feel impossible to dismiss — the user is just missing a required value. The fix is to fill in that field, not to bypass the form.

If every required field genuinely has a value and submission still fails, continue.

5. For phone-verified forms: check the phone-code gate

If the form has a phone field set up for code verification — the field that texts the user a code to confirm their number — submission is gated on that step. Here’s where it commonly breaks down:

• The SMS never arrives, so the user has no code to enter. This depends on a working SMS provider (typically Twilio) being configured for the app, and on the recipient having a valid, reachable phone number. If SMS isn’t configured, the code send can fail quietly and the user is left unable to complete the form.
• The number was entered in an unexpected format. The phone manager normalizes input, but for international or mixed-locale audiences it’s most reliable when the country code is included. If verification keeps failing for some users, have them include the full country code.
• The code expired. Codes are short-lived — they expire about 30 minutes after they’re issued. Within that window a “resend” hands back the same code, but once it expires a fresh code is generated and the old one no longer works, so a user typing in an expired code will fail.

If the form has no phone-verification field, skip this step. See Phone validation for the full flow.

6. For Gravity Forms-backed forms: check connectivity

If you built the form in Gravity Forms rather than the built-in handler, the app depends on two plugins staying active: Gravity Forms itself and the Mobile App Manager Gravity Forms Manager bridge. If either is deactivated, or the form id the app references no longer exists in Gravity Forms, the bridge can’t fetch the form — and submission processing returns an error instead of a confirmation.

Confirm:

• Gravity Forms is active and the form still exists with the same form id the app is configured to use.
• The Mobile App Manager Gravity Forms Manager bridge plugin is active. If it’s missing, form fetches come back empty and submissions error out.
• The form id wired into the app’s settings (for example, the contact form’s stored form id) still points at a real Gravity Forms form. A deleted-and-recreated form gets a new id, so the app ends up pointing at nothing.

If you’re on the built-in form handler, with no Gravity Forms in the mix, skip this step.

7. Capture details if it still fails

If you’ve ruled out the cache, confirmed every required field is filled, cleared the phone-code path, and verified Gravity Forms connectivity, what’s left lives in the submission handler itself — and that needs a developer to trace. Capture:

• The form (and form id) affected.
• Whether it’s the built-in or Gravity Forms path.
• The exact symptom (no response, error text, or the form reappearing).
• Whether the user is signed in, and whether their profile is complete.
• Any error message shown to the user.

Then hand it to a developer or open a support ticket.

Quick reference: which cause is it?

Related

• Form cache and invalidation — why a form goes stale and how the cache is keyed and cleared.
• Form submission lifecycle — the end-to-end path from Submit to confirmation.
• Phone validation — how phone-code verification gates submission.
• Plugin: mam-contact-form — the built-in vs. Gravity Forms setup paths.
• My settings change isn’t showing up in the app — for the related “settings didn’t update” case.

What’s next

If it was one stale form, clearing its cache and confirming the edit is the whole job. If forms across the app keep lagging behind edits, that’s a missing cache-invalidation trigger for a specific setting — track down the setting and report it so it can be wired to invalidate the cache, rather than clearing the cache by hand each time. And if submissions still fail with every required field filled and Gravity Forms healthy, the issue lives in the per-form submission handler — that one’s for a developer.