Notification templates

Alert routing already resolves most-specific-first: a rule delivers to its integration’s channels, else its owning team’s, else the org default. Since v0.11.38, the message format follows the same ladder. You write Liquid templates for email and Slack once at the org level, teams override only the fields they care about, and individual rules can make exceptions — without any team having to restate the parts it doesn’t want to change.

Webhook payloads and PagerDuty events are deliberately not templatable: they are structured payloads that downstream consumers parse, so their shape stays fixed.

The template set

A message template set exists at two scopes:

• Org default — Settings → System → Notification templates.
• Per-team override — each group’s drawer in Settings → Groups gains the same card.

A set has four fields, all Liquid, all optional:

Field	Format
Email subject	Plain text
Email body	HTML
Slack title	mrkdwn
Slack body	mrkdwn

An empty field means inherit — leaving a field blank is how you say “use whatever the next rung up says”, not “send nothing”.

How a field resolves

Resolution is per field, not per set. For each of the four fields independently, Sluicio walks down this ladder and uses the first non-empty value:

1. The rule’s inline override (see Per-rule overrides).
2. The owning team’s template set.
3. The org template set.
4. The built-in defaults.

Because each field resolves on its own, a team that sets only the Slack body still gets the org’s email subject and body — it doesn’t have to copy them into its own set to keep them.

Upgrading from older versions

Your existing cell-wide Alert email template (the old card on the formerly single-page Settings → System) is carried into the org default set — now Settings → System → Notification templates — automatically; there’s nothing to re-enter.

The ladder covers everything alerting sends over email and Slack — stuck-message (flow-completion) notifications included, so an org template restyles those too. For stuck messages the top two rungs simply never apply: flow-completion rules aren’t team-owned and their editor has no inline template fields, so resolution starts at the org set.

What Slack messages look like

A templated Slack notification is posted as:

*title*
body

The title line is optional — if the title field resolves to empty, only the body is posted.

If nothing is configured anywhere on the ladder, the built-in Slack line — severity icon + [FIRING/RESOLVED] + summary — is exactly what it was before v0.11.38. Existing installs see no change until someone writes a template.

The state icon is a variable, not a prefix

Once a template resolves, it owns the whole line — Sluicio does not force-prepend the firing/resolved icon. It’s available as {{ alert.state_emoji }}, so put it wherever your format wants it (or leave it out).

Per-rule overrides

The rule editor’s Notification content section now has a collapsed Customize Slack message panel next to the existing email one. A rule’s inline template is the top rung of the ladder and beats every set.

Make the ladder the norm, inline the exception

Inline overrides are for the one rule that genuinely needs a different message — a customer-facing status alert, say. If you find yourself pasting the same inline template into several rules, move it into the team’s or org’s set instead, so there’s one place to change it later.

Template variables

The template editors show a variable palette served by the backend — it’s reflected from the actual alert context, so it always matches what your version renders. The namespaces:

• alert.* — state, summary, severity, alert.state_emoji, …
• rule.* — the alert rule’s name and configuration
• check.* — metric-check details
• service.* — the affected service, including service.metadata.<key> for your own metadata fields
• integration.* — the affected integration
• org.* — organization info
• sent_at — when the notification was sent

The palette marks per-variable availability: not every variable exists in every context — check.*, for example, is only available on metric-check rules. Variables are a stable contract: new ones are added over releases, but existing ones are never renamed or removed, so a template you write today keeps rendering.

Worked example

An org-wide Slack body that gives every team the same compact one-liner (Slack title left empty):

{{ alert.state_emoji }} *{{ rule.name }}* — {{ alert.summary }}

The payments team wants their service and runbook in the line, so in their group’s drawer they set only the Slack body:

{{ alert.state_emoji }} *{{ rule.name }}* on `{{ service.name }}` — {{ alert.summary }}
Runbook: {{ service.metadata.runbook_url }}

Alerts owned by the payments team now post the two-line Slack message — but their emails still look like the org’s, because the team’s email subject and body are empty and resolve up the ladder to the org set. Every other team’s alerts are untouched.

Safety

• Malformed Liquid is rejected at save — you see the parse error and the template isn’t stored.
• A saved template that later fails to render (say, mid-render on missing data) falls through to the next rung of the ladder. A bad template never blocks an alert — the notification always goes out with some rendering.

Permissions

• The org default set requires an org admin.
• A team’s override requires an org editor — or, on Enterprise with advanced RBAC, an editor of that team.

Rule inline overrides follow the normal permissions for editing the rule.