Alert! Alert! Read all about it!

We've been hinting at this for a while now, but it's actually happening in our upcoming Ninja release: we're renaming "events" to "alerts"!

As a matter of fact, customers enrolled in our Early Access Program will see these changes in their non-production instances even sooner - possibly even by the time you read this.

For a full breakdown of why we're making this change, see the Automation and terminology updates article we posted a few months ago, or check out the definitions and differences explained in this handy IT Alerting and Incident Management blog post.

Rather than go over the ground already covered in previous posts, I'd like to set some expectations about what this change will look like within the product, and how it might affect your interactions and integrations.

Same features, new names

The most obvious changes you'll likely notice right away are the updates to various page names and menu entries. For example:

• The dashboard widget names and labels will reflect the new naming conventions, such as Recent Alerts, Alert Activity, Alerts by Source, etc. 

• The "Recent Events" and "All Events" reports will now be known as "Recent Alerts" and "All Alerts", respectively. (Though not for long, as an upcoming release will combine these pages into a single "Alerts" report so you can access all of your current and historical alert information in a single place. Follow our Product Overviews and Release Highlights section for more information.)

• Speaking of reports, you'll also see changes in exported .csv files, specifically the column headers. If you have any kind of automation or scripting in place that relies on column headers in your exports reports (such as pivot tables), check to see that you're referring to the new column names.
• Event Flood Control becomes Alert Flood Control because this feature limits the number of alerts that xMatters creates in response to incoming signals.

• Other areas, such as priority thresholds (e.g., "High priority alerts only") on user devices, some group settings (e.g., "Alert-based" rotations), and table headings (e.g., the "Recent Alerts" column on performance reports), will also retain exactly the same functionality, just with new labels.

You'll also see these changes reflected in the appropriate locations within the xMatters mobile apps.

Same features, same names

Almost as important as the things we're changing are the things we aren't changing! Developers, integrators, and workflow creators will be happy to hear that we are not changing any of the properties, values, or labels associated with events in our REST API, custom step scripts, triggers, or anything else code-adjacent. This ensures that your existing integrations and incoming signals will continue to function without interruption.

The special case

I did want to draw attention to one feature in particular: the Create Event & Create Alert steps in Flow Designer.

Flow Designer contains both a Create Event AND a Create Alert step because, while both steps create an alert in xMatters, the Create Event step creates an alert based on an existing form while the Create Alert step creates an alert within a flow, using only the information from previous steps in that flow. To help highlight this distinction, the Create Event step will become the "Create Alert Using a Form" step to ensure that the label includes terminology that references what is essentially the legacy method of creating an alert.

Also, the Create Alert step was deliberately named that way because it's an integral part of allowing users to go from signal to notification entirely within Flow Designer, without needing to define a separate form and its associated properties. As more and more functionality is introduced to Flow Designer, the need to define forms and properties separately should naturally diminish and the Create Alert step will become the de facto best way to create alerts and send notifications in xMatters.