Skip to main content

6. Set Up Your First Notification

The final step of the Quickstart: configure one notification endpoint and one rule, so the platform tells you when something happens instead of waiting for you to look. This page is for the administrator finishing the initial setup, and it is the step that turns everything built so far from a system you visit into a system that reaches you.

Before You Begin​

  • You can reach Configuration → Notifications and Configuration → Processors (v1: Platform → Administration → Notifications and Platform → Processors).
  • You have the delivery details for wherever the notification should go: a distribution address for email, or a configured Slack workspace and a channel name.
  • You have read step 5, so you know what a behavior summary is; that is what will be arriving in your inbox.
This is the one quickstart step that affects other people

A badly scoped rule mails everyone on the list, repeatedly. If you are exploring an instance someone else runs in production, read this page rather than doing it, or use an endpoint that delivers only to yourself.

How Notifications Are Put Together​

Three objects, and they are configured in three different places. That surprises people, so it is worth ten seconds before any clicking:

ObjectWhat it doesWhere it lives
FPL actionThe code that actually sends the messageConfiguration → Processors, Actions tab (v1: Platform → Processors)
EndpointWhere a notification goes (an address or a Slack channel), backed by an FPL actionConfiguration → Notifications, Endpoints tab (v1: Platform → Administration → Notifications)
RuleWhat goes there: which patterns trigger which endpointsThe same page, Rules tab

Two consequences follow from that shape, and both catch people out:

  • The FPL Action is a required field on the endpoint form, not an advanced option. The action has to exist before you can save an endpoint, which is why the order below is actions first, endpoint second, rule third.
  • An endpoint with no rule pointing at it delivers nothing, silently. There is no error and no warning; the endpoint simply sits there. When a channel that used to work goes quiet, check the Rules tab before assuming a delivery failure.

Why this is more flexible than a mail setting​

Because delivery is an FPL action rather than a built-in mailer, the same mechanism that sends an email can post to Slack, call a webhook, or open a ticket in an external system. FPL is the Fluency Programming Language, and actions are one of its object types; the price of that flexibility is the extra object you are about to go and find.

Step 1: Choose the Endpoint Type​

The page offers two endpoint types.

Email​

The right first choice, because it needs no external setup. You need a recipient address, and for a first notification that should be your own, not a team distribution list.

Slack​

Better for a team that already triages in chat, but the Slack side has to be prepared first: the workspace is connected as an integration on Configuration → Integrations (v1: Platform → Applications → View Integrations), and the endpoint form then asks you to pick that integration and name a channel. See Slack Integration.

Step 2: Find the FPL Action That Will Back the Endpoint​

  1. In the navigation rail, open Configuration and click the Processors card.
  2. Select the Actions tab from the row of type tabs (Processors, Receivers, Packers, Actions, Rules) above the card grid.
  3. Look for an action that sends the kind of message you want. Each action card shows its name, its description, and its Target: what it delivers to, such as Platform Notification: Email. Type in the Search processors... field and click Search to filter by name, and set the sort drop-down to Last updated to see what has been touched recently.

Processors page on the Actions tab, with three email action cards whose Target is Platform Notification: Email, and the header button relabelled Add Action

Note what you find, because the endpoint form in step 4 offers these by name in its FPL Action drop-down and nothing else.

If there is no suitable action​

The intended way to get the behavior-summary notification objects into an account is not to assemble them by hand; it is to install the BehaviorSummary Notification Export application template.

  1. In the navigation rail, open Applications and click Install Application.
  2. Choose BehaviorSummary Notification Export from the System Components category of the Application Catalog. Its description reads Internal: BehaviorSummary notification export (email).
  3. It takes no settings, so the form is just Instance name and Display name. Click Install Application.

Install BehaviorSummary Notification Export form with the Application section's Instance name and Display name fields, above Cancel, Dry run and Install Application

Open the installed application's details by clicking its row on Applications. Because the template takes no settings, the details page has no Parameters card, only Actions, which records what it built: a NotificationExport router, a BehaviorSummary data source, the connection between them, and the BehaviorSummary_Filter and BehaviorSummary_Email pipes.

Read that list before editing any of those objects by hand: they belong to the application, and changing them outside it is how a working export quietly stops matching what the application thinks it installed.

Then go back to the Actions tab on Configuration → Processors (v1: Platform → Processors → Actions) and check it again. If the drop-down in step 4 is still empty afterwards, the action has to be written for your account: see FPL for the language, or raise a support ticket rather than working around it; an endpoint cannot be saved without one.

Step 3: Open the Notifications Page​

In the navigation rail, open Configuration and click the Notifications card. The page is titled Notifications, subtitled A list of configured notification rules and endpoints.

Notifications page on the Endpoints tab, with Email and Slack buttons in the header and one Email endpoint card named BehaviorSummary_Export

Two tabs below the header, Endpoints and Rules, switch the page between its two lists; it opens on Endpoints. On that tab, the header carries an Email button and a Slack button for adding an endpoint of each type. Configured endpoints appear underneath as cards.

Step 4: Add the Endpoint​

  1. Make sure you are on the Endpoints tab.
  2. Click Email or Slack in the header, for the type you chose. Each opens the Add Notification Endpoint dialog with Type already set and read-only.
  3. Fill in the form and click Save. Cancel, or the × in the title bar, closes it without saving.

For an Email endpoint:

Add Notification Endpoint dialog for an Email endpoint, with the FPL Action drop-down open listing Alert_Email_Action, Generic_Email_Action, and MetricAlert_Email_Action

  • Details: Name (required); Type, fixed to Email; FPL Action (required), a drop-down (placeholder Select an action) of the account's email actions from step 2.
  • Email Configurations: To (required): type an address and press Enter to add it, and repeat for each recipient; as you type, the field suggests the addresses of the account's users. CC takes additional recipients the same way.

For a Slack endpoint:

Add Notification Endpoint dialog for a Slack endpoint, with Name, read-only Type Slack, FPL Action, and under Slack Configurations the Integration drop-down and Channel field

  • Details: Name (required); Type, fixed to Slack; FPL Action (required), a drop-down of the account's Slack actions, which reads No options when the account has none.
  • Slack Configurations: Integration (required), a drop-down of the account's Slack integrations, whose Create New Integration entry starts a new one, and Channel (required), the channel name to post to.

Give the endpoint a name that says where it goes rather than what it is for (soc-team-email, #sec-alerts), because the rule in step 5 refers to it by name, and one endpoint can serve several rules.

Reading and correcting the endpoint card​

Each configured endpoint appears as a card. The header shows its type's icon, its name, and a red Delete; the body lists its properties: for an Email endpoint, Type, FPL Action, and Email (each recipient address, shown as a tag).

Clicking the card reopens it as the Edit Notification Endpoint dialog, filled in with its current values, so a wrong recipient can be corrected in place: the delivery configuration (for an Email endpoint, To and CC) is what the dialog can change. Name and Type are read-only and FPL Action is disabled, so an endpoint with the wrong name or action is replaced rather than edited: create a new one and delete the old one with the Delete on its card.

Step 5: Define What Gets Sent​

An endpoint on its own delivers nothing. A rule is what connects a trigger to it, and it is a separate object on a separate tab.

  1. Switch to the Rules tab. The Email and Slack buttons in the header are replaced by Add Notification Rule; with nothing configured, the tab reads No rules configured.

    Notifications page on the Rules tab, reading No rules configured, with the Add Notification Rule button in the header

  2. Click Add Notification Rule. The dialog has a single Details section with three fields, all required:

    • Name: a name for the rule.
    • Patterns: the patterns that trigger the rule: type a pattern and press Enter to add it. A rule can have several. This is the only scoping control the dialog has.
    • Endpoints: the endpoints the rule delivers to, picked from a drop-down (placeholder Add…) that lists each endpoint as its type and name, such as Email: BehaviorSummary_Export. Each chosen endpoint becomes a tag with an × to remove it, so one rule can reach both an email list and a Slack channel.

    Add Notification Rule dialog with the Email: BehaviorSummary_Export endpoint chosen as a tag and the Endpoints drop-down reading No more options

  3. Click Save.

Start narrow​

An over-broad first notification rule is how a team learns to ignore notifications, and the damage is hard to undo: once people filter your alerts to a folder, a correct one will not reach them either.

The dialog has no severity control. Severity is settled before a rule sees anything, by the notification threshold: only summaries scoring above 3000 notify, so Low and Medium tickets never reach an endpoint. Narrowness therefore comes from Patterns and from the endpoint you point at. For a first rule: pick one pattern, point it at one endpoint that delivers to you, and live with it for a few days. Widen the pattern set and swap in the team's address once you know what the volume actually is.

Step 6: Confirm It Is Wired Up​

The endpoint dialogs offer Save and Cancel only; there is no send-a-test control on this page. Verification is therefore structural first, then real:

  1. On the Endpoints tab, confirm the endpoint card shows the expected Type, FPL Action, and destination.
  2. On the Rules tab, confirm the rule exists and names your endpoint under Endpoints. A rule that does not name it is the silent-failure case described at the top of this page.
  3. Wait for the first qualifying ticket (one scoring above the notification threshold), then read the delivered message: it should identify the entity, the severity, and give you a way back into the platform.

If nothing has qualified yet, that is step 5's situation and not a delivery problem: a quiet queue delivers quietly.

How to Tell It Worked​

  • The endpoint appears on the Endpoints tab with the expected type, FPL action, and destination.
  • The rule appears on the Rules tab, names one pattern, and names your endpoint.
  • When a qualifying ticket is raised, the message arrives.
  • The delivered message contains enough context to decide whether to act, without first opening the platform.

If It Did Not Work​

SymptomLikely causeWhat to do
The FPL Action drop-down is empty and the endpoint cannot be savedNo action exists in the accountInstall BehaviorSummary Notification Export (step 2), then re-check the Actions tab on Configuration → Processors (v1: Platform → Processors → Actions)
The endpoint saves, but nothing is ever deliveredNo rule names it, or no ticket has qualifiedCheck the Rules tab first; then check that tickets are being raised at all on Overview Summary
Email is not received, and the rule looks rightDelivery is being filtered on the recipient sideCheck spam handling and any allow-list requirement on your mail gateway
Slack messages do not appearThe Slack integration, its token, or the channel permissions are wrongSlack Integration
Too many notificationsThe pattern set is too broadNarrow the Patterns on the rule rather than deleting the endpoint: deleting it hides the problem and loses the configuration
It worked, then stoppedA pipeline object the notification export owns was edited by handCompare against the Actions list in the application's details

Deeper symptom-by-symptom diagnosis is in Notification Delivery.

You Have Finished the Quickstart​

You now have a Microsoft 365 tenant delivering three feeds into the data lake, ingress you can verify in three places, a search you know how to scope and read, a detection you have traced from a risk score back to the vendor's own record, and a notification that reaches you without you looking.

That is one source. The rest of the manual is about the other ones, and about making what you just built specific to your organization.

Where to Go Next​

Last updated on