Integrations

Start with shipped follow-up.
Plan broader handoff honestly.

WandForm keeps the form, published version, submission review, owner follow-up, and guarded webhook delivery visible before a workflow depends on broader connector paths.

Current and planned handoff

Use the shipped path first, then document what the next destination needs.

These integration pages separate current email follow-up, guarded webhook automations, and configured-runtime Slack where supported from native Slack, public API, and connector breadth that still need product proof.

Email notifications

Core follow-up path

Email notifications keep human reviewers informed while WandForm remains the shared place to build, publish, and review form submissions.

Notify team inboxes about WandForm submissions while keeping the form workflow, published version, and submission review surface visible.

Good fit

  • Notify account owners when client intake arrives.
  • Send onboarding requests to customer success.
  • Alert operations teams when internal requests are submitted.

Guardrails

  • Avoid sending every workflow to one overloaded personal inbox.
  • Do not treat email as a replacement for submission review when a team needs shared context.
  • Keep native Slack connector, native connector, and broad public API breadth as roadmap handoff paths unless current product proof supports them; use webhook and configured-runtime Slack wording only for implemented supported paths.
View integration plan

Webhook automations

Paid-plan automation path

WandForm keeps form authoring and submission review in the product while paid-plan webhook automations add endpoint delivery, delivery state, and recovery evidence for configured workflows.

Use guarded webhook automations for structured form submissions while keeping shipped forms, versions, delivery health, and submission review in one workflow.

Good fit

  • Send client-intake handoff to a CRM or project intake endpoint your team controls.
  • Trigger support-ticket handoff from structured triage submissions when the endpoint path is configured.
  • Capture onboarding queue requirements before expanding into broader native connector work.

Guardrails

  • Do not imply a broad connector marketplace from the implemented webhook automation path.
  • Avoid changing field meaning without reviewing downstream mapping impact.
  • Native destination connectors, native Slack connector coverage, and broad public API breadth remain roadmap beyond the current email, configured Slack runtime, and guarded webhook proof.
View integration plan

Slack roadmap

Roadmap

WandForm keeps the published form workflow and submission context visible while native Slack notification breadth remains roadmap beyond configured runtime paths where supported.

Plan native Slack visibility for WandForm submission activity while keeping shipped forms and submissions managed in WandForm.

Good fit

  • Plan support-channel visibility for urgent triage requests.
  • Document product-channel visibility for qualified beta applications.
  • Capture operations visibility requirements for internal request queues.

Guardrails

  • Avoid posting sensitive or noisy submissions to broad channels.
  • Do not use Slack as the durable response database.
  • Use channel-specific roadmap planning only where the team has a clear owner.
View integration plan

Public API roadmap

Roadmap

WandForm keeps forms publishable and reviewable for the team while public API breadth stays roadmap until implementation and docs support it.

Plan future public API access for form workflows and submissions while keeping current operations visible in WandForm.

Good fit

  • Build internal dashboards around public intake workflows.
  • Connect onboarding submissions to implementation systems.
  • Use published form context in custom operational tools.

Guardrails

  • Do not bypass team authorization for tenant-authenticated workflows.
  • Avoid building one-off form apps when WandForm can remain the form workflow owner.
  • Treat advanced custom workflow code as a future expansion path, not a generic free-form promise.
View integration plan
Roadmap input

Requested native connectors

Native destinations are active roadmap inputs, not shipped connector claims. Requests help decide which destination deserves implementation and documentation next while webhook automations stay limited to the implemented endpoint path.

Google SheetsZapierNotionStripeDodo PaymentsHubSpotSalesforceAirtableMonday.comAsana
Request an integration
Operating sequence

Keep submissions visible before
adding more destinations.

The reliable path is to publish the workflow, route follow-up through shipped email or guarded webhook paths, and use roadmap pages to document what future handoff must preserve.

01
Step 01

Choose shipped follow-up first

Start with dashboard review, email follow-up visibility, and guarded webhook automation where the plan and endpoint support it.

02
Step 02

Capture destination needs

Document the downstream systems your workflow needs, then keep the dashboard as the review surface for submissions and delivery recovery.

03
Step 03

Publish and monitor

Publish the form and monitor delivery health alongside the submissions dashboard.

Start operating your forms today

Use dashboard review, email follow-up visibility, and documented roadmap planning for production submission workflows.