Alert rules never talk to Slack or email directly. They hand the alert payload to an integration flow which does the delivery. That separation means you can change how notifications are sent without touching a single rule, and the same flow can handle notifications for many rules at once.
When to build a new flow
Most organisations end up with a short list of flows:
- Slack #security alerts for high-severity security events.
- Slack #it-ops for operational noise like silent sources.
- Email on-call for critical events that need paging out of hours.
Start with one flow and add more as your rule library grows.
Create the flow
- Open the Integration flows list from the sidebar (under Configuration).
- Click New Integration Flow.
- Give it a clear name that describes the destination, for example Slack #siem-alerts.
- Set the Trigger to Manual / webhook. SIEM alerts invoke the flow through its webhook trigger, so you do not need to configure a schedule.
- Link the Connection if the destination needs one (Slack or email SMTP, generic HTTP endpoint).
- Set Active to Yes.
- Save the flow.
Add the steps
Open the flow's Steps panel. A minimal flow for Slack looks like this:
- Set Variable: pull useful fields out of the incoming payload so you can format them: ruleName, severity, summary, sampleEventIds, deepLink.
- Map: build the Slack message payload with blocks for the summary, severity badge and a link back to the alert.
- External Post: POST the mapped payload to the Slack incoming webhook URL.
Other step types available:
- Fetch: GET data from an external API, for example to enrich the alert with extra context.
- Validate: reject payloads that do not match your expected shape.
- Condition: branch on severity or tags (for example, route critical to paging, everything else to Slack).
- External Patch: update a record in a downstream system (open a ticket, acknowledge in PagerDuty).
- Email: send a formatted email through the tenant's SMTP connection.
Payload available to the flow
When an alert rule invokes a flow it hands over the following fields:
- ruleId, ruleName: which rule fired.
- severity: from the rule.
- summary: a one-line description produced by the rule evaluator.
- sampleEventIds: up to ten log event IDs that matched.
- deepLink: a URL into the alert record in DemandFlow.
- platform, sourceIds: scope metadata from the rule.
- firedAt: ISO timestamp.
Use Set Variable and Map steps to shape these into whatever format the target channel expects.
Wire the flow to a rule
Once the flow exists and is saving, set it on the rule:
- Open the alert rule.
- Pick the flow in the Notify via lookup.
- Save.
The next time the rule fires, the flow runs and the notification lands in the target channel.
Test the flow
Every integration flow has a Test action in its toolbar. Click it to run the flow with a sample payload you type in, so you can iterate on the Slack or email format without waiting for a real alert to fire.
Viewing execution history
Open the flow and look at the Executions panel to see recent runs, their inputs, outputs and any errors. If a rule is firing but nothing is appearing in the channel, this is the first place to look.
Tips
- Keep the flow's logic lean. If you need complex routing, let a Condition step split traffic and point different rules at different flows.
- Build one rich flow that includes the deep link, sample event IDs and source info. Rules that point at this flow automatically inherit the richer format.
- Test with the Test action before you wire a flow to a noisy rule. Chasing down a typo in production is no fun.
What to do next
You now have the full picture: sources, ingest, viewing, rules, alerts, dashboards and notifications. Use the overview to remind yourself how the pieces fit, and come back to any specific guide when you need a refresher.