Skip to Content
Email Delivery

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 email

Storage 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.

Last updated on