Delivery Rules

Delivery rules route accepted submissions using server-managed configuration. They are useful when one public form can route work to different departments or teams.

Security Boundary

The frontend can submit field values only. It must never submit recipients, sender addresses, provider names, provider credentials, templates, or delivery rules.

Public schema responses do not expose delivery rules or recipient addresses.

Example

{
  "email": {
    "to": ["general@example.com"],
    "bcc": ["archive@example.com"],
    "deliveryRules": [
      {
        "id": "route-sales",
        "label": "Sales inquiries",
        "when": {
          "path": "department",
          "operator": "equals",
          "value": "sales"
        },
        "recipients": {
          "replaceTo": ["sales@example.com"],
          "addCc": ["sales-manager@example.com"]
        },
        "templates": {
          "subjectTemplate": "Sales request from {{name}}"
        },
        "stopProcessing": true
      }
    ]
  }
}

Rules are evaluated in order. If multiple rules match and none stop processing, their additions accumulate.

Hardening

• Keep a safe default recipient.
• Use replaceTo when one department should own the submission.
• Use stopProcessing for first-match routing.
• Keep global archive recipients for records that must always receive delivery.
• Use only declared email fields for reply-to routing.
• Keep rule paths and template variables aligned with the field schema.