Categories: USER GUIDE NOTIFICATIONS ENTERPRISE

Execution Subscriptions

From a user’s perspective, it is often useful to be notified about certain events, like the execution (or failure) of particular plans. This is possible by leveraging the functionality of the Alerting Rules and Notifications.

Expert users can create the corresponding rules themselves, however this is not necessarily a straightforward task, and figuring out the exact definitions may be cumbersome. Therefore, Step provides a simple Wizard which allows to set up notifications in an easy way. Here is an example of how it looks in action, after an execution has finished:


As you can see, one can easily set up additional subscriptions directly on the execution page, as well as getting a quick overview of the existing ones.

At a glance

As mentioned before, subscriptions (or execution alerting rules) make combined use of the Alerting Rules and Notification Presets. In fact, a subscription simply corresponds to an alerting rule where the action is a notification, and the wizard already pre-populates the conditions used in the rule – such as defining exactly which plan is affected, and on which outcome of the execution the rule should fire.

To simplify the user experience, by default the wizard will filter the notification presets selectable by the user to include only those presets that have been tagged with the flag “Suggest for execution alerting rules” (see below), but in principle any preset can be used.

The generated rules can be freely modified after creation.

Setting up Notification Presets for Subscriptions

We recommend to define Notification presets for the most common use cases that you have, and to set the Suggest for execution alerting rules flag on such presets. Here is a (simple) example of such a notification preset for an E-Mail notification:


While you are free to set up the notification presets exactly how you please, the following best practices are recommended:

  • Pre-populate as much information as possible in the preset (e.g. Subject, Content etc.)
  • Lock all fields that are not needed to be modified by the user. If users should be allowed to edit the data, leave the corresponding field editable, but provide sensible defaults.
  • Leave only the fields that should be filled by the user unlocked in the preset.

In the example above, the preset predefines (and locks) everything except for the To: mail address. Therefore, when using this preset, users will only have to fill in their mail address.

Usage: Creating a new Subscription

Once notification presets are defined, users can start subscribing to executions. Here is what users will see when they click on the Add execution alerting rule action after an execution:


As you can see, the user will be able to define the conditions for the subscription, consisting of:

  • the execution parameters (in this case, the environment, set to the value “TEST”). The parameters presented depend on your configuration, and are pre-populated with the actual values used during the execution.
  • a trigger: this defines a condition evaluating the outcome of the execution. Thus, users can be notified on all executions, or only successful (or failed) ones.

In addition, the user has to select (and potentially fill in) a notification preset that is to be used:


By default, only the notification presets that have been flagged as “suggested” (see above) will be shown, but users may select any available notification preset if they so choose.

Finally, when a preset is selected, the user is given the opportunity to fill in any missing data. In the example below, that’s only the e-mail address – and is exactly the reason why we suggest to keep the presets as simple as possible (i.e., predefine and lock all fields not required to be user-settable).


Outcome: Alerting Rules

Once the subscription wizard is finished, an Alerting Rule is created from the user input.


The screenshot above shows the rules created for two subscriptions. These rules contain the notification action as defined by the user, as well as the conditions needed to identify the execution, and the conditions defined by the user. For instance, here is the definition of the rule triggered when executions have failed:


There is nothing really “special” about these rules other than the fact that they have been created semi-automatically by the subscriptions wizard, so they may be edited at will. For example, one could remove the condition to match on the “Environment” execution parameter (the last one in the screenshot above) so that the rule would apply to all executions regardless of the environment (but obviously, still matching the other conditions).

Subscriptions on Schedules

Subscriptions can also be defined on scheduled executions – technically, they will react to the ScheduledExecutionEndedEvent instead of ExecutionEndedEvent as “normal” subscriptions do (for more details, please refer to the corresponding Alerting Rules documentation).

To create a subscription for a schedule, choose the corresponding action from the schedules view:

The generated rules will very slightly differ from the ones for regular executions, but the procedure for creating them (i.e., the wizard) is the same.

See Also