Email Delivery
Sending notification and confirmation emails through a third-party transactional email service, separate from Form Builder → Submission Storage, and separate from whatever CRM a submission also gets sent to. This page documents that P1 has no email-sending capability at all, and lays out the plan for adding one.
This is a P1 platform gap, not a Brown-Forman-specific one; every P1 site that collects a form submission needs a way to notify a team about it. Filed here at the top level alongside Form Builder, Localization, and Managing the Header & Footer.
Confirmed: P1 has no email-sending capability
grep -rliE "postmark|sendgrid|nodemailer|smtp|email.?service|sendEmail" across every
installed @pantheon-systems/*/dist package returned zero matches. Checked
separately, and confirmed the same way, from
Form Builder → Submission Storage.
P1 doesn’t help with either half of “what happens after someone submits a form.”
Proposed: @prolific-digital/p1-email-delivery
A new package responsible only for sending notification/confirmation emails,
nothing else, and usable on any P1 site. Deliberately vendor-agnostic behind a small
interface (send(to, template, data)), so the concrete provider (Postmark, SMTP, or
another transactional-email vendor) is a swappable adapter, not baked into
form-handling code. Per the org’s existing conventions, Postmark is the default
choice for transactional email unless a specific brand or engagement has an
existing vendor relationship that overrides it.
This is genuinely new infrastructure. There’s no P1 primitive to build it on top of, so it’s a standalone Node package any P1 site installs and configures with its own API key/SMTP credentials per site.
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.
How it fits with storage and CRM sync
Email delivery is the third and last step in the submission pipeline documented on Form Builder → Submission Storage:
Visitor submits → validate → persist (durable store) → attempt CRM sync
→ attempt notification emailStorage happens first and independently; a failure here should never block or delay
storage, and a storage failure should never be silently swallowed just because the
email step is what a developer happened to be looking at. Track delivery success on
the stored submission record (an emailStatus flag) the same way CRM sync status is
tracked, so “did the notification actually go out” is answerable without digging
through Postmark’s own dashboard.
Open questions for this page now live on Outstanding Questions, tracked centrally across all pages rather than repeated per page.