Action Type: Email

Security Requirements and Controls

Email Action sends messages as emails. This action will send a styled email with the most important aspects of an alarm, including a hyperlink back to LogScale with the result. Email delivery services integrated with LogScale such as Postmark are supported, see Email Configuration for further details.

Screenshot of the Email Action configuration form displaying fields for Recipients, checkboxes for attaching CSV results and using custom email subjects or templates, and the action name field

Figure 277. Configuring Email Action


Parameter Description
Name The name provided for the email action.
Recipients

A comma-separated list of email addresses.

Recipients can include message templates that resolve at trigger time. Templates can be the complete email address (for example, {field:email}) or embedded within an address (for example, {field:username}@crowdstrike.com). See Dynamic Email Recipients for details.

Attach results as a CSV file The results of the query that triggered the email will be attached as a CSV to the email,with a limit of 5MB. If the file exceeds this limit, results are truncated and an error.txt attachment is also sent where the number of events being truncated is specified.
Use custom email subject When selected, will open a dialog where the subject title can be edited. Variables can be used according to the Message Templates and Variables markup.
Use custom email template When selected, will open a dialog where the subject body can be edited. Variables can be used according to the Message Templates and Variables markup.

Note

You can see which email messages were generated by the events that triggered the action: go to humio-activity repository and search on the messageId field.

Dynamic Email Recipients

Email actions support dynamic recipients through message templates. Most templates available in email subjects and bodies can also be used in the Recipients field, including field references like {field:fieldName} that resolve from event data at trigger time.

Templates can form the entire recipient address or be embedded within an address. For example:

  • Complete address: {field:email}

  • Embedded in address: {field:username}@crowdstrike.com

  • Using trigger name: {name}@example.com

This enables sending notifications directly to users referenced in log events. For example, notify a user whose login failed based on email or username fields in the event.

Note

Static and dynamic recipients can be mixed in the same recipients list.

Warning

The following templates produce large or multi-line output and are not permitted in recipients:

  • {url}

  • {query_result_summary}

  • {events_str}

  • {query_string}

  • {warnings}

  • {events}

  • {events_html}

  • {schedule}

Recipient Resolution by Alert Type

How recipients resolve depends on the trigger type:

  • Filter alerts: The recipient calculates from the single event that triggered the alert. The email body contains only that event.

  • Aggregate alerts, legacy alerts, and scheduled searches: The recipient calculates from the first event only, but the email body contains all events from the query results. This creates a risk when events have different values for the field referenced in the recipient template.

Query Scoping for Data Privacy

When using field references in recipients, you must filter your query to return only events appropriate for the recipient. Without proper filtering, recipients may receive notifications containing other users' data.

Problem scenario: A scheduled search with an unfiltered query: 

loglevel=ERROR action=login status=failed

With recipient {field:email}, this query:

  1. Returns failed login events for multiple users (Alice, Bob, Charlie)

  2. Extracts the recipient email from the first event (for example, alice@example.com)

  3. Sends Alice an email containing all users' failed login data

Solution 1: Use filter alerts (recommended)

Filter alerts trigger on each individual event. The recipient and the event data always match because only one event triggers each notification. 

loglevel=ERROR action=login status=failed

This query, when used in a filter alert with recipient {field:email}, sends one email per failed login to the affected user only.

Solution 2: Filter to a specific user

For scheduled searches, add filters that limit results to a single user: 

username=alice loglevel=ERROR action=login status=failed

All events in the results belong to Alice, so Alice should receive all of them.

Warning

Do not use aggregate alerts, legacy alerts, or scheduled searches with dynamic recipients and unfiltered queries. The recipient resolves from the first matching event only, but the email body and attachment contain all matching events, potentially exposing data from other users or systems to the resolved recipient.