Skip to main content

Admin & Workflows​

In Pro mode, Flow includes an admin application embedded into WordPress admin. It covers areas such as:

  • General settings
  • API settings
  • Submissions
  • Templates
  • Workflows

This is the operational layer for Flow-backed forms. The frontend block editor defines the form experience, while the admin application governs storage, templates, workflow execution and backend integration.

API settings​

The API settings screen controls how Flow talks to the backend. Important concepts include:

  • backend transport (gatey or fetch)
  • backend API name
  • backend base URL
  • AWS auth mode (COGNITO, IAM, NONE)

In the recommended Pro setup, you register the Flow backend API in Gatey first, then select that API from Flow’s API settings.

Submissions​

With the Pro backend connected, Flow can provide submission operations such as:

  • listing submissions,
  • filtering and sorting,
  • viewing details,
  • editing notes and tags,
  • changing status,
  • viewing event history,
  • invoking manual actions.

Manual actions are useful when an operator wants to push a submission back into an automation flow without editing the form itself. They can be scoped per form and are emitted as workflow-relevant events.

Templates​

Flow Pro includes email templates with HTML/text bodies, preview support and multiple rendering engines. Templates are typically used by workflow email steps, but the same variable model is also important when Flow consumes normalized events from AI Kit Backend email-intake pipelines.

Workflows​

Flow Pro workflows are event-driven. They react to named events and then execute one or more action steps.

Current trigger surfaces include:

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

Current step types include:

  • email.send
  • webhook.call
  • eventbridge.event
  • ai.agent
  • status.update
  • delay

AI agent workflow steps​

The ai.agent step is different from the frontend AI Suggestions block. It emits an ai.agent.requested event toward the AI backend, then downstream workflows continue from ai.agent.completed or ai.agent.failed.

Operational prerequisite:

  • the Flow backend is responsible for storing and dispatching the workflow event
  • the AI Kit backend is the component that actually processes ai.agent.requested

In other words, enabling AI workflow steps is not only a Flow-backend concern. A real deployment also needs the AI Kit backend dispatcher and its model configuration. If you want grounded AI behavior, it also needs a configured Knowledge Base.

That split gives you a clean separation between:

  • frontend assistance before a user submits,
  • backend classification or routing after the platform accepted a submission.

Status-update steps can also produce downstream submission.updated triggers, which lets you model state transitions as part of a larger process map.

The AI step UI exposes configuration for:

  • Mode
  • Internal routing
  • Route Keys, Outcome Types, and Signal Keys
  • Prompt Text
  • Platform System Block
  • Additional System Guidance
  • Response Constraint
  • Update Status on Dispatch

Recommended interpretation:

  • use Mode for task intent,
  • use Internal routing only when you want Flow-owned downstream branching,
  • use route and outcome keys as stable canonical identifiers,
  • use the response schema as a real runtime contract, not only as documentation.

Important caveat:

  • No internal routing removes Flow's routing guardrail block, but it does not automatically clear any older custom response schema already left in the editor.

For the full field-by-field explanation, see AI Agent Workflow Step.

EventBridge and external systems​

eventbridge.event and webhook.call let Flow participate in larger automation topologies. This is useful when Flow is one input source among many, or when you want to fan out a submission into AWS-native or third-party processing pipelines.

AI Kit Backend email intake relationship​

Flow workflows are not limited to browser form submissions. In current deployments they can also sit behind AI Kit Backend email-intake pipelines such as:

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

In those setups, Flow templates and workflow steps consume a normalized event contract instead of only raw form fields. That is what allows a single workflow layer to handle both browser-originated submissions and inbound email inquiries.

Manual actions can also re-trigger workflow-like behaviour without necessarily changing status.