Email Action Templates

An Automated Threat Hunting (ATH) playbook monitors your environment on a schedule, runs a query against your data, and takes action when it finds results that match a condition you define. One of the actions a playbook can take is sending an email notification to alert your team that something requires attention.

This topic focuses on writing templates for the Subject and Email Body fields of an email action. An email action also includes recipients, attachments, and other configuration options, but those settings are described in the Automated Threat Hunting playbook documentation. Here you'll learn how template syntax works and how to create effective email notifications.

• Overview

• Template Syntax

• How the Email Body Is Processed When You Save

• Run-for-All Mode (Default)

• Run-for-Each Mode

• Comparison of the Two Modes

• Custom Jinja2 Filters

• Troubleshooting

Overview

When you configure an email action, you can write templates that control the content of the email—one template for the subject and another for the body. The Subject field and Email Body field can each contain plain text, template expressions, or a combination of both. If you use templates in both fields, you can use the same or different template languages and Stellar Cyber will detect the language for each. The Email Body field can also be left empty if you do not want to include a message body.

Templates use placeholder variables that Stellar Cyber fills in automatically with real data from the query results at the time the playbook runs. This means you write the template once, and Stellar Cyber generates a customized email each time the playbook triggers.

Choosing a Sending Mode

Before looking at template syntax, decide how you want the email action to send notifications. The email action supports two sending modes:

• Run-for-all mode (the default) – Stellar Cyber sends one email that summarizes all matching records, and every recipient receives the same email. For example: "Here are the 12 failed login attempts detected in the last hour." This mode is active when the Run for each record option is not selected in the email action settings.

• Run-for-each mode – Stellar Cyber sends a separate email for each matching record, and each email contains only the data from this record. For example: "A failed login from IP address 10.0.0.1 was detected on the account for amy." This mode is active when you select Run for each record in Actions: Email.

The advantages that each mode offers can help you choose between them:

• Use run-for-all mode when a fixed set of recipients, such as a SOC team, needs a single overview of everything the playbook found. Run-for-all mode also supports attachments and works with playbooks that use calculations.

• Use run-for-each mode when you want each record to produce its own notification. Because the Recipients field supports template variables in this mode, each email can be addressed using data from its own record; for example, each tenant's administrators can receive only the notifications for that tenant. Even with a fixed recipient list, run-for-each mode is useful when you want each record to become a separate, trackable message in a shared inbox or ticketing system.

Each mode provides a different set of data to the template, so the template you write depends on the mode you are using. A template written in the run-for-all style also works in run-for-each mode (see Using Run-for-All Style Templates in Run-for-Each Mode), but a template written in the run-for-each flat style does not work in run-for-all mode. This topic explains both modes, shows you the data available in each one, and provides example templates you can adapt for your own playbooks.

Source:

                <b>Stellar Cyber Alert Notification</b><br />
                <br />
                <b>Alert:</b> Scanner Reputation Anomaly<br />
                <b>Source IP:</b> 195.178.110.137<br />
                <b>Severity:</b> High

                After processing — a <br /> is added at every source line break, on top of the tags you wrote:

            <b>Stellar Cyber Alert Notification</b><br /><br /><br /><br /><b>Alert:</b> Scanner Reputation Anomaly<br /><br /><b>Source IP:</b> 195.178.110.137<br /><br /><b>Severity:</b> High

Source:

                <b>Stellar Cyber Alert Notification</b><br /><br /><b>Alert:</b> Scanner Reputation Anomaly<br /><b>Source IP:</b> 195.178.110.137<br /><b>Severity:</b> High

            After processing — unchanged, because there are no source line breaks to convert.

Run-for-All Mode (Default)

Run-for-all mode is the default behavior. It is active whenever the Run for each record option is not selected in the email action configuration.

How It Works

When the playbook triggers, Stellar Cyber collects all matching records from the query results and passes them to your template as a single data structure. Your template then has access to the entire set of results at once. Because all records are available together, you must write iteration logic in your template to loop through the records and display each one.

Stellar Cyber sends one email containing the rendered output of your template. All recipients receive the same email.

Data Available to Templates (Template Context)

In run-for-all mode, the subject template and the email body template have access to the full Interflow record. The following are the key parts of this record that you can reference in your templates:

Each item inside ctx.payload.filtered is a record object with the following structure:

• _index: The index where the record is stored.

• _type: The document type.

• _source: The actual event data fields (for example, user, srcip, event_type, event_score). When referencing a field inside a record, you access it as _source.fieldname.

Template Examples

Mustache Example

These templates produce a single email with a subject identifying the total number of detected alert events and the email body listing all detected events in bulleted format.

Subject

Alert: {{ctx.payload.filtered_total}} events detected

Email Body

The following {{ctx.payload.filtered_total}} events were detected at {{ctx.trigger.triggered_time}}:

{{#ctx.payload.filtered}}
- User: {{_source.user}}, Event: {{_source.event_type}}, Source IP: {{_source.srcip}}
{{/ctx.payload.filtered}}

How this works:

• {{ctx.payload.filtered_total}} inserts the count of matching records.

• {{#ctx.payload.filtered}} begins a loop over all matching records.

• Inside the loop, {{_source.user}}, {{_source.event_type}}, and {{_source.srcip}} pull field values from each record.

• {{/ctx.payload.filtered}} ends the loop.

Jinja2 Example

These templates use Jinja2 to add conditional logic—in this case, labeling events by severity based on their score—to identify the total number of alert events requiring review in the subject and present them in the email body.

Subject

Security Alert: {{ ctx.payload.filtered_total }} events require review

Email Body

Playbook triggered at {{ ctx.trigger.triggered_time }}.

{% for hit in ctx.payload.filtered %}
{% if hit._source.event_score >= 75 %}[CRITICAL]
{% elif hit._source.event_score >= 50 %}[MAJOR]
{% elif hit._source.event_score >= 25 %}[MINOR]
{% else %}[NOTICE]
{% endif %} User: {{ hit._source.user }}, Score: {{ hit._source.event_score }}, IP: {{ hit._source.srcip }}
{% endfor %}

How this works:

• {% for hit in ctx.payload.filtered %} loops through each record, assigning it to the variable hit.

• The {% if %} / {% elif %} / {% else %} block checks the event score and inserts a severity label accordingly.

• Field values are accessed as hit._source.fieldname.

Features Available in Run-for-All Mode

• Attachments: You can attach Interflow data (JSON), CSV calculation results, and JSON calculation results to the email. These options are configured in the email action settings.

• Recipients: You specify recipients using static email addresses or saved recipient references. Dynamic per-record recipients are not available in this mode.

• No email throttle: Because only one email is sent per execution, there is no per-execution email limit.

Run-for-Each Mode

Run-for-each mode is activated by selecting the Run for each record option in the email action configuration.

The Run for each record option is available only for playbooks that do not use calculations.

How It Works

Instead of passing all records to a single template rendering, Stellar Cyber processes each matching record individually. For every record that the query returns, Stellar Cyber renders the template using the data in that record and sends a separate email. This means that if the query returns 10 matching records, Stellar Cyber sends 10 emails—each one customized with the data from its corresponding record.

Stellar Cyber works through the matching records one at a time. During each rendering, the record being processed is called the current record—the record whose email is being generated at that moment. For example, if a query matches 20 records, the playbook performs 20 separate renderings, one for each record.

Because each template rendering receives only one record, you do not need to write any iteration logic. You simply reference the fields you want directly.

Data Available to the Template (Template Context)

In run-for-each mode, the template context is built from a single record, and two template styles are supported:

• Flat style (recommended for new templates) – Reference fields directly by name, such as {{user}}. This style is described in this section.

• Run-for-all style (supported for compatibility) – Templates written for run-for-all mode, which loop over ctx.payload.filtered, also render correctly in run-for-each mode. See Using Run-for-All Style Templates in Run-for-Each Mode.

For the flat style, Stellar Cyber takes _source fields in the record and "flattens" them to the root level of the context, meaning you can access them directly by field name without any prefix. For convenience, the fields are also accessible under _source.fieldname.

For example, given a record like this—

{
  "_id": "record_123",
  "_index": "aella-ser-2025.01.01-",
  "_source": {
    "user": "john",
    "email": "john@example.com",
    "event_type": "login_failure",
    "severity": "high",
    "srcip": "10.0.0.1"
  }
}

—the template context becomes:

Both access patterns produce the same result. The direct pattern (without _source.) is recommended for readability.

Using Run-for-All Style Templates in Run-for-Each Mode

Run-for-each mode also renders templates that were written for run-for-all mode—templates that reference the ctx object and loop over ctx.payload.filtered. This compatibility lets you enable Run for each record on an existing email action and keep the template that the action already uses. You do not need to rewrite templates that were originally written for run-for-all mode.

The key to understanding how the same template behaves in the two modes is what ctx.payload.filtered contains in each mode:

• In run-for-all mode, ctx.payload.filtered contains all matching records. A loop over the list produces one line for each record, and the single email summarizes all of them.

• In run-for-each mode, Stellar Cyber renders the template separately for each record, and during each rendering, ctx.payload.filtered contains only that one record. The loop still runs, but it runs only once for each email, so each email shows only the data from its own record.

Example: One Template, Two Modes

Suppose a playbook query matches the following three records:

The Email Body field contains this run-for-all style template:

{{#ctx.payload.filtered}}
User: {{_source.user}}, IP: {{_source.srcip}}
{{/ctx.payload.filtered}}

With Run for each record not selected (run-for-all mode), the playbook sends one email, and the loop produces one line for each of the three records:

User: amy, IP: 10.0.0.1
User: bob, IP: 10.0.0.2
User: carl, IP: 10.0.0.3

With Run for each record selected (run-for-each mode), the playbook sends three emails. During each rendering, ctx.payload.filtered contains only the record for that email, so the loop runs once and each email contains a single line:

Email 1:  User: amy, IP: 10.0.0.1
Email 2:  User: bob, IP: 10.0.0.2
Email 3:  User: carl, IP: 10.0.0.3

In run-for-each mode, the following flat-style template produces the same three emails without a loop:

User: {{user}}, IP: {{srcip}}

Choosing Between the Two Styles

• When you write a new template for run-for-each mode, use the flat style. It is simpler to read and does not require a loop.

• When you switch an existing email action from run-for-all mode to run-for-each mode, keep the existing template. It renders correctly without changes, and each email shows only the data from its own record.

Template Examples

Basic Notification

Subject

Security Alert for {{user}}

Body Email

Hello {{user}},

A {{severity}}-severity event was detected on your account:

  Event type: {{event_type}}
  Source IP:  {{srcip}}

Please review this activity. If you do not recognize it, contact your security team immediately.

How this works:

• There is no loop. The template references fields directly because it renders against a single record.

• {{user}}, {{severity}}, {{event_type}}, and {{srcip}} are all fields from _source in the record, made available at the root level.

Using Jinja2 Filters

Subject

[{{ event_score | to_severity(uppercase=true) }}] Alert for {{ user }}

Body Email

Event detected at {{ timestamp | ts_format(hour_shift=-5, format="%Y-%m-%d %H:%M:%S") }} (EST):

  User:     {{ user }}
  Type:     {{ event_type }}
  Severity: {{ event_score | to_severity(capitalize=true) }}
  Source:   {{ srcip }}

How this works:

• | to_severity converts a numeric event score to a human-readable severity label (see Custom Jinja2 Filters below).

• | ts_format formats a millisecond timestamp into a readable date/time string with an optional timezone offset.

Dynamic Recipients

One of the most powerful features of run-for-each mode is the ability to send each email to a different recipient based on data in the record itself. In the Recipients field of the email action configuration, you can use template variables in addition to static email addresses.

How Recipient Variables Resolve

When Stellar Cyber processes a record in run-for-each mode, it renders the Recipients field against the same record that it uses to render the subject and the email body. The content of each email and the recipient address for that email therefore always come from the same record. There is no separate routing step—the process works like a mail merge, in which each row of a spreadsheet produces one letter and the address on the envelope comes from the same row as the content of the letter.

A recipient variable is a substitution, not a lookup. It resolves to whatever value is in the referenced field of the current record—the record whose email is being generated. Stellar Cyber does not look up recipients in a user directory and does not decide which recipient a record belongs to. For each email to reach a meaningful recipient, the address must either be present in the record or be constructed by the template from a field in the record.

Where the Recipient Address Comes From

The following patterns show where the recipient address can come from:

• The record contains an email address – Records from identity-centric sources, such as email security events or cloud sign-in logs, often include an email address or user principal name. For example, if a failed sign-in record contains "email": "amy@example.com", the variable {{_source.email}} resolves to amy@example.com, and the email for that record is sent to that address.

• The template constructs an address from a username – If the record contains a username but not a full email address, and usernames in your organization map predictably to email addresses, you can construct the address in the template. For example, {{user}}@example.com resolves to amy@example.com for a record that contains "user": "amy". Stellar Cyber does not verify that the constructed address exists—the mapping between usernames and addresses is an assumption that you make when you write the template.

• The template constructs an address from a tenant name – In multi-tenant deployments, each record identifies the tenant that it belongs to. If your notification addresses follow a naming convention, you can construct a per-tenant address. For example, soc-{{_source.tenant_name}}@example.com resolves to soc-acme@example.com for records from the tenant acme and to soc-globex@example.com for records from the tenant globex. As a result, each tenant's administrators receive only the notifications for that tenant. This happens not because Stellar Cyber matches records to recipients, but because the template builds each address from the tenant name in the record, and your mail system defines those addresses as distribution lists.

• The address is static – A static address, such as soc-team@example.com, always receives the email regardless of record content. Use static addresses when every notification should go to the same recipients. Each record still produces its own email, which is useful when each record should become a separate, trackable message in a shared inbox or a ticketing system.

If your records contain neither an email address nor a field from which an address can be constructed—for example, records that contain only IP addresses and ports—dynamic recipients are not usable for that playbook. In that case, use static recipients.

You can combine dynamic and static recipients. For example, the entry {{_source.email}}, soc-team@example.com sends each email both to the recipient resolved from its record and to the SOC team. If a dynamic recipient fails to resolve for a particular record (for example, the email field is empty), Stellar Cyber skips that recipient for that record and logs the miss.

Features Available in Run-for-Each Mode

• No iteration needed: Each record gets its own email automatically.

• Template compatibility: Templates written in the run-for-all style render correctly, with each email showing only the data from its own record.

• Dynamic recipients: Recipient addresses can be resolved from record fields using template variables.

• Email throttle: A maximum of 100 emails are sent per playbook execution. If the query returns more than 100 records, only the first 100 generate emails.

• No attachments: File attachments (interflow JSON, CSV, calculation JSON) are not supported in this mode.

Comparison of the Two Modes

The following table summarizes the key differences between run-for-all mode and run-for-each mode to help you choose the right one for your use case:

Custom Jinja2 Filters

The following custom Jinja2 filters are available in both run-for-all mode and run-for-each mode. They provide convenient formatting for common data types found in security event records.

ts_format

This filter formats a millisecond-precision timestamp into a human-readable date and time string. You can optionally shift the time by a number of hours (to adjust for timezone) and specify a custom format string.

{{ timestamp | ts_format }}
  -> "2025-01-15 08:30:00 UTC"

{{ timestamp | ts_format(hour_shift=-5) }}
  -> "2025-01-15 03:30:00 UTC"

{{ timestamp | ts_format(hour_shift=0, format="%Y-%m-%d %H:%M:%S") }}
  -> "2025-01-15 08:30:00"

For a complete list of format codes, refer to strftime.org.

to_severity

This filter converts a numeric event score (0–100) into a severity label. This is useful for making email notifications immediately understandable without requiring the reader to interpret a numeric score.

Options:

{{ event_score | to_severity }}                      -> "major"
{{ event_score | to_severity(capitalize=true) }}     -> "Major"
{{ event_score | to_severity(uppercase=true) }}      -> "MAJOR"

Troubleshooting

• Email not sent for a record (run-for-each mode): If a variable in the email body fails to resolve for a particular record (because the referenced field is missing or empty in that record), Stellar Cyber skips sending an email for that record and logs the skip under AUTOMATION | Action History | Email Actions.

• Recipient resolution failures (run-for-each mode): If a dynamic recipient template resolves to an empty string or an invalid email format, Stellar Cyber skips that recipient and logs the reason. Check the AUTOMATION | Action History for details on resolution misses.

• Attachment too large: In run-for-all mode, if an Interflow attachment exceeds the size limit of the email server, Stellar Cyber sends the email without the attachment and logs the following message: Attachment too large (Email server returned 500, message: None), sent without Interflow attachment.

• Verifying template output: Use the Run Now option on the playbook and then check … | Last Status to see whether the email action executed successfully and review any error details.