Goal

Allow a single contact form to route submissions to different notifications depending on what the user is contacting you about — for example, Sales inquiries go to sales@, Support requests go to support@, Billing questions go to billing@.

This recipe applies to both the default path and the Gravity Forms path. The setup steps are identical once you’ve reached the Contact Form admin page.

Prerequisites

• A working contact form set up per Recipe: Setting up a contact form (default path) or Recipe: Setting up a contact form with Gravity Forms
• WP Admin access
• Notification email addresses for each reason type you want to support

How it works

When you add a Contact Reason field to the contact form, mam-contact-form reads the user’s selection at submission time and fires the matching notification you’ve configured. Each reason choice maps to one Gravity Forms notification.

The mapping is stored in WordPress options keyed:

mam-contact-form_{form_id}_{reason_field_id}_{choice_key}

The Contact Form admin submenu only appears when the option mam-contact-formcontact_form_reason is set — that is, after the Contact Reason field has been mapped on the Gravity Forms side. If you don’t see the Contact Form submenu, finish the mapping step from your setup recipe first.

Steps

1. Add a Contact Reason field to the form

In Forms → [your contact form] → Edit, add (or convert) the Contact Reason field:

• Type: Drop Down (or Radio Buttons)
• Label: Contact Reason (or whatever you’d like users to see)
• Choices: one entry per reason type — for example, “Sales”, “Support”, “Billing”

Save the form.

2. Map the field as the Contact Reason field

Open the field’s settings, switch to the Mobile App tab, and mark the field as the Contact Reason field for this form. Save.

This mapping writes the option mam-contact-formcontact_form_reason with the GF field ID. The plugin uses that to look up the field’s choices at submission time.

3. Create a notification for each reason

In Forms → [your contact form] → Settings → Notifications, create one notification per reason type. Give each a clear name (e.g., “Sales inquiries”, “Support requests”). Set the Send To Email to the address that should receive that reason’s submissions.

You do not need to configure Gravity Forms conditional logic on the notifications — mam-contact-form handles routing.

4. Map reasons to notifications

Go to Mobile App Manager → Contact Form. You will see a row for each choice in your Contact Reason field. For each row, select the notification that should fire when a user picks that reason. Save.

The save handler verifies a nonce (mam_contact_form_save) and then iterates the form’s reason choices, writing one option per choice. Re-saving the page is idempotent — only mappings that change are rewritten.

Verification

1. Open the app, go to the contact form, and submit one entry per reason type using distinct test data.
2. Confirm each test arrives at the correct destination email and only that destination.
3. Confirm entries appear in Forms → [your form] → Entries with the Contact Reason field populated.
4. If you have a mam_contact_form_contact_processed listener, confirm it fires once per submission with the expected $values['reason'].

Gotchas

• One notification per reason. The plugin fires exactly one notification based on the reason. If you also want a catch-all “send a copy of every submission to admin@”, add that as a separate Gravity Forms notification with no conditional logic — Gravity Forms will fire it independently.
• Unmapped reasons fall through. If a reason has no notification mapped, no notification fires for that submission. The form entry is still saved.
• Renaming choices breaks mappings. The choice key ($ckey) is derived from the choice’s position/text in Gravity Forms. If you rename a choice, the mapping resets for that choice. Re-map after any rename.
• No admin submenu = unmapped reason field. The Contact Form submenu page hides itself when mam-contact-formcontact_form_reason is empty. Map the field first.
• Anonymous users are still rejected on the default path. The reason routing only fires for signed-in users; anonymous submissions short-circuit before the message is built.

Related articles

• Plugin: mam-contact-form
• Recipe: Setting up a contact form (default path)
• Recipe: Setting up a contact form with Gravity Forms
• Hook: mam_contact_form_contact_processed — for custom routing logic beyond what the UI supports

Metadata