About Notifications

Notifications provide a way to inform users when changes occur in the system. For example, you can create notifications that send an e-mail message to users when they are assigned an item or when an item is submitted.

Notifications are executed when certain events occur or conditions change in the system. Rules determine when notifications should be generated.

You can increase the importance of notifications by setting escalation parameters that repeat a notification, send an escalation notification if an action has not occurred within a specified time period, or delay a notification based on the value in a Date/Time fields. For details and examples, refer to About Escalations.

Notifications can also be used to automatically call Web service functions or run scripts. This allows for a simple way to integrate with external applications, enabling you to easily import or export data when changes occur in SBM.

Notifications also provide automation for adding item links to and removing items from folders. For example, you can automatically add item links to an SBM Knowledge Base folder when support personnel add information to a specific field.

Key Benefits

Push information to users as key data changes in the system.
Notify managers if employees fail to act on items in a specified timeframe.
Ensure items are not forgotten.

How Notifications Work

As users submit, update, and transition items in the system, the Notification Server processes notifications defined for workflows and auxiliary tables. Rules determine when notifications are generated.

Rules are evaluated during each Notification Server cycle, and when a rule becomes true, a notification is generated.

Common rule examples are:

"I become the owner of an item" - This rule sends a notification to a user who is assigned an item.
"Any item is closed" - This rule sends a notification to subscribers when items become inactive.
"An item has not been acted upon since last week" - This rule sends a notification when an item has not changed state this week.
"An item mentioned user" - This rule sends a notification to a user who has been mentioned in an item's text field or note.

The most common use of notifications is to generate e-mail messages. For each notification, you can specify which users always receive an e-mail and which users can choose to subscribe or unsubscribe to the notification. You can customize the e-mail templates that are sent for each notification by including certain field data, notes and attachments related to a particular item, and a link to the item.

Users can also view their notifications in SBM Work Center.

Inheritance Guidelines

Notifications are created for workflows. Each notification applies to all projects assigned to a workflow and its sub-workflows, also referred to as child workflows. If you change the rule selection for a notification at a child workflow level, that selection applies to all workflows assigned to the child's parent.

Rules created in a parent workflow are inherited in any sub-workflows, but rules contained in sub-workflows can be overridden.

For example, at a parent workflow, you can create this rule:

"Any Item Changes State AND Customer Reported Is Equal to Yes."

You can override this rule for a sub-workflow as follows:

"Any Item Changes State AND Customer Reported Is Equal To No."

Changes made to the rule in the sub-workflow do not impact the rule in the parent workflow.

Editing a rule at the sub-workflow level overrides the rule's inherited properties. Any modifications you make apply to the selected workflow only.

Provided Notifications

To ease the process of implementing new process apps, a default set of notifications and notification rules are provided for each parent workflow in your application. The notifications and supporting rules are added after the first deployment of a new process app or on subsequent deployments after new parent workflows have been added.

The names of each notification and rule are prepended with the first letter of up to three words from the workflow name. For example, a workflow named "Software Development Workflow" would result in a SDW prefix for the provided notifications and rules. (If prefixes already exist in your system, subsequent prefixes are numbered, such as SDW1.) You can remove or modify this prefix as needed. The singular item name for your application is included in the name to indicate the type of item to which the notification refers.

By default, members of all groups in your system are allowed to subscribe to the provided notifications. You can modify these settings on the Subscriptions page for each notification. For details, refer to Notification Subscriptions.

The following notifications are provided for each workflow in a process app:

Any [item] changes owner
Any [item] changes state
Any [item] changes to inactive
Any [item] I submitted changed state
Any [item] I submitted changed to inactive
Any [item] is submitted
Any [item] mentioned user
I become the owner of any [item]

Tip: You can modify or delete the provided notifications and rules if you do not want to use them.