Writing User Notification Messages for Business Rules

Business rules enable admin users to apply a wide range of automation to master data processes. Included in business rules' range of features is the ability to display messages to the user at specific moments, and under specific circumstances. Some messages may convey a bit of information relevant to an action that was just taken, or an acknowledgment that the desired outcome has been achieved, but most often, a configured message to the user will display when something has gone wrong.

Because so much flexibility is supported for creating business rules, a lot of latitude is granted to admin users configuring business rules, specifically as it relates to drafting text notifications. The information contained in this topic aims to provide admin users with a primer on recommended practices to consider when writing business rule notifications, so the end user may be provided with information that is useful, clear, and timely.

General Guidelines

The aim for notifications should be to provide the user with concise, informative messages that, depending on the kind of notification, inform the user a process has completed, prompt the user to take a specific next step, or confirm whether an action is successful or has failed. Automated system notifications that only provide jargon-rich technical information are not as strong as those that offer plain-language messages designed to help the user take the next step. Notifications can be displayed via popup messages (as in the 'Information' and 'Acknowledgment' message type screenshots below), or as text shown below the affected field in a Node Editor (as in the 'Warning' and 'Error' message type screenshots, also below), or as small pop-ups that display near the affected cell(s) in Node Lists.

There are four types of notifications that can be presented to users in business rules: Information, Acknowledgment, Warning, and Error. What follows is a description of each of these, with an emphasis on Warning and Error as these are the notification types that will most commonly be used with business rules.

Information

An information notification informs the user of an event that may be of interest to the user. These notifications are always system-initiated.

Message Template

Information messages inform the user of a positive event that is likely to be of interest to the user. Unlike error messages, information notifications are not associated with a problem, so the triggering event is the most relevant piece of information, whereas with an error, the problem itself is the most relevant piece of information.

What follows is the recommended template for an informational message:

{{Event}}. {{Further Information}}. refer to {{Reference to all information}}.

A good example of this kind of message might be, 'Creation of background process BGP_113506 initiated. (Create collection: “Marketing Collection” from search)'

In this example, the relevant event is described. Following this, the admin-named event that has initiated the background process, which is ‘Create collection’, the collection itself is named ‘Marketing Collection’, and the collection is being created from the results of a search.

When properly configured in a business rule using the Web UI Context bind, information messages will be coded blue.

Acknowledgment

An Acknowledgment message informs the user that their goal was fulfilled. These messages might best be described as the opposite of error messages. Acknowledgment messages are always generated by the successful completion of user-initiated tasks.

What follows is the recommended template for an acknowledgment message:

{{Object(s)}} {{action}}

A good example of this kind of message would be: 'Item was successfully approved.'

In this case, 'Item' is the object, and 'successfully approved' is the action.

When properly configured in a business rule using the Web UI Context bind, acknowledgment messages will be coded green.

Warning

A Warning message warns users of a condition that might cause a problem in the future. Conditions that generate warning messages can stem from either user- or system-initiated actions. The fundamental purpose of a warning message is to help the user lessen the risk of a potential negative consequence. A warning message might display, for example, when a user is at risk of deleting an asset, losing system access, or executing an action that will take significant time to correct.

What follows is the recommended template for a warning message:

{{Point of concern}}, because {{cause}}. {{Solution}}

A good example of this kind of message is in the Node Editor warning notification shown below.

In this instance, the stated point of concern is 'Normally phones do have Bluetooth.' The solution statement is, 'Make sure that this is correct, and if so, check the compatibility on related accessories.' This message is clear, written in plain language, and alerts the user to a potential problem, and provides steps they can take to avoid an error going forward.

When properly configured in a business rule, popup warning messages will be coded amber, and warning messages for Node Editor fields (using the Data Issues Report bind) will be preceded with an amber triangle, and turn the outline of the affected field amber.

Error

An Error message lets the user know two things: one, a problem has occurred and two, the user cannot proceed until the problem has been cleared. The issue being raised can stem from either a user- or system-initiated action. Effective error messages inform users not only what the problem is, but also provide a brief explanation of its cause, as well as information that can point users towards a fix. The error message should prompt users to either perform an action or change their behavior.

Some examples of events that can trigger error messages are the following: input problems, Create, Read, Update, and Delete issues (CRUD), violations of business rules, business-relevant system to system problems, server connection problems, database problems, and network problems.

What follows is the recommended template for an error message:

{{Problem}}, because {{cause}}. {{Solution}}

A good example of this kind of message is in the Node Editor error notification shown below.

In this instance, the stated problem is 'The relationship between the selected 'Resolution' and 'PPI' does not match.' The solution statement is, 'Make sure that the right PPI is selected in relation to Resolution.' This message is clear, written in plain language, and gives the user a clear course of action they can follow to clear the error and proceed.

When properly configured in a business rule, popup error messages will be coded red, and error messages for Node Editor fields (using the Data Issues Report bind) will be preceded with a red circle, and turn the outline of the affected field red.