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.
- New Relic will automatically migrate accounts from January 23rd to May 15th, 2023.
- New Relic can migrate accounts earlier, just reach out to your account team.
- Your team can avoid the automated migration by removing channels from policies.
- 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 ascondition_family_id
. issue_id
has been added. Consumers should switch all integrations to using theissue_id
instead of theincident_id
, as theincident_id
will be removed at some point.radar_entity.entityGuid
andtargets[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
andviolation_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 be0
. 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 be0
. 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 theYYYY-MM-DD, HH:MM UTC
to the ISO 8601 compliantYYYY-MM-DDThh:mm:ss.sssZ
format.violation_chart_url
will have a value ofNot Available
if chart generation failed or did not return in a timely manner.- The email sender will change to
noreply@notifications.newrelic.com
.
incident_id
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 |
---|---|---|
|
|
|
|
|
|
|
|
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. |
|
|
The custom incident description, if one is defined. |
|
|
|
| N/A |
Only valid for conditions. |
| N/A |
Only valid for conditions. |
|
|
|
|
|
The state of an issue has more states, but doesn't have one for acknowledged. |
|
|
|
|
|
|
|
|
There is no matching attribute on the issue level. |
|
|
|
|
|
Prefer |
|
|
|
|
|
|
|
|
|
|
|
Open incident counts of all incident regardless of priority. |
|
|
Open incident counts of all incidents regardless of priority. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
An issue has priority, which can have different values than severity. |
|
|
|
|
|
|
|
|
|
|
|
There is no matching attribute on the issue level. |
|
|
|
|
|
|