Purpose

Per-form result-envelope filter. Fires after a submission completes, lets a sibling plugin shape the JSON envelope returned to the app for that specific form id.

This is the typical per-form override pattern — bind by form id baked into the filter name.

Signature

$result = apply_filters(
    'mam_for_gravity_forms_form_result_form_' . $form_id,
    array $result,
    array $entry,
    array $form
);

Returns: array — the shaped envelope.

Result envelope shape

array(
    'status'   => 'success',                  // 'success' | 'failure'
    'message'  => 'Thanks for submitting!',   // user-facing copy
    'redirect' => '/thank-you',               // optional — button id or URL to navigate to
    // arbitrary per-form additional keys:
    'data'     => array( ... ),
)

Example: redirect to a confirmation screen for form 42

add_filter( 'mam_for_gravity_forms_form_result_form_42',
    function ( array $result, array $entry, array $form ): array {

        if ( ( $result['status'] ?? '' ) !== 'success' ) {
            return $result;
        }

        $result['redirect'] = 'btn_confirmation_screen';
        $result['message']  = 'Your application was received — check your email.';

        return $result;
    },
    10, 3
);

Variants

After this per-form filter fires, the pipeline also fires the generic versions:

$result = apply_filters( 'mam_for_gravity_forms_form_result',    $result );
$result = apply_filters( 'mam_for_gravity_forms_form_result_v2', $result );

Per-form > generic > v2. Don’t subscribe to all three for the same form — subscribe to the most specific.

When to use

Per-form result filters are the right place for:

• Custom redirect logic for a specific form
• Custom success messages that depend on submitted data
• Conditional failure overrides (e.g., “valid GF submission, but my plugin’s business rules reject it”)
• Custom data added to the envelope that the app should know about

For post-submission side effects (notifications, persistence to other tables), use mam_for_gravity_forms_form_submitted_{form-id} instead — that fires before result-envelope shaping.

Gotchas

• Form id is in the filter name. Don’t try to dispatch on form id inside a generic-name filter; use the dynamic per-form name.
• Returns get chained. The generic mam_for_gravity_forms_form_result filter runs after this one — anything you set can be overwritten.
• Don’t fire notifications from here. Use mam_form_manager_send_notifications (which runs after result-envelope shaping).
• status = failure with no message produces a confusing UX. Always set a user-facing message.

Related articles

• Form submission lifecycle
• Forms manager overview
• Hook: mam_for_gravity_forms_formsubmitted{id}
• Hook: mam_form_manager_send_notifications

Metadata