Event-Driven Forms and Workflow Backend for WordPress on AWS

Why forms become an architecture problem

Simple contact forms can live almost anywhere. The problem starts when forms become business workflows: save-and-resume drafts, file uploads, email templates, webhook delivery, approval steps, CRM handoff, audit trails, protected admin views and retryable downstream actions.

In a traditional WordPress implementation, those responsibilities often accumulate inside plugins, PHP hooks and database tables attached to the public site. That works until traffic, spam, large attachments, external systems or static publishing force the form layer to behave like a real backend.

The Flow backend separates page rendering from form execution. WordPress still owns the form design and editorial placement, but AWS owns the runtime path that accepts submissions, stores state and dispatches work.

System boundary

WordPress source site
Gutenberg forms, workflow intent, email/template configuration
        │
        ▼
Static or dynamic frontend
Flow blocks rendered into public pages
        │
        ├─ submit / save draft / load draft / upload URL
        ▼
API Gateway REST API
/frontend/* routes: public form operations
/admin/* routes: protected management operations
        │
        ▼
Forms API Lambda
validation, persistence, event recording, upload references
        │
        ├─ DynamoDB: forms, submissions, events, templates, workflows, webhooks, process maps
        ├─ S3: payload uploads and email template assets
        ├─ EventBridge: submission and workflow events
        ├─ SES: email actions via email sender Lambda
        └─ Webhook dispatcher Lambda: outbound integrations

The browser does not need WordPress/PHP to handle a submit. The page can be static, the form can still be interactive, and the backend can apply a different security, retention and retry model than the content site.

What the Flow stack creates

Frontend API versus Admin API

The most important design choice is the route split. Visitor actions belong under /frontend/*; management and inspection belong under /admin/*. That keeps the public form surface small and makes privileged operations easier to protect.

Submission lifecycle

Data model: why several tables are useful

A single submissions table is not enough once forms become workflows. Flow separates definitions, records, event history, templates, webhooks and process maps because each has a different lifecycle and access pattern.

Security and abuse controls

The frontend API may intentionally accept anonymous traffic, because many forms are public. That does not mean it should be unprotected. The stack supports optional reCAPTCHA, WAF, IP allow/block lists and separate admin authentication so public reachability does not leak into privileged management operations.

Workflow and integration pattern

submission.created / submission.updated / action-invoked
        │
        ▼
EventBridge rule
        │
        ├─ Workflow Dispatcher Lambda
        │      └─ evaluates workflow definitions and writes events
        │
        ├─ Email Sender Lambda
        │      └─ reads templates and sends via SES
        │
        └─ Webhook Dispatcher Lambda
               └─ signs and delivers payloads to external systems

The key advantage is failure isolation. A visitor submit can complete once the submission is durably accepted. Email or webhook delivery can be retried, logged or inspected without pretending the original HTTP request is still alive.

Deployment parameters that change the architecture

Operational failure modes to document

Implementation path

1. Classify forms by complexity: simple contact, long draftable form, file-upload form, workflow-trigger form or integration-heavy form.
2. Decide the frontend auth mode: anonymous with WAF/reCAPTCHA, IAM, or Cognito-protected page/API flow.
3. Deploy the Flow backend stack with only the protections and storage choices needed for the first production use case.
4. Copy the stack outputs into the Flow plugin/admin configuration and keep the CloudFormation parameters in the site runbook.
5. Define form IDs, template keys, workflow IDs and webhook keys as stable integration contracts.
6. Test draft save/load/finalize separately from final submission, email and webhook dispatch.
7. Add logs, alarms and manual recovery guidance before connecting critical business systems.

Related resources

FAQ