Form notifications for email, Slack, Discord, and webhooks.

Choose a destination for each kind of work.

Email is the durable baseline for a contact or lead owner. Slack and Discord are useful team signals when a fast alert matters. A generic webhook is the flexible path when an automation platform, CRM, ticket system, or private receiver needs the structured payload.

Configure the destination and recipient permissions before launch, and keep the browser form focused on collecting the submission. FormsFort can deliver accepted submissions to email, Slack, Discord, and webhooks; the destination still owns its own access controls, formatting rules, rate limits, and outage behavior.

• Email provides a durable notification and delivery record for the owner.
• Slack and Discord fit team triage; a webhook fits custom routing and enrichment.
• A static HTML form needs no notification server or chat token in browser code.
• Check plan availability and destination limits before promising a high-volume alert path.

Acceptance comes before notification.

Validation and spam checks run before normal notification work is queued. A rejected submission should not create an ordinary email, Slack, Discord, or webhook alert. Treat an accepted browser response as the start of delivery, not proof that every downstream destination has processed the event.

Use the request ID from the response or delivery record as the correlation key. Record it with the event in your receiver logs. If a receiver returns a transient failure, retries may deliver the same request more than once, so make webhook and automation handlers idempotent before production traffic arrives.

• Log request IDs alongside receiver status, response time, and any downstream event ID.
• Return a 2xx response quickly after durable receipt; do slow enrichment asynchronously.
• Deduplicate by request ID or another stable event key before creating a ticket or CRM record.
• Inspect rejection and delivery status separately when an expected notification is missing.

Static-site setup with a safe webhook handoff.

The example below is ordinary accessible HTML: labels point to controls, the fieldset provides a group name, and native constraints catch empty or malformed values. The access key is intended for the public form action; never place Slack, Discord, CRM, or webhook authentication tokens in the page.

The hidden webhook value illustrates a form-level routing value used by this setup. If your project configures destinations in the FormsFort dashboard instead, omit that field and keep the destination secret there. Test the receiver with a non-production endpoint first, then use the webhook tester to inspect status, body, and timing.

• Verify the recipient and allowed domain before publishing the form.
• Exercise one accepted request and one rejected request, and save both request IDs when available.
• Confirm email, Slack, Discord, and webhook formatting with a realistic payload.

Use automation paths for Telegram and Google Sheets.

Telegram and Google Sheets are not native notification destinations on this page. Send the accepted payload through the webhook path to an automation platform or your own handler, then call the Telegram Bot API or Sheets workflow there. This keeps bot tokens and spreadsheet permissions out of the browser and gives you one place to retry and deduplicate.

• Use a dedicated incident or customer-support platform when notifications need on-call escalation, ticket state, or long-term conversation history.
• Use a custom worker when each event needs private enrichment, strict ordering, or transactional writes before a notification is sent.
• Use the destination's native event system when you need guaranteed ordering or domain-specific audit controls that a form notification cannot provide.
• Do not treat a browser success message as proof that every downstream destination accepted the delivery; inspect the delivery record and receiver logs.