Goal

Use a Gravity Form to back an in-app feature — for example, a Contact Us screen, an Offer Submission form, or a Listing Edit form. After this recipe, app users will see the form rendered natively, submitted entries will appear in Forms → Entries, and the form’s configured notifications will fire.

Prerequisites

• Plugin activated per Recipe: Activate the plugin
• WP admin access
• A MAM feature plugin that consumes Gravity Forms (e.g. mam-special-offers, mam-geodirectory, or mam-contact-form on its GF path) — without one, there is no MAM dropdown to attach the form to
• A clear idea of which fields the form needs

How the wiring works

The plugin appends every active Gravity Form to MAM’s internal forms list via the mam_form_manager_get_forms_from_plugins filter. Any feature plugin that asks “which form should we use?” pulls from that list and shows the form names in a dropdown.

When a user submits the form in the app, the request travels through MAM Suite’s form pipeline. At the end of that pipeline, MAM fires mam_form_manager_send_notifications. This plugin’s handler then:

1. Calls GFAPI::add_entry() to create a real Gravity Forms entry.
2. Calls GFAPI::get_entry() to re-fetch it cleanly.
3. Calls GFAPI::send_notifications() to trigger every notification configured on the form.

To the WordPress site, the result is indistinguishable from a web submission. To the mobile app, the form behaves like a native MAM form.

Steps

1. Build the Gravity Form

Go to Forms → New Form in Gravity Forms and add the fields you need. A few practical notes:

• Field labels become field titles in the app. Use clear, user-facing labels — the app renders them verbatim.
• Admin Field Label is fine. It only affects the WP admin entry view; it does not surface in the app.
• Use field types the MAM renderer understands. text, textarea, email, phone, number, date, select, radio, checkbox, and hidden are all reliable. Exotic field types (CAPTCHA, signature, list, repeater) may not render or may render with reduced fidelity.
• Required fields. Mark them required in GF; the app’s renderer respects the GF required flag.

Save the form. Note its Form ID (visible in the URL: ?id=42) — you may need it for verification.

2. Configure notifications

Under Settings → Notifications on the form, add any admin or user notifications you want. These fire automatically on app submissions because the plugin calls GFAPI::send_notifications() after add_entry(). You don’t need to do anything app-side to enable notifications.

If you want different notifications for app submissions versus web submissions, gate them inside the GF notification’s Conditional Logic — for example, on a hidden field that the app populates and the web form leaves blank.

3. Attach the form to the MAM feature

Go to Mobile App Manager → App Settings, pick the role, and find the dropdown for the feature you’re wiring. The dropdown label depends on the consuming plugin — examples:

Select your form by name. Save the role.

4. (If applicable) Map the form’s fields

Some consumers — Special Offers, GeoDirectory, Contact Form’s GF path — also need to know which GF field corresponds to which app field slug (e.g. “this GF field is the Offer Title; that one is the Offer Description”). This mapping is registered in code via Hook: mam_gf_get_form_settings and is usually shipped by the consumer plugin itself. Out of the box, you don’t need to write any code — the consumer’s defaults usually match a sensible field layout.

If your form’s field IDs don’t match the consumer’s expected layout, check the consumer’s documentation for its required slug→GF index mapping and align your form, or write a small custom callback (see Hook: mam_gf_get_form_settings).

5. Verify

Open the mobile app for a user in the role you configured:

1. Navigate to the feature.
2. Confirm the form renders with all the fields you defined.
3. Submit the form.
4. In WP admin, open Forms → Entries for that form. Confirm a new entry appears.
5. Check the notification email, if one is configured.

Common gotchas

• Form not in the dropdown. The list is built from GFAPI::get_forms(). If your form is in the trash, deactivated within GF, or the GF plugin itself is deactivated, the form will not appear. Empty dropdown across all forms → see Recipe: Activate the plugin.
• Submission succeeds but no entry appears. This usually means GFAPI::add_entry() returned a WP_Error. The plugin logs an admin alert via mamdebug in this case (TD-GF-003). Check the MAM debug log for GFAPI::add_entry failed: lines — common causes are missing required fields the app didn’t send, or field validation failing on a calculated field.
• Entry created but no notification email arrived. Check spam, then confirm the notification’s Send To is correct and that the notification’s Conditional Logic is satisfied by the submitted values. The plugin always calls GFAPI::send_notifications() if add_entry() succeeded; it does not filter which notifications run.
• Renaming the form does not break the wiring. The MAM dropdown stores the Form ID, not the form title. You can rename freely.
• Deleting and re-creating the form does break the wiring. A new form gets a new ID. You’ll need to re-pick it in the role’s dropdown.

Variations

Treat the same form as both an app form and a web form

If the form should also be fillable on the WP site, no extra work is needed for app behavior — but if you also want web submissions to do something (create a CPT post, route to a feature handler), you need a consumer subscribed to mam_for_gravity_forms_web_form_result_form_{form_id}. See Recipe: Route a web submission to a custom post type.

Use the form’s field mapping in code

If you’re building your own consumer plugin and need to read app-submitted values out by slug, see Hook: mam_gf_get_form_settings for the mapping format.

Verification

This article was last verified against:

• Plugin: mam-gravity-forms-manager v2.3
• Gravity Forms (required)
• Reference consumers: mam-special-offers, mam-geodirectory, mam-contact-form

Re-verify whenever the mam_form_manager_get_forms_from_plugins filter contract changes, the mam_form_manager_send_notifications action’s ($entry, $form) signature changes, the add_entry → get_entry → send_notifications order in mam_gravity_forms::mam_form_manager_send_notifications() changes, or a consumer plugin renames its Form dropdown labels.

Related articles

• Plugin overview: mam-gravity-forms-manager
• Recipe: Activate the plugin
• Recipe: Route a web submission to a custom post type
• Hook: mam_gf_get_form_settings
• Hook: mam_for_gravity_forms_web_form_resultform{form_id}

Metadata