What team alerts are vs submitter emails

There are two distinct notification systems in HighAdvocacy and it is worth pinning down which one this doc covers.

Submitter status emails are the three co-branded emails sent automatically to the person who made a submission: Submission Received, Submission Approved, Submission Rejected. They live under Settings > Email Notifications and are documented in Submission status emails. Submitters never see what is configured on this page.

Notification integrations are the alerts sent to your team when something happens that may need attention: a new submission landed, a reviewer approved or rejected one, or a reward fired or failed. These are routed to channels and tools your team already uses: Slack channels, Microsoft Teams channels, Discord channels, Zapier/Make workflows, custom webhook endpoints, and direct team email inboxes. They live under Settings > Notifications, which is split into two tabs: Integrations and Team Emails.

The two systems do not overlap. Turning off Submission Received under Email Notifications does not stop your Slack channel from getting the submission.received alert.

Supported destinations

Integrations and Team Emails together cover five destination types.

Slack, Microsoft Teams, Discord, Zapier/Make, and Custom webhook are configured on the Integrations tab. Team email recipients are configured on the Team Emails tab. Both share the same five events.

Five events are available across every destination:

• submission.received: a new submission was made.
• submission.verified: a reviewer approved a submission.
• submission.rejected: a reviewer rejected a submission.
• reward.sent: the reward delivery webhook fired successfully.
• reward.failed: the reward delivery webhook failed.

All five are pre-selected when you create a new integration or configure team emails. You opt out of events you do not want.

Empty state

The first time you open Settings > Notifications > Integrations, no integrations exist yet. Instead of a blank table, you see an empty state designed as onboarding: a short headline (“Never miss a review”), a one-line description of what alerts are for, and five platform cards laid out side by side: Slack, Microsoft Teams, Discord, Zapier, and Custom. A small footnote points to the Team Emails tab.

Each platform card is clickable. Clicking a card opens the create-integration dialog with that platform pre-selected, skipping the platform picker step. This is the fastest path from a brand-new account to a live Slack alert: empty state, Slack card, paste webhook URL, Save.

Once at least one integration exists, the empty state is replaced by the integrations list with an + Add Integration button.

Adding an integration

If you are starting from the empty state, click the platform card you want. If you already have at least one integration, click + Add Integration at the top of the list, then pick a platform from the picker step.

The configure dialog opens with everything pre-filled with sensible defaults:

• Name is auto-filled as {Platform} - {Today's Date} (for example, Slack - Jan 30, 2026). Edit it to something more descriptive if you have more than one integration per platform.
• Webhook URL is the field you supply. The exact value depends on the platform; see the per-platform sections below.
• Events has all five events pre-selected. Uncheck any you do not want this destination to receive.
• Campaigns defaults to All campaigns. Switch it to a specific subset if you only want certain campaigns to alert this destination.

You can save without testing, but the Test Connection button next to Save is the easiest way to confirm your URL is right before any real events fire.

Configuring Slack

Slack uses an Incoming Webhook URL. You generate it in Slack, then paste it into HighAdvocacy.

1. In Slack, open the workspace where you want alerts to land.
2. Go to Apps and find Incoming Webhooks. Add it to the workspace if it is not already installed.
3. Click Add New Webhook to Workspace.
4. Pick the channel where alerts should be posted.
5. Copy the webhook URL that Slack generates. It looks like https://hooks.slack.com/services/....
6. Back in HighAdvocacy, paste the URL into the Webhook URL field of the configure dialog.
7. Confirm the event selection and campaign scope, then click Test Connection.

A successful test posts a small sample message to the chosen Slack channel. The payload uses Slack’s Block Kit format, so each real alert renders as a structured card with the campaign name, platform, reviewer email, submission time, and a Review Now button that deep-links straight to the submission inside HighAdvocacy.

You can run multiple Slack integrations on the same account, for example, one channel for submission.received and a separate channel for reward.failed. Duplicates are allowed.

Configuring Microsoft Teams

Microsoft Teams uses an Incoming Webhook URL for the Teams channel you want to post into.

1. In Microsoft Teams, open the channel where alerts should land.
2. Open the channel’s Connectors (or Workflows) and add an Incoming Webhook.
3. Name the webhook (for example, “HighAdvocacy”) and copy the URL Teams generates.
4. Back in HighAdvocacy, paste the URL into the Webhook URL field.
5. Run Test Connection to confirm the webhook can post.

Alerts to Microsoft Teams use a Teams message card, so each alert renders in the channel with the event headline, the key fields inline, and a link back to the relevant submission or campaign in HighAdvocacy.

Configuring Discord

Discord uses a channel webhook URL for the Discord channel you want to post into.

1. In Discord, open Server Settings > Integrations > Webhooks for the server that contains the target channel.
2. Click New Webhook, pick the channel where alerts should be posted.
3. Name the webhook (for example, “HighAdvocacy”) and copy the URL Discord generates.
4. Back in HighAdvocacy, paste the URL into the Webhook URL field.
5. Run Test Connection to confirm the webhook can post.

Alerts to Discord use an embed message, so each alert renders in the channel with the event headline, the key fields inline, and a link back to the relevant submission or campaign in HighAdvocacy.

Configuring Zapier

Zapier (and Make) integrations use a generic webhook URL exposed by their Webhook by Zapier trigger.

1. In Zapier, create a new Zap.
2. For the trigger app, pick Webhooks by Zapier.
3. Choose the Catch Hook event. Zapier generates a webhook URL.
4. Copy that URL.
5. Back in HighAdvocacy, paste the URL into the Webhook URL field of the configure dialog.
6. Run Test Connection. Zapier should show the sample payload in its trigger setup view, which you then use to map fields to whatever action step you build next (Google Sheet row, CRM record, Slack message, anything in Zapier’s 5000+ apps).

The payload sent to Zapier and Make is the standard JSON format: event, timestamp, and a data object containing the submission and campaign details. Field names and structure are documented in the per-event payload reference (see Notifications overview for the field list).

Configuring a custom webhook

A custom webhook is the lowest-level option: any HTTPS endpoint you control receives the standard JSON payload. Use this for internal tools, custom dashboards, or downstream systems that do not match Slack, Microsoft Teams, Discord, or Zapier patterns.

1. In your downstream system, expose an HTTPS endpoint that accepts a POST with a JSON body.
2. Decide whether your endpoint requires authentication. If it does, plan which header keys and values you will need.
3. In HighAdvocacy, open the configure dialog with Custom as the platform.
4. Paste your endpoint URL into the Webhook URL field. HTTPS is required: the URL must start with https://.
5. If your endpoint requires auth headers, expand the advanced section and add up to 5 custom header pairs (for example, Authorization: Bearer ...). Header keys must be alphanumeric and hyphens only.
6. Run Test Connection.

Two things to know about custom headers:

• You can add up to 5 header pairs per integration.
• Custom headers cannot override system headers. Content-Type, X-HighAdvocacy-Signature, and User-Agent are always set by HighAdvocacy and your values for those keys are ignored.

The X-HighAdvocacy-Signature header is attached to every webhook delivery. It is signed with your account’s HMAC signing secret. Use it to verify that incoming deliveries actually came from HighAdvocacy. The secret is shown on the Integrations tab and can be rotated; rotation does not disable any active integrations, but it does change the signature on all future deliveries, so any service verifying signatures will need to be updated.

Testing the connection

The Test Connection button works the same way for every platform. It sends a synthetic event with dummy data to your URL and reports back what happened.

On success, you see a green confirmation with a short message, “Connected successfully! Your Slack channel will receive alerts.” (or the platform equivalent). A Show details disclosure reveals the technical detail: HTTP status code (200), response time in milliseconds, the exact payload that was sent, and the response body returned by your endpoint.

On failure, you see a red message in plain language (“Couldn’t reach your Slack. Double-check the URL and try again.”), and the same Show details disclosure surfaces the HTTP status code, response body, and any error returned by the receiving system.

Test events:

• Do not appear in delivery logs.
• Do not increment the failure counter that drives auto-disable.
• Are exempt from the 100-deliveries-per-minute rate limit.

You can test as many times as you want without consequence. Save the integration when you are satisfied; saving without testing is allowed but not recommended.

Per-campaign coverage rules

Every integration is scoped either to all campaigns or to a specific list of campaigns. Pick the right scope when you save, then forget about it.

All campaigns (default) is dynamic. It includes every existing campaign and every campaign you create in the future. New campaigns never need to be remembered; the integration fires for them as soon as they go live.

Specific campaigns lets you select a subset from a dropdown. Two behaviors are worth knowing:

• New campaigns are auto-added to the selection. When you create a new campaign, it is automatically added to the selected list of every integration with a specific scope. The integration detail page shows a “Recently added” indicator next to any campaign that was added automatically, so you can review and remove if the alert is not wanted. This is the inverse of the more obvious “remember to add new campaigns to your alerts” pattern: habituated users assume their alerts cover new campaigns, so missing an alert is worse than receiving one you can remove.
• Deleting a campaign removes it from every integration’s selection. If all of a specific-scope integration’s selected campaigns get deleted, the integration stays active but fires for nothing. A warning banner appears on the integration’s detail page so you notice.

Team email recipients are not subject to campaign scoping; team email alerts fire for every campaign.

Failure handling

Webhook delivery is best-effort. Receiving systems go down, URLs get revoked, channels get archived. The system handles this without your team needing to monitor.

Every delivery is attempted once. On failure, the integration’s consecutive failure counter increments. After 5 consecutive failures, the integration is automatically disabled and an email is sent to the account Owner explaining what happened and pointing back to Settings > Notifications > Integrations to re-enable. The integration row in the list shows a red Failed status badge. The integration’s detail page shows a warning banner naming the failure count and the last failure time, with a Re-enable button.

The failure counter resets to 0 when:

• Any delivery to that integration succeeds.
• You manually re-enable the integration.
• You edit the integration’s webhook URL.

In practice this means a transient five-minute outage at your downstream system is unlikely to disable an integration, because the next successful delivery resets the counter. A persistently broken URL (for example, a Slack webhook revoked when someone deactivated the Incoming Webhooks app) will disable after five failures, which is by design: you would rather hear about a broken integration than have alerts silently dropping.

Re-enabling an integration without first fixing the cause will let it run, fail again, and auto-disable a second time. Edit the URL or fix the receiving system before re-enabling.

Limits

Two account-wide limits apply.

• 10 integrations per account. Once you hit 10, the + Add Integration button is disabled with the message “You’ve reached the maximum of 10 integrations. Remove unused ones to add more.” Duplicates within the limit are allowed, for example, two Slack integrations posting to different channels.
• 10 team email recipients. On the Team Emails tab, once 10 addresses are added the input is disabled with the message “Maximum 10 recipients reached.” Recipients can be individual people or distribution lists; a distribution list counts as one recipient.

Per-integration limits:

• 100 characters maximum on the integration name.
• 5 custom header pairs maximum on a custom webhook integration.
• At least 1 event must be selected: you cannot save an integration with all events unchecked.

System rate limit:

• A maximum of 100 webhook deliveries per minute per account. Test events do not count toward this limit. Real deliveries that exceed it are dropped, not queued, in this version.

Common errors

If something is not working, walk through this list before contacting support.

If a behavior matches none of these and the delivery history shows no entries for events you expect, confirm the event type is checked on the integration. An integration with all submission.* events checked but reward.sent unchecked will not deliver a reward-sent event even though everything else is configured.

Related docs

• Notifications & Alerts overview: for the side-by-side of submitter emails vs team alerts and the full event list
• Submission status emails: for the three submitter-facing emails configured separately
• Roles and permissions: only Owner and Admin can edit integrations and team emails
• Campaigns: for how campaign scope on an integration ties back to campaign creation