The user profile form is what a signed-in app user sees on their profile screen — the place they go to view and update their name, avatar, email, and anything else about their account you choose to collect. In MAM Suite, it’s just a regular Gravity Forms form: you build it in WordPress, attach it in App Settings as the User Profile Form, and then map it field by field so MAM knows which Gravity Forms field holds which piece of profile data.

That mapping step is really what this guide is about. Choosing the form is only half the job — until you point each MAM profile field at a Gravity Forms field, that field stays hidden in the app and won’t save anything the user enters. Here, you’ll build the form, attach it, map every field, and confirm the edits actually stick.

Looking for the broader “set up the whole profile screen” overview instead — avatar placeholder, Take Photo button, profile button colors? See Customize a user profile screen for your app. This article stays focused on the form itself and its field mapping.

Goal

A profile form that:

• Is built in Gravity Forms and selected as your app’s User Profile Form.
• Has each profile field you want (name, email, avatar, and — as an example below — a mailing address, phone, and company) mapped to the correct Gravity Forms field.
• Saves the user’s edits back to their WordPress account.
• Pre-fills with the user’s current values every time they open it.

Prerequisites

• MAM Suite installed with MAM Main activated.
• The MAM Gravity Forms plugin active, plus Gravity Forms itself. The form-picker and field-mapping UI only appear when MAM detects the Gravity Forms bridge — internally it checks for the mam_for_gravity_forms_forms_manager class before rendering the form list.
• Admin access to Mobile App Manager → App Settings.
• A general understanding of building a form in Gravity Forms (adding fields, setting field types).

Which fields MAM knows how to map

MAM ships with a fixed set of profile fields ready to map. Point one at a Gravity Forms field and MAM handles both directions: it pre-fills that field from the user’s stored data, and it saves whatever they submit back to the matching user meta. The table below lists one row per field, with the label and slug you’ll see in the mapping UI:

The slugs are just MAM’s internal names for these fields; the labels are what you’ll actually see in the mapping UI. The one thing to keep straight: each row in the mapping table corresponds to one of these profile fields, and your job is to point it at a Gravity Forms field.

Name, email, and avatar form the core of any profile. Address, Phone, and Company are optional extras — proof the form can go well beyond just a name and email address, but nothing you’re required to use. Map them only if your app actually collects that information; otherwise, leave them alone.

Any field on your Gravity Forms form that you don’t map simply won’t render in the app’s version of the profile form (MAM flags it internally with a “hidden” handling value). So the mapping table doubles as your control for which fields show up at all.

Steps

1. Build the form in Gravity Forms

Head to Forms in WordPress and create a new form for the profile. Add whatever fields you want users to edit — for a typical profile, that’s:

• A Name field (Gravity Forms’ name field, so first and last come through as a split input).
• Email.
• Optionally an Avatar/file-upload field for the profile photo.
• Any extra detail you collect — for example a Gravity Forms address field, a phone field, and a company text field.

Keep the field types sensible — an email field for email, a phone field for phone — so the app pulls up the right mobile keyboard for each one. Then save the form.

Only add the fields your app actually needs. A minimal profile is just Name, Email, and an avatar — the address/phone/company fields are there for apps that collect that extra detail, nothing more.

2. Attach the form as your User Profile Form

In App Settings, open the User Profile category and find the User Profile Form setting (stored under the option key mam_main_user_profile_form). It’s a simple picker listing your Gravity Forms forms — select the one you built in Step 1.

This one setting is doing double duty: it tells the app which form to render on the profile screen, and it registers that form’s submissions so they save as profile data. (Under the hood, MAM hooks the profile save handler to this exact form ID — so whichever form you pick here is the one whose edits actually stick.)

3. Map each MAM profile field to a Gravity Forms field

This is the step it’s easy to skip — and the reason fields mysteriously “don’t show up” later. For the User Profile Form, MAM gives you a field-mapping table: one row per MAM profile field (User Avatar, Email, Name, Display Name, Address, Phone, Company), each with a dropdown of the Gravity Forms fields on your selected form.

For every profile field you want live in the app, pick its matching Gravity Forms field from the dropdown:

• Name → your Gravity Forms name field
• Email → your email field
• User Avatar → your avatar/file-upload field
• Address → your Gravity Forms address field (as an example — one field covers street, city, state, and ZIP)
• Phone → your phone field
• Company → your company field (if used)

Each choice gets stored as its own option, named by tacking the slug onto the form’s option key — for example mam_main_user_profile_form_address, mam_main_user_profile_form_phone, mam_main_user_profile_form_company. Leave a row unmapped (or set it to “no field”) and that field is treated as hidden: it won’t render in the app, and nothing typed into it will save.

Map every field you added back in Step 1. The most common mistake is picking the form but only mapping Name and Email — anything else you added then quietly never shows up. If a field appears in Gravity Forms but not in the app, check this table for an unmapped row first.

4. Save

Save your App Settings. MAM rebuilds the form definition from your mappings on the next app payload — the bundle of data your app downloads from your site — so the app picks up the change on its next refresh.

5. Verify edits pre-fill and save

Now see it in action: reload the app (or trigger a JSON refresh), sign in as a test user, open the profile screen, and confirm:

• Pre-fill: the form opens already populated with the user’s current values. (A brand-new user may see these blank — set them once, then re-open to confirm they come back.)
• Mapped fields render: every field you mapped in Step 3 shows up, and nothing you meant to include is missing.
• Address validation: if you used an address field with a state dropdown, leaving it on the placeholder (“Select state…”) is rejected with a “Please select a state” message — confirm a real selection saves.
• Email rules: changing email to an address already used by another account is rejected; a valid, unused address saves and updates the WordPress login email.
• Save persists: after saving, re-open the form (or check the user in WordPress) and confirm the new values stuck.

Notes and gotchas

• Name is special. In the app, the name field is a split first/last input, and saving it writes to both the standard WordPress first_name / last_name fields and, for store compatibility, billing_first_name / billing_last_name. If there’s no display name set, MAM builds one from first + last.
• Email updates the login. Saving the email field changes the user’s actual WordPress user_email (after checking it’s valid and not already taken) — it’s not just a profile field, so this form can genuinely change how a user logs in.
• Address, phone, and company reuse WooCommerce user-meta keys. For historical reasons, those values land in the standard billing_address_1, billing_city, billing_state, billing_postcode, billing_phone, and billing_company user-meta keys. That’s just where MAM happens to keep them — the form itself is a general-purpose profile form, and it works fine even in apps with no store at all.
• Unmapped = hidden, not optional. There’s no separate “show this field” toggle — the mapping is the visibility control. Want a field gone from the profile? Unmap it. Want it back? Map it.
• Custom fields beyond this list — anything not in the table above — get added in code via the mam_add_fields_to_user_profile filter, with saves handled through mam_user_roles_save_addl_user_profile_field_{slug}. That’s a developer task; see the hook reference.

Related

• Customize a user profile screen for your app — avatar placeholder, Take Photo button, and profile/login button colors.
• Power your app forms with Gravity Forms — the general Gravity Forms bridge and field-mapping pattern this form uses.
• App setting: User Profile Form (mam_main_user_profile_form)
• Hook: mam_add_fields_to_user_profile — add custom profile fields in code.
• Hook: mam_user_roles_save_addl_user_profile_field — save a custom profile field.

What’s next

• Want to require a complete profile before someone can use the app? Set this same form as the Form to display when opening the app? setting, and MAM will present it on launch until every required field is filled in.
• Add an avatar placeholder and a Take Photo button so users can set their own profile photo — see Customize a user profile screen for your app.
• Need a field MAM doesn’t map natively? Add it with the mam_add_fields_to_user_profile filter.