Forms integrations and automation

POM Forms can send files to Google Drive, call a webhook, and create WordPress content from a submission. Add automation only after the form's fields, consent, notifications, and error behavior work correctly.

Choose the right destination

One form can use more than one destination. Document every copy of the submitted data in the site's privacy and retention process.

Google Drive uploads

Configure the Google account and OAuth client under Settings → POM Theme → Integrations → Google Drive, then add a Google Drive Upload field to the form.

Use this when files should go directly to an approved Drive folder rather than the WordPress Media Library. See Google Drive uploads for POM Forms for the complete setup and go-live checklist.

Webhooks

A webhook sends the submission to a URL controlled by another service or integration.

Configure a webhook

1. Open the form under Forms → All Forms.
2. Open Webhook.
3. Enable webhook delivery.
4. Enter the HTTPS endpoint supplied by the receiving service.
5. Configure Secret Key when the receiver can verify the X-POM-Forms-Signature HMAC.
6. Save the form.
7. Submit a non-sensitive test and verify that the receiver returns a successful 2xx response.

Use a dedicated production endpoint. Do not paste temporary inspection URLs into a published form.

Webhook safety

• Use HTTPS.
• Share the secret through an approved secure channel.
• Verify signatures on the receiving service.
• Accept only the fields that the destination needs.
• Decide how retries or duplicate deliveries are handled.
• Do not place credentials in a visible field or URL.
• Treat the successful form message and successful external processing as separate outcomes. Webhook failure does not replace the visitor response automatically.

Create WordPress content

The Create Post tab maps submitted values to a WordPress post or supported custom post type.

You can configure:

• post type;
• title, content, and excerpt;
• initial status;
• author;
• custom fields;
• taxonomy terms.

A safe review workflow

For public forms, create content as Draft or Pending Review unless automatic publication is explicitly required and every submitted value is trusted and moderated.

1. Choose the post type.
2. Map a required field or merge-tag template to the title.
3. Map the body fields to content or excerpt.
4. Choose Draft or Pending Review.
5. Map only approved custom fields and taxonomies.
6. Submit realistic tests, including missing optional values.
7. Review the created post in WordPress.

Changing a source field name can break a mapping. Review this tab whenever the form layout changes.

Hidden contextual values

A Hidden field can add context such as a campaign, referring section, or predefined category. Hidden values are submitted by the browser and should not be treated as proof of identity, authorization, payment, or another security-sensitive fact.

External action URLs

Under Messages/Behavior → Submission Behavior, Form Action URL (GET) and Form Action URL (POST) forward validated values to an external endpoint instead of running the internal POM action pipeline. They bypass storage, notifications, the Webhook tab, Google Drive uploads, and post creation.

Use these modes only when the external destination owns the entire workflow. Use the Webhook tab when POM should continue handling storage and other actions.

Design for failures

For every external integration, decide:

• what the visitor sees if the destination is unavailable;
• whether the submission is also stored or emailed;
• who monitors failed processing;
• whether retrying could create duplicates;
• how a test can be performed without using real personal data.

Runtime configuration for developers

Trusted plugins can adjust a normalized form configuration for the current request through pom_forms_runtime_config. The filtered value is not written back to the form, so the form builder remains the source of truth.

Use pom_forms_before_submission_config when the override must apply only to an actual form submission. The action runs immediately before POM Forms resolves the saved configuration for its internal submission pipeline.

add_action(
    'pom_forms_before_submission_config',
    static function (int $form_id): void {
        $GLOBALS['my_integration_active_form'] = $form_id;
    }
);

add_filter(
    'pom_forms_runtime_config',
    static function (array $config, int $form_id, bool $resolve_message_defaults): array {
        if (
            123 !== $form_id
            || ($GLOBALS['my_integration_active_form'] ?? 0) !== $form_id
        ) {
            return $config;
        }

        $config['store_submissions_override'] = false;

        return $config;
    },
    10,
    3
);

Use this filter only for request behavior owned by a trusted server-side integration. Do not use it to persist editor changes. The filter receives the form ID and whether message defaults were resolved for the current caller.

Plugins that need form-specific controls can render their own secured settings after the builder through pom_forms_builder_after_app. The action receives the form ID and its WP_Post object, or zero and null before the form's first save.

Related guides

• Notifications, submissions, and retention
• Google Drive uploads
• Programmatic forms for developers
• Forms troubleshooting