• EnglishEspañol日本語한국어Português
  • Log inStart now

Notification migration

Workflows are replacing the classic notification system for . This is good news because workflows is an improved, flexible notification system. Workflows help your team learn about potential errors within the greater context of your stack so you can take immediate and efficient action.

What does this migration mean for your team? In our previous notification model, your team would create an alert condition with different thresholds and parameters. If that condition was associated with a specific policy, was breached, and you wanted your team to know about it right away, you would add notification settings. Our notification settings would tell New Relic what data to send where.

Now, we've added workflows. Going forward, instead of configuring classic notification channels and associating them to policies, notification destinations are created and associated to workflows. Workflows can process data from a range of policies and can use attributes like tags or priority to organize notifications.

What to expect

The migration from the classic notification system to workflows creates a destination for each classic notification channel and connects them to workflows created for each policy. Only policies with channel associations will be migrated.

  1. New Relic will automatically migrate accounts from January 23rd to May 15th, 2023.
  2. New Relic can migrate accounts earlier, just reach out to your account team.
  3. Your team can avoid the automated migration by removing channels from policies.
  4. The notification channel APIs and Terraform resources will continue to work until December 31st, 2023.

Known changes

Notifications will not substantially change during the migration. They will continue to have the same attribute names and most of the same values. The migration to workflows will change the following:

  • All _url attribute values will change and lead to issue based pages, not incident based pages. condition_id will now always have the same value as condition_family_id.
  • issue_id has been added. Consumers should switch all integrations to using the issue_id instead of the incident_id, as the incident_id will be removed at some point.
  • radar_entity.entityGuid and targets[0].id will be an entity guid when one is available for all types except for Webhooks.
  • targets[0].labels will contain all tags from the issue, not just the tags for the entity defined by the target.
  • targets[0].link and violation_callback_url will lead to the issue page.
  • open_violations_count.critical will contain the count of all open incidents across all priorities. Priority specific counts are unavailable.
  • open_violations_count.warning will always be 0. Priority specific counts are unavailable.
  • closed_violations_count.critical will contain the count of all closed incidents across all priorities. Priority specific counts are unavailable.
  • closed_violations_count.warning will always be 0. Priority specific counts are unavailable.
  • owner will have a value of NA if the issue has not been acknowledged.
  • timestamp_utc_string will switch from the YYYY-MM-DD, HH:MM UTC to the ISO 8601 compliant YYYY-MM-DDThh:mm:ss.sssZ format.
  • violation_chart_url will have a value of Not Available if chart generation failed or did not return in a timely manner.
  • The email sender will change to noreply@notifications.newrelic.com.


The incident_id on PagerDuty, Webhook, VictorOps, OpsGenie and xMatters notifications refers to the classic incident id. The classic incident id is deprecated. Consumers should start using the issue_id instead.

Incident_id changes:

  • A unique incident_id will still be generated for every issue. The value will be different than those used in the deprecated Incident API.
  • To limit the impact to VictorOps, OpsGenie and xMatters notifications, the incident_id will be populated by the issue id. That will cause the New Relic steps to acknowledge or close an incident in xMatters to no longer work.

Configuring custom payloads

When moving from notification channels to workflows your team may want to make some tweaks to your custom payloads. Workflows still function in the same way as notifications in that, when a condition is breached then a notification is sent to a webhook and when it is sent, it goes with its custom payload. The migration from notification channels to workflows requires changing some of the terminology in this payload.

The following table provides a translation between what the webhook payload names used in our classic notification system and their new, corresponding names in the issue payload. Handlebars is the simple templating language used for writing message templates.

For many keys, the issue payload may contain a list of values. To provide a one-to-one mapping, only the first value is used in the replacement.

Alerts (classic) name

Alerts (classic) variable

Workflow message template replacement






{{json accumulations.tag.account.[0]}}




The number of closed incidents across all priorities.




There is no replacement for warning counts. All closed incident counts will be represented as critical to avoid double counting incidents.



{{escape accumulations.conditionDescription.[0]}}

The custom incident description, if one is defined.






{{escape accumulations.evaluationName.[0]}}

Only valid for conditions.



{{escape accumulations.evaluationMetricValueFunction.[0]}}

Only valid for conditions.



{{escape accumulations.conditionName.[0]}}



{{#if issueClosedAt}}"closed"{{else if issueAcknowledgedAt}}"acknowledged"{{else}}"open"{{/if}}

The state of an issue has more states, but doesn't have one for acknowledged.



{{escape issueTitle}}



{{#if issueDurationMs}}{{issueDurationMs}}{{else}}0{{/if}}

issueDurationMs is only available when an issue closes




There is no matching attribute on the issue level.



{{json issueAckUrl}}



{{issueId}} OR {{labels.nrIncidentId.[0]}}

Prefer issueId since labels.nrIncidentId will be removed at some point.



{{json issuePageUrl}}






{{#if locationStatusesObject}}"location_statuses": {{locationStatusesObject}},{{/if}}
{{#if accumulations.metadata_entity_type}}"entity.type": {{json accumulations.metadata_entity_type.[0]}},{{/if}}
{{#if accumulations.metadata_entity_name}}"entity.name": {{json accumulations.metadata_entity_name.[0]}}{{/if}}




Open incident counts of all incident regardless of priority.




Open incident counts of all incidents regardless of priority.



{{escape owner}}



{{escape accumulations.policyName.[0]}}



{{json policyUrl}}



{{json accumulations.runbookUrl.[0]}}



{{#eq 'HIGH' priority}}WARNING{{else}}{{priority}}{{/eq}}

An issue has priority, which can have different values than severity.



"id": "{{labels.targetId.[0]}}",
"name": "{{#if accumulations.targetName}}{{accumulations.targetName.[0]}}{{else if entitiesData.entities}}{{entitiesData.entities.[0].name}}{{else}}N/A{{/if}}",
"link": "{{issuePageUrl}}",
"product": "{{accumulations.conditionProduct.[0]}}",
"type": "{{#if entitiesData.types.[0]}}{{entitiesData.types.[0]}}{{else}}N/A{{/if}}",
"labels": { {{#each accumulations.rawTag}}"{{escape @key}}": {{#if this.[0]}}{{json this.[0]}}{{else}}"empty"{{/if}}{{#unless @last}},{{/unless}}{{/each}} }










There is no matching attribute on the issue level.



{{json issuePageUrl}}



{{json violationChartUrl}}

Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.