Why submitter emails exist

Submitter emails close the loop with the people sending you proof. Without them, a submitter clicks Submit and never hears back until you (or someone on your team) gets around to manual outreach. That gap erodes trust and is the single most common driver of “where is my reward?” inbound. Submission status emails replace that gap with three automatic, co-branded messages sent at the moments a submitter actually cares about: when their claim lands, when it is approved, and when it is rejected.

These emails are transactional, sent from HighAdvocacy’s internal email system, and require no SMTP setup, no domain verification, and no integration on your side. They are auto-enabled on all existing campaigns and on every new campaign you create.

The three events

Three notification types cover the full submission lifecycle. Each one is independent and can be turned on or off without affecting the other two.

The Received delay is intentional: it lets you batch-handle very-fast rejections (for example, obvious bot submissions) before the submitter gets a confirmation that would later be contradicted. Approved and Rejected emails fire as soon as a reviewer acts in the Submissions dashboard. Each notification can be toggled on or off independently from Settings > Email Notifications.

From-address and branding

Every email is sent from {Your Company} via HighAdvocacy <[email protected]>. For an account belonging to Acme Inc, that renders in the submitter’s inbox as Acme Inc via HighAdvocacy. This format keeps your brand in the sender line so submitters recognize the email, while making it transparent that HighAdvocacy is the delivery system.

The body uses a co-branded template:

• Header: your company logo, pulled from your workspace’s brand identity settings.
• Body: your subject line and email copy, rendered on a clean minimal background.
• Footer: “Powered by HighAdvocacy” with a small HighAdvocacy logo.

You do not control the wrapping shell, only the subject and body. If your logo is missing or low-resolution in the header, update it in your workspace brand settings; the email template re-reads it on every send.

Customizing subject and body per event

Each of the three notifications has its own subject line and body. Click Edit on the row you want to change. The edit modal opens with:

• Subject Line: a single-line text input.
• Email Body: a plain-text area for the body copy.
• Available variables: a list of merge variables you can paste into either field.
• Preview: a live render of the email with sample data, refreshing as you type.
• Reset to Default: restores the shipped template for that notification.

The three default templates ship ready to use. The defaults already pull in the submitter’s name, the platform they submitted for, and (for Approved) the reward they earned. Most accounts only need to edit the subject lines for brand voice (for example, swapping “Decision on your claim” for “Update on your Acme submission”) and leave the body as-is.

When you have edited subject or body for one notification, Save Changes at the bottom of the Email Notifications page persists every change at once. Changes apply to all future submissions immediately; previously sent emails are not re-sent.

Variables available in the template

You can drop these merge variables into the subject line or body of any notification. They are replaced at send time with the values for that specific submission.

The {{rejection_reason_clause}} variable is special. When a reviewer rejects a submission and types a reason, the variable renders as a complete clause, for example, because the submitted link could not be verified. When the reviewer rejects without a reason, the variable renders as an empty string, which lets the same template stay grammatical in both cases. Use it inline in a sentence rather than on its own line.

A variable typed without matching curly braces (for example, user_name without the doubled braces) renders as literal text. The preview panel will show this immediately.

Previewing with sample data

The preview pane on the right of the edit modal renders your subject and body with realistic dummy data: a sample submitter name, a sample platform, a sample reward, and your real company logo and brand color in the wrapper. The preview updates as you type, so you can verify that:

• Variables resolve where you expect.
• Line breaks land naturally and the body does not run together as one wall of text.
• The header logo and the “Powered by HighAdvocacy” footer render with your branding.
• The Rejected template still reads naturally when {{rejection_reason_clause}} is empty (the most common rejection case).

Preview uses dummy data only; it never pulls a real submission. To test against your own data, use the test email flow below.

Sending a test email

To verify the live rendering (including the header logo, footer, and the from-address as it appears in a real inbox), use the Send Test Email button at the bottom of the Email Notifications page.

1. Click Send Test Email.
2. In the dialog, pick which notification to send from the dropdown. Only notifications that are currently enabled appear here.
3. Confirm. The test goes to the email address you signed in with.
4. Check that inbox. The test arrives with the same from-line, branding, and structure as a real submission would, with the merge variables filled in using sample data.

Test sends do not show up in any submission’s history and do not count against your account in any way. Send as many as you need while you are tweaking copy.

Per-campaign enable/disable

Notification toggles in Settings > Email Notifications apply at the account level. Turning a notification off there stops it from being sent for any campaign. Existing campaigns inherit the account-level setting at the moment a submission triggers; there is no separate per-campaign override in this version.

During campaign creation, an inline reminder appears after the install code section: a banner telling you that submitters will receive email updates and pointing you back to Settings to customize. This reminder is informational only; you do not configure email content from inside campaign creation.

If you need a campaign that never emails submitters (for example, an internal test campaign), turn off all three notifications at the account level for the duration of the test, then turn them back on. A more granular per-campaign override is on the roadmap.

What submitters see end to end

A submitter who claims a reward on one of your campaigns sees three possible messages depending on the outcome:

1. Within 5 to 10 minutes of submitting, an email titled around We received your claim for {{platform_name}} arrives in their inbox. The body confirms receipt, sets expectation around a 2–3 business-day review window, and is signed by The {{company_name}} Team.
2. Immediately after a reviewer approves, an email titled around Your claim for {{platform_name}} was approved arrives. The body names the reward earned via {{reward_name}} and notes that fulfillment is being processed.
3. Immediately after a reviewer rejects, an email titled around Decision on your claim for {{platform_name}} arrives. If the reviewer added a reason, it appears inline as part of a full sentence; if not, the message still reads naturally without it.

Each email shows your logo at the top and “Powered by HighAdvocacy” at the bottom. There is no unsubscribe link because these are transactional, not promotional. The submitter receives at most two emails per submission: Received, then either Approved or Rejected. State is final (a submission cannot move back from approved to rejected), so submitters never receive contradicting messages about the same claim.

Related docs

• Notifications & Alerts overview
• Notification integrations: for routing alerts to your team in Slack, Microsoft Teams, Discord, Zapier, or a custom webhook
• Roles and permissions: only Owner and Admin can edit notification settings