Skip to main content

Backend Sync & Pro Backend​

Flow can work without a dedicated backend, but Pro is designed to work especially well with the separately deployed WP Suite Flow Backend in your own AWS account.

Submission model​

Each form can post directly from the browser to a configured endpoint URL.

That endpoint may be:

  • your own custom endpoint,
  • a WordPress‑side endpoint you implement yourself,
  • the Flow backend submission endpoint.

This means Flow does not inherently store submissions in WordPress.

When a Flow backend is available, the same frontend runtime can switch from "plain browser POST" to a backend-aware submission path. The capability decision is based on the configured transport and the resolved backend target.

Backend sync​

When backend sync is enabled, Flow can synchronise a Gutenberg-defined form into a canonical backend form definition. The sync flow is:

  1. edit a Flow form in WordPress;
  2. save the form;
  3. Flow extracts a canonical structure and computes a sync hash;
  4. the backend definition is created or updated if needed;
  5. WordPress stores backend sync metadata such as backend form ID, sync hash, status, timestamps and last error.

This backend definition is what lets admin tooling, workflows and submission handling operate against a stable schema instead of the raw Gutenberg post content.

Typical Pro setup​

A common production setup is:

  1. deploy the Flow backend to AWS;
  2. register the published API base URL in Gatey as a separate API;
  3. configure the same protection mode in Gatey that you selected when publishing the backend (IAM or COGNITO);
  4. select that API in SmartCloud → Flow Settings → API Settings.

This gives Flow a simple secure way to reach the backend for submissions, templates, workflows and admin operations.

Drafts, files and larger payloads​

When used with the Flow backend, forms can support:

  • save-draft and load-draft flows,
  • draft deletion,
  • backend-issued submission IDs and statuses,
  • presigned upload flows for large payloads or file-heavy submissions.

Workflow event model​

Once a submission is accepted into the backend workflow system, Flow workflows can react to lifecycle and integration events such as:

  • submission.created
  • submission.updated
  • submission.action-invoked
  • integration.webhook.requested
  • ai.agent.completed
  • ai.agent.failed

That means backend sync is not only about schema storage. It is the bridge between a Gutenberg-authored form and a backend event pipeline.

Relationship to AI Kit Backend email intake​

Flow backend workflows can also process normalized events coming from AI Kit Backend email-intake chains. In current deployments that can look like:

  • WorkMail -> ai-email-intake-proxy -> ai-email-intake-dispatcher -> Flow workflow
  • WorkMail -> ai-email-intake-proxy -> ai-email-intake-dispatcher -> Flow workflow -> ai.agent -> downstream Flow workflow

The shared value here is the event contract. Browser submissions and email-intake events can both be normalized into the same workflow model, which allows the same template layer, AI step definitions and routing logic to operate across channels.