Managing Notifications → 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 SBM AppScripts. 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.
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.
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 Serena Work Center.
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.
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.
Copyright © 2007–2015 Serena Software, Inc. All rights reserved.