Form submissions on your site — what visitors experience

How to form submissions on your site — what visitors experience

When a visitor fills out a form on your live site — your contact form, your newsletter signup, your wholesale inquiry form, your event registration — SGEN handles the whole journey: it confirms the submission is real (not a bot), saves the entry into your admin, sends you an email notification, and pushes the data into any tools you have connected (Slack, Zapier, Mailchimp, your CRM). This page explains what visitors experience when they submit, where their submissions land in your admin, and how to verify the whole flow is working before launch and after.

This page is the single reference for everything that happens after a visitor clicks Submit. It does not cover how to build the form (that's the Form Builder docs) or how to wire integrations (that's the Integrations docs). It covers the moment of submission, where the data goes, and how to confirm everything arrived.

What is this for?

Picture this. You run Your Store, a 22-person online shop. Your website has a Contact Us form, a Wholesale Inquiry form, and a "Join our newsletter" footer signup. Every week you should be getting roughly twenty form submissions across all three. Some are wholesale leads worth thousands in monthly revenue. Some are press requests from industry publications. Some are people asking about your upcoming events. Some are job applications. Every single one of those submissions is a person reaching out to your business — and you do not want to miss any of them.

This page is about making sure that pipe stays clear. It walks through what happens when someone clicks Submit on one of your forms, where the submission goes, what notifications you can expect, and what to do if something feels off. It also walks through the most common reasons a form submission can quietly disappear without you noticing — because the worst failure mode is one where everything looks fine in the admin but a key notification (the email to your team, the Slack ping, the CRM sync) silently never arrived.

The pipeline has five steps when everything works:

1. The visitor types in the form on your live site and clicks Submit.
2. SGEN confirms the form exists, the submission is not a bot, and any required Captcha has been passed.
3. SGEN saves the submission into your admin's Submissions list for that form.
4. SGEN sends you (or whoever you configured) a notification email.
5. SGEN pushes the submission to every connected integration — Slack, Zapier, Mailchimp, HubSpot, custom webhooks — in parallel.

If steps 1-3 succeed but step 4 or 5 fails, the visitor still sees a success message and their submission is still safely in your admin. You may not realize anything is wrong because no error surfaces to you immediately. This is why end-to-end verification matters every time you change something — the form, the recipient, an integration.

Good use cases

• Receiving contact form messages from prospective customers and partners — the bread-and-butter case for most sites.
• Capturing wholesale inquiries with attached files (a retailer's PDF catalog, a store's logo for branded packaging, a brand brief for a design firm).
• Newsletter signups that automatically push the new subscriber into your Mailchimp list, no manual export required.
• Quote-request forms that send a Slack ping to your sales channel the moment a lead comes in, so the first responder can claim it.
• Event registrations that record who's coming, capture dietary needs and accessibility notes, and email each registrant a calendar invite.
• Job applications with resume uploads that go straight to a hiring inbox plus your applicant tracking system.
• Customer feedback surveys that run on a per-product page and write structured responses you can later export as a CSV for analysis.
• Partnership and press inquiries that route to a different mailbox than your general contact form, so the right team sees them first.
• Refund or support requests that create a record in your admin (so support can see history) and a Zapier-driven ticket in your help desk.

What NOT to use this for

• Order placement on a store. SGEN's storefront has its own checkout flow. Do not use a contact form to take credit card details — there is no payment processing on this path. Anything that needs to charge a card belongs in the storefront checkout.
• Sensitive identity verification. Forms here are for everyday business intake. They are not designed for verified identity, government ID upload, or health information that requires special compliance handling. If you need to collect Protected Health Information or run government-grade ID checks, those workflows belong in a tool built for that purpose.
• Real-time chat. A form is one message in, one response back later. If your visitors expect instant replies, use a live-chat widget in your site footer instead. The form-submit pipeline is asynchronous by design — visitors hit Submit and then close the tab.
• Anonymous abuse reporting where attribution must be cryptographically guaranteed. Forms collect what visitors voluntarily submit. They are not designed for forensic-grade accountability. If you need a whistleblower or abuse reporting tool, use one built for that purpose.
• Replacing your CRM. The Submissions list is a system of record for what was received. It is not a CRM. Use Submissions to confirm what came in, then push the data into your real CRM via integration for ongoing relationship management.

Scope

Form submission handling applies to every published form on your live site. Each form has its own submissions list, its own email notification settings, and its own integrations.

• Covers: all form types — contact forms, newsletter signups, wholesale inquiry forms, event registrations, file-upload forms, and custom multi-field forms.
• Does not cover: storefront checkout. Checkout has its own order-processing pipeline. A contact form is not a payment form.
• Spam protection: every form ships with a honeypot field and a 2-second timing gate automatically. reCAPTCHA is optional per form and requires site-level reCAPTCHA keys in Settings.
• Admin access: any admin user with Forms access can view, export, and delete submissions for any form.
• Integrations per form: Slack, Zapier, Mailchimp, HubSpot, and custom webhooks can each be connected per form. One form can drive multiple integrations simultaneously.

Fields

Each submission row in your admin shows:

Clicking a row opens the full submission detail: every field the visitor filled, plus a sidebar showing per-integration delivery state and the page the visitor submitted from.

How this connects to other features

• Form Builder — every form you can submit on your live site was created and configured in your admin's Form Builder. Field labels, required fields, success messages, and where the email goes are all set there. If you want to change anything visitors see or where notifications go, edit the form, not this page.
• Email Notifications — the email that lands in your inbox when a visitor submits comes from your email settings on each form. From-address, recipient, subject line, and message template are all configured per form. Each form can have its own template.
• Integrations (Slack, Zapier, Mailchimp, HubSpot, custom webhooks) — connections from a form to other tools live on the form's Integrations tab. Each form can have its own set of connections, so you can route different forms to different channels and tools.
• Pages (Custom CSS) — if you want to change how the form looks (button color, error message style, spacing), the styling lives in your site's theme, not on the form itself. Custom CSS in your design system can target form elements.
• reCAPTCHA settings — when bot signups become a problem, you can enable reCAPTCHA on individual forms in their settings. The site-wide Google reCAPTCHA keys live in your general site settings.
• Form Submissions list — every successful submission lands in the Submissions tab of the form in your admin. That is the source of truth for what your site received.
• Storefront orders — if a form leads to a sale (a custom-quote workflow that turns into an order), you may want to cross-reference submissions against orders. Both records live in admin and can be exported for analysis.
• Site search and analytics — submission volume per form is a useful signal for understanding which content drives leads. Most teams cross-reference this with their analytics platform.

Before you start

A few things that matter for a form to submit reliably.

• The form must be published. Forms with status Draft will not accept submissions from the public site. Visitors get an "Form does not exist" error. Always confirm the form is in Published state before you announce anything driven by it.
• The page that hosts the form must be published. A form embedded on a draft page is not visible. The whole pipe is gated by page visibility.
• Your email From-address should be on a domain you control. Mail providers (Gmail, Outlook, etc.) reject mail from non-resolving from-addresses. If your form sends from noreply@your-temp-domain.com and that domain has no mail records, your notifications will silently bounce. Always check that the From-address is on a real, configured domain �� and that the domain has the right DNS records for sending mail.
• If you have aggressive page caching turned on at the CDN level (Cloudflare full-page cache, etc.), the security tokens on your form can go stale and visitors will see "Invalid nonce, please refresh your screen and try again." Either disable full-page caching on pages that contain forms, or shorten the cache lifetime to under a minute. This is one of the most common silent breakage sources after a CDN migration.
• Spam protection has limits. SGEN ships with two layers of bot protection (a hidden honeypot field and a 2-second timing gate) on every form by default. Sophisticated bots can bypass both. For high-spam forms, also enable reCAPTCHA.
• Decide whether you want a redirect or an inline message. When a visitor submits, you can either show them a green success alert in place of the form (no page change) or redirect them to a thank-you page you've designed. The redirect option is better for conversion tracking; the inline option is better when the form is on a page where you want them to keep browsing.
• Confirm where uploaded files end up. If your form has a file-upload field, those files are stored in your media library. They're not deleted automatically when a submission is deleted — clean up storage periodically if file-upload volume is high.

Where to go

To work with form submissions:

• See submissions: Dashboard -> Forms -> [your form] -> Submissions tab.
• Edit the form (fields, email, redirect): Dashboard -> Forms -> [your form] -> Edit.
• Check spam protection: Dashboard -> Forms -> [your form] -> General -> Enable reCAPTCHA.
• See connected integrations: Dashboard -> Forms -> [your form] -> Integrations tab.
• View site-wide reCAPTCHA keys: Dashboard -> Settings -> Security -> reCAPTCHA.
• Export submissions to CSV: Dashboard -> Forms -> [your form] -> Submissions tab -> Export action.
• Check delivery status of a single submission: click the submission row to open detail; right sidebar shows email + integration delivery state.

Steps — verify your form works before launch

Before launch (or after any change to a form, an email setting, or an integration), run through this end-to-end. The verification takes about ten minutes per form. Do not skip it — the most common failure mode for a form is one where the customer thinks it works but a downstream notification is silently broken.

1. Submit a real test from the public site as if you were a visitor

Open an incognito or private browsing window. Go to the page on your site that has the form. Fill it out the way a real visitor would — full name, real email (your personal one is fine), a real-looking message. Wait at least a few seconds before clicking Submit (this is on purpose — submitting too fast trips the bot guard).

Click Submit.

You should see either a green success alert appear inline ("Thanks! We received your message.") or a redirect to whatever thank-you page you configured. If you see a red error alert, note exactly what it says — that's diagnostic information you'll need next.

The reason for the incognito window is that you want to test as a real visitor would, without your admin login affecting anything. Some error messages only appear to logged-in admins as a debugging aid; visitors see the success message anyway. Testing in incognito gives you the visitor's-eye view.

2. Confirm the submission landed in your admin

Open the admin in another tab. Navigate to Forms -> [your form] -> Submissions tab. Your test submission should be at the top of the list, with the timestamp matching when you clicked Submit.

Click into the submission to confirm all the fields you filled in are recorded correctly. If a field is missing or wrong, that's a form-builder issue (a misconfigured field name) — go back to the form's Edit tab and fix it.

Pay extra attention to fields that should have specific formats. Email addresses should appear as full email addresses. Phone numbers should appear formatted the way the visitor entered them. Dropdowns should show the chosen value, not the dropdown's internal key. If anything looks like an internal label or a key instead of a human-readable value, the form's field configuration needs attention.

3. Confirm you received the notification email

Switch to your email inbox. The notification should be there within thirty seconds. Check your spam folder if it isn't in your inbox after a minute.

If the email never arrives:

• Confirm the form's email recipient is correct (Edit form -> Email Notifications -> To field).
• Confirm the form's email is enabled (some forms are set up to save submissions silently without sending email — check the Email Notifications tab is on).
• Check whether your domain's email provider is rejecting mail from your configured from-address. Ask your email administrator to whitelist the sending domain.
• For test purposes, change the recipient temporarily to a personal Gmail address — Gmail is forgiving and will deliver almost anything to your spam folder. If Gmail receives it but your business mailbox doesn't, the issue is on your business mailbox side.

The notification email contains the full submission contents in the body, plus any uploaded files as attachments. Read through the body once to confirm it formats well — long messages should be readable, line breaks should be preserved, special characters (apostrophes, accented letters) should not look mangled.

4. Confirm any connected integrations fired

If you have Slack, Zapier, Mailchimp, HubSpot, or custom webhook integrations connected to the form, check each of them.

• Slack: open the channel you wired the integration to. There should be a new post with the submission details.
• Zapier / Make: open your dashboard there. The "Task History" or "Run History" should show a successful run timestamped within seconds of your submission.
• Mailchimp: if you wired the form to add subscribers to a list, open the list and search for the email you used. The new subscriber should be there.
• HubSpot: check the contact in your CRM. The contact should be created (or updated, if it already existed) with the form fields mapped to contact properties.

If any integration didn't fire, open the submission detail in the admin. There's usually a sidebar showing per-integration delivery status. A failed delivery there points you at exactly which connection broke. The most common breakage causes are revoked OAuth permissions (someone disconnected the app on the integration side) and rotated webhook URLs (the URL you configured no longer exists at the destination).

5. Try the redirect (if you have one configured)

If your form is set to redirect visitors to a custom thank-you page after submit, walk through that path too. Submit again. Confirm the visitor lands on the right thank-you page. Confirm the URL has ?success=1 appended — many customers use this query parameter to fire conversion-tracking pixels (Google Ads, Facebook Pixel, etc.) on the thank-you page.

If you don't already have conversion tracking on the thank-you page, this is a good time to add it. The thank-you page is the highest-signal moment to attribute a conversion — visitors who reach it have completed a desired action.

6. Try a deliberate failure path

This is optional but worth doing once. Submit the form without filling in a required field — the form should reject it client-side and show a validation message. Submit it filling in only spaces — the form should reject it as empty. If reCAPTCHA is enabled, try without solving it — the form should reject it with a Captcha error.

These deliberate failures confirm your spam guards work. If a deliberate failure path silently succeeds (a submission saves anyway despite required fields being empty), that's a form-builder configuration issue and worth fixing before launch.

7. Submit from a different network or device

One last check, useful for catching geography-specific or network-specific issues. If you've only tested from your office Wi-Fi, also test once from your phone on cellular data. Some bot-detection systems flag certain IP ranges (corporate VPNs, hosting provider IPs) as suspicious — you want to confirm a normal residential visitor from outside your office can submit cleanly.

What success looks like

After a clean submit, three things happen within about thirty seconds:

1. The visitor sees a success message (green alert) or a redirect to your thank-you page.
2. A new row appears in your Submissions list in admin.
3. A notification email arrives in the configured inbox.

Plus, every connected integration receives the submission and shows a successful delivery in its own dashboard.

If all three of those line up — submission saved, email delivered, integrations green — your form is healthy.

A useful metric to watch over time: ratio of submissions to email-delivered. If that ratio drifts below 100% (some submissions show up in admin but never trigger an email notification), you have a slow leak — usually email infrastructure that's intermittently bouncing your notifications.

What to do if it does not work

A few common scenarios and what to check for each.

Visitor sees a red error: "Invalid nonce, please refresh your screen and try again."

This almost always means the page that hosts the form was served from a stale cache. Each form gets a one-time security token when the page renders, and that token expires. If your CDN or page cache is serving the same page for hours, the token is dead by the time someone tries to submit.

Fix: lower the cache lifetime on form-hosting pages, or set those pages to bypass the full-page cache. Your hosting/CDN provider's docs cover the settings. Cloudflare users can use a cache-rule that excludes pages with form embeds. If you're not sure how aggressive your caching is, try clearing it once and submitting again — if that fixes the immediate issue, your cache lifetime is too long.

Visitor sees a red error: "Invalid submission."

This is the bot guard tripping. Either the visitor filled in a hidden honeypot field (very unusual — almost always a bot, occasionally a screen reader user), or they clicked Submit faster than two seconds after the page loaded. The two-second gate is intentional; bots fill forms in milliseconds.

Fix: in the rare case a real visitor reports this, ask them what browser and assistive tools they're using. If a screen reader is filling the honeypot, that's a bug to report. Otherwise, no action — the guard is working as designed. If the issue is widespread (many real visitors reporting it), that's worth escalating to support — there may be a regression in the page rendering that's causing the timing field to be set wrong.

Visitor sees a red error: "Captcha is required.."

Means reCAPTCHA is enabled on the form but the visitor did not complete the challenge. They need to click the Captcha checkbox before clicking Submit. If they did and still got the error, they may have failed Google's behavioral check (bots, VPN users, and some accessibility tools sometimes get flagged). They can retry, often it works on the second attempt.

If a meaningful share of legitimate visitors are failing Captcha, consider tuning the Captcha sensitivity or switching to invisible reCAPTCHA which is less intrusive.

Submissions are landing in admin but you are not getting the email.

Most common cause: the From-address on the form is on a domain that doesn't have proper email DNS records, and the recipient's mail server is silently rejecting it. Less common: the recipient address has a typo or is no longer monitored.

Fix: open the form, check the Email Notifications tab, confirm the From-address is on a domain you control and has proper email-sending DNS configured, and confirm the To-address is current. As a temporary workaround, change the recipient to a personal Gmail address while you sort out your business mail — Gmail will deliver almost anything.

Bot signups are coming through despite the honeypot.

Honeypot + 2-second timing gate stops most bots. Sophisticated form-fillers bypass both. The next defense is reCAPTCHA. If reCAPTCHA isn't enough either (rare), the next step is rate-limiting at your firewall or CDN. Cloudflare's bot-fight mode can shave off most automated traffic.

The thank-you page redirect isn't firing.

Open the form. Go to General settings. Check the Form Redirect field. If empty, no redirect happens — visitors see the inline success message instead. If filled, the redirect should work; common breaking issues are typos in the URL or pointing to a page that has been unpublished.

Visitor uploads a file but it isn't attached to the submission.

Confirm the form has a file-upload field configured (not a regular text field). Confirm the file type is allowed (forms reject some types by default — large videos, executables). Confirm the file is under the size limit (large attachments can hit upload limits at the server level).

A submission appears twice in the admin.

Most often this happens when a visitor clicks Submit multiple times because the page felt slow. Each click is a real submission — there is no automatic deduplication on the server side. If this is a recurring problem, the fix is on the form template: disable the submit button as soon as it's clicked the first time, with a "Submitting.." label until the response returns.

Submissions stop arriving entirely after a recent change.

If everything was working and then stopped working after a change, the change is the cause. Common candidates: the form was switched to draft, the form's email recipient was edited (typo), the form's hosting page was unpublished, the integrations were rewired, the site was migrated to a new CDN with default cache rules, or reCAPTCHA was enabled with the wrong site/secret keys. Walk back the change history and revert one piece at a time.

Example 1: Your Store's contact form launches and they verify the whole pipe

Your Store launched their new site on Monday. You, as the site owner, want to confirm the Contact Us form is fully wired before they push the launch announcement to their email list of 8,000 subscribers.

Open an incognito window, go to /contact, and fill out the form as if you were a real customer:

• Name: Site Owner Test
• Email: owner@yoursite.com (your real address, since you will be receiving the test)
• Subject: Test submission — please ignore
• Message: Just confirming the form works.

Wait five seconds, click Submit. You see the green success alert: "Thanks! We received your message."

Switch to your admin tab. Open Forms -> Contact Us -> Submissions. The test submission is at the top of the list, timestamped 14:22:08, all four fields populated correctly.

Switch to your email. Within twenty seconds, the notification arrives. Subject line says "[Your Store Contact] Test submission — please ignore," body has the test name, email, and message.

Switch to Slack. The #leads channel has a new post: "New contact form submission from Site Owner Test." Click into it shows the full message.

Switch to HubSpot. There is a new contact listed, properties populated from the form fields, source attributed to "Your Store Contact Form."

Everything green. Push the launch announcement.

Three days later, repeat the same end-to-end test (now a weekly habit) and you catch a small regression: the Slack ping is missing. Open the form's Integrations tab — the Slack integration shows "Not connected." Your Slack admin had rotated workspace tokens during a security audit and the old webhook was deactivated. Generate a fresh webhook URL, paste it in, save, and confirm the next test submission pings Slack again.

The point of the example: you catch the regression because you run the test routinely. Without that habit, a few weeks of submissions would have come in with no Slack visibility, and the sales team would have wondered why the inbound was so slow.

Example 2: Your Store sees a sudden surge in newsletter signups and recognizes them as bots

Your Store has a footer newsletter signup form. Normal volume is five to fifteen signups a day. On Tuesday morning, you log into admin and see 847 new signups since Monday afternoon.

Open the Submissions list. Most of the new emails look bizarre — long random strings of characters at unusual domains, names that do not read as natural language, signups clustering in 30-second bursts every four hours.

This is a botnet hammering the form. The honeypot and timing gate are not catching this attacker.

Open the form's settings, enable reCAPTCHA (your general settings already have site keys configured, so it is a one-toggle change), and save. Within ten minutes, signup volume drops back to roughly two per hour — the natural rate.

Review the 847 bot signups in admin. Use the bulk-delete action to remove them so they do not pollute the newsletter list. (Many of the bot signups had also synced to Mailchimp before reCAPTCHA went on — pull a Mailchimp report and clean those out too.)

Next step: turn on Cloudflare's bot-fight mode for the site as a whole, so even if a future attacker bypasses reCAPTCHA, the upstream WAF can rate-limit their volume.

Example 3: Your Store has a Wholesale Inquiry form with file uploads to the wholesale team inbox

Your Store's Wholesale Inquiry form is for prospective retail buyers — they want retailers to upload their catalog or a brief before the wholesale team gets on a call. The form has these fields:

• Business name (text)
• Contact email (email)
• Monthly volume needed (dropdown: under 50 units / 50–200 units / over 200 units)
• Current supplier (text)
• Open date or expected first order (date)
• Catalog or brief (file upload, accepts PDF)
• Free-text "tell us more" field

The form sends email notifications to wholesale@yoursite.com, posts to the #retail-leads Slack channel, and creates a deal in HubSpot under "Wholesale pipeline."

A real prospective retailer submits a brief. The flow:

• Visitor uploads a 4.2 MB PDF catalog.
• Submission saves with the file URL stored as part of the entry.
• Notification email lands at wholesale@yoursite.com with the PDF attached and all form fields in the body.
• Slack post in #retail-leads shows: "New wholesale inquiry from a wholesale buyer, 200 units/month, Q3 2026 start, catalog attached."
• HubSpot deal created at the "Inquiry" stage with the file linked.

Example 4: Your Store runs a registration form for an open-house event

Your Store hosts a quarterly open-house event at their main location. They have an Event Registration form on a dedicated event landing page. The form collects name, email, how many guests, and dietary needs. Email notification goes to events@yoursite.com Confirmation email goes back to the visitor.

Two weeks before the event, registrations flow in — about ten per day. Spot-check the Submissions list twice a week to confirm everything is arriving.

The day of the event, pull a CSV export of the Submissions list and use it to print name badges and check in guests.

The dietary-needs field feeds the catering order three days before the event. The spreadsheet shows attendee count per dietary requirement (vegan, gluten-free, etc.) so the caterer can prep correctly.

The point: form submissions work for any structured intake — event registrations, RSVPs, surveys, feedback collections — not just contact forms. The same admin views, notifications, and integrations apply.

Example 5: Your Store notices a quiet failure and learns the value of monitoring delivery state

Three months after launch, you notice that your Slack #leads channel has been quieter than usual — fewer new posts than you would expect given the volume of emails landing in your inbox.

Open admin, navigate to Submissions, and click into the most recent five submissions one at a time. The right sidebar of each shows delivery state per integration. Pattern: every recent submission shows "Slack: failed."

Open the Integrations tab on the form. Slack still shows as configured. Click the test-connection button on the integration. The test fails with an error from Slack: "channel_not_found."

What happened: the marketing manager had renamed the #leads channel to #sales-leads in Slack last week. Slack treats renamed channels as effectively new — the old channel ID stops accepting posts. SGEN didn't realize this had happened because the integration is fire-and-forget.

Update the integration to point at the new channel name, test again, get a green check. Six new submissions land that afternoon — they all post to Slack correctly.

The bigger lesson: the per-submission integration delivery sidebar is the canary. If you suspect any tool has gone quiet, click into a recent submission and look at the sidebar. The state shown there is authoritative.

Example 6: a small site uses the simplest possible setup

Your Store's owner runs a lean two-person operation. The site has exactly one form: a Contact Us form. No Slack, no Zapier, no CRM. The goal is for emails to land in your personal mailbox when someone submits the form.

The setup:

• Form has three fields: name, email, message.
• Email notifications enabled, recipient is owner@yoursite.com (your personal mailbox).
• No reCAPTCHA — submission volume is low and the honeypot+timing protection is plenty.
• No integrations connected.
• No redirect — visitors see the inline green success message and continue browsing.

This works. Two or three contact submissions arrive each week, all real, all in your inbox within thirty seconds of the visitor clicking Submit. You reply from your email. The Submissions list in admin is your backup record in case you ever lose an email thread.

The example is here to illustrate that you do not need every bell and whistle. The simplest possible setup is the form + email recipient. Everything else is an addition that you turn on only when you have a specific need.

Next steps

• Build a form for a specific intake — see Form Builder docs for how to add fields, configure validation, and set up email and integrations.
• Connect Slack, Zapier, Mailchimp, or HubSpot to a form — see Integrations docs for connection setup per tool.
• Style your forms to match your site — the Custom CSS section in your design system can target form elements (button colors, error message style, spacing).
• Reduce spam without losing real visitors — see the reCAPTCHA setup guide and the spam mitigation tips for forms with high-volume traffic.
• Export submission data for marketing or analysis — every Submissions list has an export-to-CSV action.
• Set up conversion tracking on your thank-you page — fire Google Ads, Facebook Pixel, and similar tags when visitors land on the thank-you page after submitting.
• Build a weekly verification habit — the most reliable way to catch quiet integration failures is to submit a real test through every active form once a week and confirm every notification path lands.