Submission Storage

Durably storing every form submission on our own infrastructure, separate from Email Delivery, and separate from whatever CRM a submission also gets sent to. This page documents that P1 has no native concept of a form submission as data, and lays out the plan for building durable storage.

This applies to every form on a P1 site, not just the ones built with Form Builder, including the hand-built Contact/Subscribe/Unsubscribe forms on Brown-Forman brand sites. It’s filed here because Form Builder is where a new form most often gets created, but the storage layer itself is shared, general-purpose infrastructure.

Confirmed: P1 has no submission storage

grep -rliE "form.?submission|formSubmit|submission.*store|webform" across every installed @pantheon-systems/*/dist package returned zero matches.

Web Forms & Salesforce covers the Salesforce Web-to-Lead integration Herradura’s live forms post to, but Web-to-Lead is a one-way fire-and-forget POST. If Salesforce (or any CRM) is unreachable, slow, or the request silently fails validation, there is no record anywhere that a visitor ever submitted the form. That’s the gap this page addresses.

Why this needs its own architecture, not just “add error handling”

A visitor’s submission needs to survive two independent failure modes: the CRM being unreachable (the sync fails) and transactional email being unreachable (the internal team never gets notified: see Email Delivery). Today, a CRM POST failure and a notification-email failure are the same kind of event: silent data loss, with no way for a team member to go looking for what was actually submitted. The fix isn’t retry logic bolted onto the existing CRM call: it’s making the submission durable before either downstream system is even attempted, so a failure in either one is recoverable instead of silent.


Visitor submits → validate → persist (durable store) → attempt CRM sync
                                                       → attempt notification email

This is the one piece that must never be skipped or reordered: if storage happens after the CRM attempt, a CRM outage produces exactly the silent-loss scenario this page exists to prevent.

Why not a CCR document

We explicitly rejected using CCR/P1 documents (see Workflows) as the store: CCR documents are built for versioned, editorially-authored content with branches and checkpoints: the wrong shape for high-volume, write-once event data, and every form submission would show up cluttering the Site Structure UI next to actual pages. This needs a real database, separate from P1’s content model entirely.

Open question, not yet confirmed with Pantheon: does the P1 platform provide any database/storage service brand sites can provision (the way Vercel offers Postgres, KV, etc.), or does this need to be stood up entirely outside P1’s infrastructure? This determines whether the storage layer is “a P1-adjacent service” or “infrastructure we own and operate ourselves.” Don’t assume either answer; confirm before committing to an implementation.

Proposed: `@prolific-digital/p1-form-storage`

Usable on any P1 site, not tied to one brand: one submissions table/collection, minimal shape: form type (contact/subscribe/unsubscribe/custom), site ID, raw field payload (JSON), submitted-at timestamp, and downstream-delivery status flags (crmStatus, emailStatus) so a team can query “show me everything that failed to reach the CRM this week” directly, without needing the CRM’s own UI to be working.

Scoped to @prolific-digital rather than @brown-forman deliberately: this isn’t a Brown-Forman-specific concern, it’s general P1 tooling any site we build can use.

CRM sync stays unchanged, now decoupled

For Brown-Forman brand sites specifically, this is the Salesforce Integration already documented (@brown-forman/p1-salesforce-forms), but the pattern generalizes to any CRM. No behavior change to that integration itself; the only difference is it now runs after storage has already succeeded, so a CRM-side failure updates a status flag on an already-durable record instead of losing the submission outright.

Open questions for this page now live on Outstanding Questions, tracked centrally across all pages rather than repeated per page.