Control the Message Flows for Specified Resources by Blocking Conditions

Here are some examples on how to control the message flow for a specific resource:

• Stop message delivery by specific resources

  If you need to block all notifications related to some resources (or bucket or any other resource tree item), you can use conditions based on a resource property to achieve it. For example, you can create a 'checkbox' property "Block notifications" and add it to the Resource Info screen. You must then configure blocking conditions for the message steps based on the value of this property ("block_notifications" is not null). After that all can set on or off the checkboxes for particular resources to control the delivery.

• Redirecting e-mail notifications for some resources only.

  If you need to change a normal flow for some selected resources then you may find it easy to achieve by using resource properties and message blocking conditions.

  For example, you need to create a flow where an email must be sent to resources, but for some reasons, it is also necessary to redirect these emails to another address for some resources. You may create an additional resource property (for example, 'alternative_email’), store the second address in this property for necessary resources, and leave it empty for others. You can specify the following message blocking conditions:

  • message step 'send_general_email': Add blocking condition 'alternative_email' is not null so that this message is not sent to normally used address if the alternative one was specified for this particular resource.

  • additional message step 'send_alternative_email' can be created with the blocking condition “alternative_email is null” so that the message is sent, only if the address was specified.

  Therefore, only one message is sent for either to the normally used address or to the alternative e-mail (if it is specified).

• Duplicating e-mail notifications to a dispatcher for some resources only

  Use the resource property and message blocking conditions to duplicate e-mail notifications to a dispatcher for some resources only. The flow is similar to the redirect example (above) with one difference that you do not need to block the step with normal delivery but only have the blocking condition for alternative step.

• Stop delivery for testing environments

  A delivery channel (internal or external) can be made inactive when a client copies a production instance to create a test instance and would not like any message to be sent to a real customer or a production external system. Message from the channel that are inactive are not sent to real customers. Alternatively, you may configure the credentials of delivery channels to point to the test instances of external systems (available only for external delivery channels).