Open in ChatGPTOpen in Claude

Preset message rendering flow

When a notification is sent, Notification Center determines which message template to use by evaluating the preset and its configuration layers. The system merges the applicable templates to produce the final notification message. This process is the same for all destination types and entity types.

How Notification Center builds a message

Notification Center follows a defined rendering order to construct the final message:

1. The notification request is received from an entity such as an alert or case.
2. Routing determines the destination (connector + preset).
3. The system identifies whether the selected preset is a system preset or a custom preset.
4. The preset’s general layer provides the default message template.
5. If an override layer exists for the entity subtype, it replaces the sections defined in the general layer.
6. Notification Center renders the merged template using dynamic values from the entity and system context.
7. The completed message is sent to the destination.

Dynamic data sources

During rendering, Notification Center populates templates using data from the notification payload.

Data source	Description
Entity data	Information specific to the alert or case, such as name, severity, and trigger time.
System context	Metadata available through the _context variable, including account details, region, and system identifiers.
Destination configuration	Optional values from the connector, such as service names or webhook URLs.

See Dynamic templating for supported variables and syntax.

Example rendering scenarios

Preset type	Configuration	Rendered result
System preset	General template only	Uses the built-in message format for the destination type.
Custom preset without overrides	General template only	Applies user-defined message structure for all entity types.
Custom preset with overrides	General + subtype-specific templates	Replaces general sections for specific subtypes such as metric threshold alerts.

Troubleshoot preset fallback to a default template

If a notification arrives formatted with a system default instead of the custom preset you selected, the custom template most likely failed to render, and Notification Center fell back to a default. Rendering fails when the template references data that is missing or malformed at send time, for example:

• A group-by key or entity field that the specific alert does not include.
• Invalid JSON in the destination payload after the template is interpolated.
• A syntax error in the template, such as an unclosed tag or a bad filter expression.

To reduce fallbacks:

• Guard optional values with a fallback, for example {{ alert.some_field or "n/a" }}, so a missing field does not break rendering.
• Confirm that every field and group-by key you reference is present for the alert subtype the preset targets. See Alerts schema.
• Test the preset against a representative alert before relying on it in production.

Note

Notification Center does not currently surface the specific rendering error that caused a fallback. Until it does, narrow the cause by removing template sections until rendering succeeds, then reintroduce them one at a time.

Next steps

Create system-based or fully custom presets in Preset creation flow.