Pro module40 abilities

Formidable ability reference

Reference for the GoBuildWP Pro 1.12.4 source. Installed schemas and policy remain authoritative.

This Formidable ability reference covers how an agent can build and edit Formidable forms and fields, manage email notifications and the on-submit action, bind a form to a style, and read, correct or remove entries. It also reaches Formidable's Stripe Lite payment records on a free install, and with Formidable Pro its Applications and subscription cancellation.

Read-only, write and destructive groups describe the source annotations. They do not establish a minimum safety profile, human approval or undo support. Those controls are separate: check the installed ability, the connected user and the active site policy before calling it. A read can still return sensitive data. These pages are not evidence that every operation passed an end-to-end runtime test.

What Formidable needs before these load

Formidable Forms must be active. The module loads whenever the FrmAppHelper class is present, with a per-site plugin check on multisite, so wppilot/formidable-check-setup is offered at any version and reports min_satisfied; the other calls register from Formidable 6.0.0, where the FrmForm, FrmField and FrmEntry surface settled. Pro calls also need FrmProDb::$plug_version at 6.0.0 or newer, licensed or not. Calls check Formidable's capabilities with current_user_can(): frm_view_forms, frm_edit_forms, frm_change_settings, frm_view_entries, frm_edit_entries and frm_delete_entries. A refusal is formidable_capability_missing (403).

Minimum (base)
6.0.0 WPPILOT_PRO_FORMIDABLE_MIN_VERSION
Minimum (pro)
6.0.0 WPPILOT_PRO_FORMIDABLE_PRO_MIN_VERSION
Formidable editions
free, pro
Agent skills shipped
formidable-integration, form-model-schema, form-model-migration

Where Formidable spreads a form

The form row sits in wp_frm_forms with its settings serialised in the options column, fields in wp_frm_fields, entries in wp_frm_items and each answer in wp_frm_item_metas. Email notifications and the on-submit action are form-action posts, styles are frm_styles posts, and Pro Applications are terms in the frm_application taxonomy. Payments and subscriptions have their own wp_frm_payments and wp_frm_subscriptions tables.

That split decides what can be undone. Writes to forms, fields and entries are recorded as irreversible because they land in the frm_* tables. An edited notification is a post, so the ledger keeps a before-image and wppilot/rollback-change can restore it; deleting a notification, a form action or an Application, and setting the on-submit action, stay irreversible. A style binding is not destructive: wppilot/formidable-apply-style reports previous_style_id so the old style can be applied again.

Entries without a trash state

wppilot/formidable-delete-entry removes the entry and its answers at once, with no undo. wppilot/formidable-set-entry-status changes is_draft, which marks a saved-for-later submission, not a deleted one. Entry-value edits merge existing answers through FrmEntryMeta::update_entry_metas and update the frm_items row directly; status changes also write that row directly. Both explicitly fire frm_after_update_entry, which notifies listeners without proving their downstream work completed, and answers can be addressed by field id or field_key; an unknown reference is refused with formidable_invalid_input. Forms behave differently: a delete sets status trash unless force=true, which also removes Repeater child forms, entries and form actions.

Entry reads key answers by field_key and redact password, card, upload and signature answers and the ip until include_sensitive=true with confirm=true. Formidable has no read or starred flags, so the export filters on is_draft and dates, and the list search matches an entry's item_key. The list stops at a pool of 5000 matches and sets pagination.truncated when it does.

Payment records without Pro

The transaction and subscription reads register when the Stripe Lite tables exist, Pro or not. wppilot/formidable-cancel-subscription needs Pro and changes the local row to cancelled without contacting Stripe, PayPal or Square, so use it once the cancellation has already happened at the gateway.

Representative call sequence

This sequence describes the documented calls and checks to perform. It is not a recorded result from an installed WordPress site. Inspect returned errors and partial results, then verify the saved values and affected output before proceeding.

Stop the newsletter form redirecting to an old page and show a thank-you message instead.

  1. 01 wppilot/formidable-list-forms Finds the newsletter form's numeric id.
  2. 02 wppilot/formidable-set-on-submit-action Sets the create event's on-submit action to type message with the new text, updating the existing redirect in place; created comes back false.
  3. 03 wppilot/formidable-list-form-actions Filtered to type on_submit, lists the form's on-submit action so its id can be read with formidable-get-form-action and the new message checked; formidable-get-form does not return actions. Then submit the form once on staging to see the message a visitor gets.

Questions about Formidable

Can I restore a Formidable entry the agent deleted?

No. Formidable entries have no trash, and the delete removes the wp_frm_items row and its answers. Export the entries beforehand if they might be needed.

Does cancelling a Formidable subscription stop the customer being charged?

Not by itself. It marks the wp_frm_subscriptions row cancelled and leaves the gateway alone, so cancel at Stripe, PayPal or Square as well.

Why does the agent see check-setup but no other Formidable tools?

Formidable is installed below 6.0.0. check-setup reports min_satisfied false in that case; updating Formidable registers the rest.

Formidable reads

AbilityWhat it does
wppilot/formidable-check-setupCheck Formidable SetupReports the Formidable Forms environment in one call: whether the free plugin is active and at the minimum supported version, whether the Pro add-on is loaded (and its version), whether the Stripe Lite payment surface is configured (wp_frm_payments table present), the current user's Formidable-native capabilities (view_forms, edit_forms, change_settings, view_entries, edit_entries, delete_entries), the install size (forms_total, entries_total), and the field-type catalog actually renderable on this site. Call this first before any other Formidable ability — the payments_supported flag and the capabilities map let the agent branch BEFORE invoking a surface that would otherwise return formidable_pro_required or formidable_capability_missing.
wppilot/formidable-export-entriesExport Formidable EntriesExport one form's entries as CSV or JSON with field labels as headers, via FrmEntry::getAll with metas. Filters: is_draft, date_from / date_to (created_at), search (any field value; the redacted password, card, file and signature fields are searched only with include_sensitive=true and confirm=true). Formidable has no starred / read flags. Up to 5000 rows per call (a ~200 KiB budget may stop sooner); pass next_cursor back as cursor until it is null. Password, credit-card, file-upload, signature and IP columns are [REDACTED] unless include_sensitive=true with confirm=true.
wppilot/formidable-get-applicationGet Formidable ApplicationReads one Formidable Pro Application by id. Returns id, name, slug, form_count, created_at, updated_at, AND the form_ids list (member form ids retrieved via FrmProApplication::get_forms_for_application). Pro-only.
wppilot/formidable-get-entryGet Formidable EntryReads ONE submission by id. With include_meta=true (default), the response includes a meta map keyed by field_key with the submitted values (Formidable stores them in wp_frm_item_metas). Long string values are truncated at max_field_bytes (default 8192) and the truncation paths are reported in truncations[] so you can re-fetch a specific field with a higher cap.
wppilot/formidable-get-field-types-schemaList Formidable Field TypesReturn the catalog of every Formidable field type this install can actually render — Lite types always, plus Pro types when Formidable Pro is active and the type is NOT an upsell for a separate add-on (entries with an addon key are filtered out). Internal-only types marked hide=true in the catalog (e.g. submit) are excluded so an agent never accidentally registers one via add-field. Output is compact: per entry {type, label, category, pro_only}. Use this FIRST when constructing a form, then call this same ability again with type set to one slug for the per-type detail; omit type to enumerate everything. A non-listed type returns formidable_invalid_input. Categories reflect the editor groupings: standard (single-value inputs and choice fields), structure (divider / end_divider / break / html / summary / captcha), payment (credit_card / product / quantity / total / coupon). Note: dropdown is an alias of select in Formidable's update path (FrmField::update at FrmField.php:742-746) — the catalog reports select only. Mirrors the catalog-vs-detail pattern used by gravityforms-get-field-types-schema, wpforms-get-field-types-schema, fluentforms-get-field-types-schema.
wppilot/formidable-get-formGet Formidable FormReads the full payload for a single Formidable form by id: the base row (id, form_key, name, description, status, parent_form_id, is_template, created_at), the decoded options blob (the serialized wp_frm_forms.options column — submit_value, success_msg, success_action, before/after/submit HTML, email_to, redirect, save_progress, etc.), and the compact field list (id, field_key, type, name, description, required, field_order, default_value, options, field_options). Per-field byte cap defaults to 8192; bump via max_field_bytes (256–65536) for long rich-text defaults. Use include to skip subsystems you don't need (['settings'] returns just the options blob; ['fields'] returns just fields). Action / style binding payloads ship from list-form-actions and apply-style — never from get-form.
wppilot/formidable-get-form-actionGet Formidable Form ActionReads the full payload for one form action of ANY type. Returns id, name, type, enabled, modified_at, and the decoded settings blob (verbatim - no whitelist filter, since the shape varies by action type). Pass action_id; the action MUST belong to form_id. Use this when you need to inspect a non-email action (wppost, webhook, payment, …) - for email actions, get-notification gives you the same payload with a curated key list.
wppilot/formidable-get-form-canonicalGet Formidable Form (Canonical)Reads a single Formidable form by id and returns it mapped to the plugin-agnostic form-model-schema vocabulary (17 canonical types: text/email/tel/url/number/textarea/date/time/datetime/select/radio/checkbox/file/hidden/submit/consent/group) used by the form-model-migration skill. Formidable native field types (~30 including Pro) fold onto those 17 - composites (name, address, divider|repeat) collapse to canonical group; structural-only types (divider, end_divider, break, html, summary, captcha) drop with informational warnings; Pro payment types (credit_card, product, quantity, total) drop with structural warnings. The form lives in wp_frm_forms (with the legacy options blob carrying success_msg / success_action / success_url); fields live in wp_frm_fields (one row each, loaded via FrmField::get_all_for_form). Notifications are frm_form_actions posts with post_excerpt="email"; the on-submit confirmation is a frm_form_actions post with post_excerpt="on_submit", falling back to the legacy options.success_* keys. Output keys: fields[] with canonical types, mail_config{} from the first published email action, notifications[] from the rest, messages{} (empty - Formidable has no built-in message catalogue), conditional_rules[] from per-field field_options.hide_field / hide_opt (mapped 1:1 when expressible), meta{} (source plugin + version + lossless form options echo), plus warnings[] for everything that does not fit the canonical shape (multi-page break, repeater sections, payment fields, captcha, custom redirects). Smart-tag syntax [FIELD_ID] and [field_key] inside subject / message / recipient is rewritten to [<canonical-name>] to match the CF7 / WPForms / Gravity / Fluent canonical convention. Honours the same max_field_bytes truncation contract as the other canonical readers (default 8192 bytes for mail_config.body, notifications[].body, with *_truncated flags); pass max_field_bytes: 0 to disable truncation when full-fidelity canonical is required before an execute-mode migration. Returns WP_Error formidable_form_not_found when the id does not exist or refers to a trashed form. Use this ability inside the form-model-migration workflow (Phase 2 - read source schema); for ad-hoc inspection outside the migration pipeline, prefer formidable-get-form which returns the Formidable-native shape.
wppilot/formidable-get-notificationGet Formidable NotificationReads the full settings blob for one email notification on a Formidable form. Pass form_id + action_id. Returns: id, name, enabled, plus the email settings (email_to, cc, bcc, reply_to, from, email_subject, email_message, plain_text, inc_user_info, event, conditions). Non-email actions are rejected — use list-form-actions for those.
wppilot/formidable-get-subscriptionGet Formidable SubscriptionReads one row from wp_frm_subscriptions by id.
wppilot/formidable-get-transactionGet Formidable TransactionReads one row from wp_frm_payments by id. Returns id, receipt_id, invoice_id, sub_id, item_id, amount, status, action_id, paysys, created_at, begin_date, expire_date, meta (decoded blob), test.
wppilot/formidable-list-applicationsList Formidable ApplicationsLists every Formidable Pro Application (terms in the frm_application taxonomy). Compact row per application: id, name, slug, form_count (cached on _frm_form_count term meta), created_at, updated_at (Unix timestamps from _frm_created_at / _frm_updated_at term meta). Pro-only. Use this BEFORE get-application / apply-form-to-application to pick an application id.
wppilot/formidable-list-entriesList Formidable EntriesLists submissions (wp_frm_items rows) for a Formidable form. Filters: is_draft (omit for both, true = saved drafts only, false = completed entries only); user_id (entries created by that WP user id); search (substring on item_key); created_after / created_before (ISO-8601 dates, inclusive bounds on created_at). Paginated: default per_page=50, max 500. Hard cap on the matching pool is 5000 - pagination.truncated=true when reached. Compact row per entry: id, item_key, form_id, user_id, is_draft, parent_item_id, created_at, updated_at, ip. Use get-entry for the full meta payload.
wppilot/formidable-list-form-actionsList Formidable Form ActionsEnumerates every form action on a Formidable form across ALL types (email, wppost, webhook, mailchimp, activecampaign, stripe, paypal, on_submit, …). Use the type filter to scope to one (e.g. wppost); omit to return everything. Compact per-row payload: id, name, type, enabled, modified_at. This is the generic surface - for email-action CRUD use wppilot-manage-wppilot-notifications.php (list-/get-/create-/edit-/delete-notification); for on-submit configuration use set-on-submit-action. Read/delete only at this surface; create/edit for non-email types go through wppilot/execute-php with the Formidable action subclass dispatcher (see the SKILL.md companion for snippets).
wppilot/formidable-list-formsList Formidable FormsLists Formidable forms with a compact summary per row (id, form_key, name, description, status, parent_form_id, is_template, created_at). Supports filtering by status (published / draft / trash / any - default published), by template flag (is_template), by parent_form_id (for repeater child forms), and by a substring match on the form name (search). Paginated: default per_page=50, max 500. Use this BEFORE get-form to pick a form id; the settings blob (options) and fields[] come from get-form and the form actions from list-form-actions, never from this surface.
wppilot/formidable-list-notificationsList Formidable NotificationsLists email notifications attached to a Formidable form (every form action whose type slug is email). Compact per-row payload: id, name, enabled (true when post_status='publish'), email_to (recipient string), email_subject, modified_at. Use this BEFORE get-notification to pick an action id. Non-email actions (wppost, webhook, mailchimp, …) are listed by list-form-actions; this surface intentionally narrows to the email type so the agent never gets a mixed list with type-specific schemas it can't introspect.
wppilot/formidable-list-stylesList Formidable StylesLists every Formidable form style (CPT frm_styles). Compact per-row payload: id, name, slug (post_name), is_default (post_status='publish' AND has the default-style menu_order). Use this BEFORE apply-style to pick a style_id for a form. Style CRUD itself (creating / editing the 250+ CSS variable set) is out of scope for this surface — use wppilot/execute-php with FrmStyle::save_settings for one-off edits, or the Formidable admin UI for the full experience.
wppilot/formidable-list-subscriptionsList Formidable SubscriptionsLists rows from wp_frm_subscriptions (Stripe Lite + Pro recurring billing ledger). Same gating as transactions — available whenever payments_supported=true.
wppilot/formidable-list-transactionsList Formidable TransactionsLists rows from wp_frm_payments (the Stripe Lite + Pro payment ledger). Available on free Formidable installs that have Stripe Lite configured AND on Pro. Filters: form_id (joins via the action's menu_order), status (e.g. complete, failed, pending, cancelled), paysys (e.g. stripe, paypal, manual), entry_id (item_id). Paginated.

Formidable writes

AbilityWhat it does
wppilot/formidable-add-fieldAdd Formidable FieldAdds a field to an existing Formidable form. The type slug MUST come from get-field-types-schema (the catalog filters out Pro-only and add-on-upsell types so this ability never registers a type the install cannot render). Optional name (the field label), description, required, default_value, options (for choice fields like select / radio / checkbox), field_options (per-type config map merged on top of Formidable's defaults), and field_order (omit to append at the end). Heads-up: Formidable accepts dropdown as an alias of select in its INTERNAL update path, but this ability validates against the canonical catalog and requires select. Pass dropdown and you'll get formidable_invalid_input — always use the catalog slugs.
wppilot/formidable-apply-form-to-applicationApply Form to ApplicationBinds a form to a Formidable Pro Application — wraps FrmProApplication::add_form_to_application which adds a _frm_form_id term meta and bumps the cached form_count. Idempotent re-call returns applied=false. Pro-only.
wppilot/formidable-apply-styleApply Formidable StyleBinds a Formidable form to a style (the frm_styles post id whose CSS variable set governs the form's appearance). Writes options.custom_style = <style_id> on the form via FrmForm::update. The style_id MUST resolve to an existing frm_styles post — otherwise rejected with formidable_invalid_input. Idempotent: re-applying the same style returns applied=false (no-op). This is the ONLY supported path for style binding; edit-form-settings explicitly rejects custom_style in its input.
wppilot/formidable-clear-form-from-applicationClear Form From ApplicationUnbinds a form from a Formidable Pro Application — wraps FrmProApplication::remove_form_from_application. Idempotent: re-call when the form isn't bound returns cleared=false. Pro-only.
wppilot/formidable-create-applicationCreate Formidable ApplicationCreates a new Formidable Pro Application (a frm_application taxonomy term). Wraps FrmProApplication::create which calls wp_insert_term + adds _frm_created_at / _frm_updated_at term meta. Pass name (required). Pro-only.
wppilot/formidable-create-formCreate Formidable FormCreates a Formidable form. Accepts both short and WordPress-native keys for the common fields: title ↔ name (255-char limit, CRLF-stripped); slug ↔ form_key (auto-suffixed when it collides with an existing form, so always trust the returned value, never the input). Optional description and status (published | draft). Set is_template=true to register the row as a form-template. Pass source_form_id to DUPLICATE an existing form (including its fields and Repeater child sub-forms) and then apply the caller-supplied name / slug / description / status as overrides - the duplication path uses FrmForm::duplicate, which copies fields verbatim. Returns the compact form row of the newly created (or duplicated) form.
wppilot/formidable-create-notificationCreate Formidable NotificationCreates an email notification (form action of type email) on a Formidable form. name becomes the action's admin label. email_to / cc / bcc / reply_to / from accept Formidable shortcodes (e.g. [admin_email], [1234] for a field value). Every header-bound value (subject + addresses) is RFC 5322 validated — CR / LF / NULL are rejected with formidable_invalid_email_header. enabled defaults to true (post_status='publish'). Pass event=['create'] (default) for new entries, ['update'] for entry updates, or both. plain_text=true sends as text/plain instead of HTML.

Destructive Formidable calls

AbilityWhat it does
wppilot/formidable-cancel-subscriptionCancel Formidable SubscriptionCancels a recurring billing subscription (wp_frm_subscriptions row) by setting its status column to cancelled. NOTE: this changes the local ledger only — the upstream gateway (Stripe / PayPal / Square) is NOT contacted; that lifecycle is owned by the Pro gateway controllers. Use this when the upstream cancel has already happened externally and the ledger needs to catch up. Pro-only.
wppilot/formidable-delete-applicationDelete Formidable ApplicationDeletes a Formidable Pro Application term. Underlying member forms are NOT cascaded — they're unbound but remain in the database. Pro-only. Idempotent: deleting a missing application returns deleted=false.
wppilot/formidable-delete-entryDelete Formidable EntryHard-deletes one entry + its wp_frm_item_metas rows. No soft-delete (there is no trash state for entries - only the is_draft flag which means something different). Idempotent: deleting an already-missing entry returns deleted=false.
wppilot/formidable-delete-fieldDelete Formidable FieldHard-deletes a single field from a form. Identify the field by field_id (numeric) OR field_key (slug from get-form); the field MUST belong to form_id — cross-form refs are rejected with formidable_field_form_mismatch (400). Idempotent: deleting an already-missing field is a no-op that returns deleted=false — re-running the same call is safe. There is no soft-delete for fields; the field row + its wp_frm_item_metas rows are removed atomically by FrmField::destroy. Heads-up for Repeater (Pro) fields: FrmField::destroy does NOT cascade to the auto-generated child sub-form (a wp_frm_forms row with parent_form_id pointing at the parent). Delete that child form separately via delete-form on its id, OR delete the parent form (which DOES cascade child sub-forms).
wppilot/formidable-delete-formDelete Formidable FormDeletes a Formidable form. Default force=false runs a SOFT delete via FrmForm::trash (the row stays in wp_frm_forms with status='trash' and a trash_time timestamp written into its options blob — restoring is just edit-form{status: 'published'}). Pass force=true to HARD delete via FrmForm::destroy — this also cascades on parent_form_id so any Repeater child sub-forms are removed, and entries + form_actions tied to the form are removed too. Calling soft-delete twice on the same form is a no-op (deleted=false in the response). Calling force-delete on an already-hard-deleted id returns formidable_form_not_found (404). Use force=true ONLY when you are sure the form's entries are no longer needed — there is no undo.
wppilot/formidable-delete-form-actionDelete Formidable Form ActionHard-deletes one form action by action_id. Works for any type EXCEPT on_submit (route those through set-on-submit-action which manages the singleton lifecycle properly). For email actions specifically, delete-notification has the same effect with the same idempotency contract. Idempotent: deleting an already-missing action returns deleted=false.
wppilot/formidable-delete-notificationDelete Formidable NotificationHard-deletes one email notification by form_id + action_id. No soft-delete — the row is removed from wp_posts via wp_delete_post(force=true). Idempotent: deleting an already-missing action returns deleted=false (no-op) rather than 404.
wppilot/formidable-edit-entryEdit Formidable EntryModifies field values on an existing entry. Pass item_meta keyed by field_id (int) OR field_key (string) - both are accepted and normalised internally. Unknown field refs are rejected with formidable_invalid_input (arbitrary-key-injection guard). Reads the current answers, merges the requested values and passes the complete map to FrmEntryMeta::update_entry_metas. It updates the frm_items entry timestamp and editor directly, then explicitly fires frm_after_update_entry and clears the entry cache. The hook notifies listeners; it does not prove that their downstream work completed.
wppilot/formidable-edit-fieldEdit Formidable FieldPartial-merge edit of one field on a form. Identify the field by field_id (numeric) OR field_key (slug from get-form). The field MUST already belong to form_id — cross-form keys are rejected with formidable_field_form_mismatch. Mutable keys: name (label, CRLF-stripped), description, required, default_value, field_order (use this to reorder a single field), options (replaces the whole choice list), field_options (REPLACES the whole per-type config map — Formidable's model layer does not partial-merge it, so pass the full intended map). The type is intentionally NOT mutable — Formidable's FrmField::update accepts a type change but the resulting state on a non-empty form is brittle; recreate the field via delete-field + add-field instead.
wppilot/formidable-edit-formEdit Formidable FormEdits a Formidable form's metadata in place. Accepts BOTH short and WordPress-native aliases for the same field: title ↔ name, slug ↔ form_key; the canonical short form wins when both are supplied. Only the keys you pass are touched (partial merge): omit a key to leave it unchanged. Setting status to trash routes through FrmForm::trash so the soft-delete trash_time is stamped correctly; pass status='published' or 'draft' to restore. This ability INTENTIONALLY does not accept a fields input — field-level edits (add/edit/delete/reorder) use the dedicated add-field / edit-field / delete-field abilities. Returns the compact form row after the write.
wppilot/formidable-edit-form-settingsEdit Formidable Form SettingsPartial-merge edit of the wp_frm_forms.options blob (the Settings → General tab in the Formidable admin UI). Whitelisted keys: submit_value, submit_html, before_html, after_html, show_title, show_description, ajax_submit, antispam, js_validate, save_draft, editable, logged_in, no_save, open_status, open_date, open_msg, closed_msg, open_form_msg. The success_msg / success_action / success_url / success_page_id family has been migrated to the on-submit action in Formidable 6.0+ - write those via set-on-submit-action, not here. custom_style is REJECTED - use apply-style for style binding. Unknown keys are silently dropped.
wppilot/formidable-edit-notificationEdit Formidable NotificationPartial-merge edit of one email notification. Identify by form_id + action_id. Only the keys you pass are written; email_to / cc / bcc / reply_to / from / email_subject are CRLF-validated on every write. enabled=false flips the underlying post to draft (Formidable skips draft actions on entry events); enabled=true restores publish. The settings blob is partial-merged on the whitelisted keys ONLY — unknown keys are silently dropped so arbitrary keys cannot be injected.
wppilot/formidable-set-entry-statusSet Formidable Entry StatusToggles the is_draft flag on an entry. Draft entries (is_draft=1) are typically saved-for-later submissions; completed entries (is_draft=0) are final. Writes is_draft and updated_at directly in frm_items, then explicitly fires frm_after_update_entry and clears the entry cache. Idempotent: setting is_draft to its current value returns changed=false.
wppilot/formidable-set-on-submit-actionSet Formidable On-Submit ActionPUT semantics for the ONE on-submit action a Formidable form may have per event (create or update). Three types — message (show a success message inline), redirect (send the browser to a URL), page (render a WordPress page id). Existing on-submit actions for the same event are updated in place; missing ones are created. The other keys are type-aware: message reads message + show_form_after_message; redirect reads redirect_url (CRLF + scheme-whitelist validated via frm_validate_url_safe — javascript: / data: / vbscript: rejected) + redirect_open_in_new_tab + redirect_delay_seconds + redirect_delay_message; page reads page_id (must exist as a published page). The event input defaults to ['create']; pass ['create','update'] to bind the same configuration to both submission events (front-end edits require Pro).

For the task-level view of Formidable, with worked requests and what to check afterwards, see Formidable Forms integration page.