Rules are the foundation of notifications because they determine when
notifications are generated. There are two types of rules:
- When Rules - Determine when a notification will be generated.
Before a notification can be generated, the set of conditions that make up the
notification's rule must become true.
- Termination Rules - Determine when escalations should no
longer be sent.
All rules consist of one or more conditions. Conditions are typically
based on changes to field values, such as:
- "State Changes to Assigned"
- "Submit Date Changes"
- "Owner Changes From Current User"
- "Severity Changes to Critical"
You can also group conditions together to form more complex rules:
- "Any Item is Submitted AND Item Type Is Equal to Hardware Request AND
Purchase Amount Is Greater Than 1,000"
- "State Changes to Closed AND (Manager Changes From Joe Manager OR
Manager Changes From Samatha Manager)"
Common conditions for Termination rules are:
- "State Changes to Assigned"
- "Resolution Changes to Complete"
- "Attachment Is Added"
At the beginning of each Notification Server cycle, which is defined in
all changes to items that have occurred since the last cycle are evaluated
against notification rules. Notifications are generated for each rule that
became "true" in that cycle.
Consider the following information when you create conditions:
Sub-Relational field is selected as the object,
notifications are fired when the field's value is changed in an item using the
workflow for which the rule is defined. For example, if your Issues workflow
contains a relational field to the
Incidents table and a
Sub-Relational field to the
Company field within that table, you can create a
notification that fires when the selection in the issue changes the value of
Incident Company field.
The (Current User) value is available for
Multi-Group field types. (Current User) enables you to
create a rule that sends a notification to the current user selected for a
field if that user has privileges to view an item and is subscribed to the
notification. For example, the condition "Manager Is Equal To (Current
User)" causes a notification to be sent to a particular user when that
user is selected in the
Manager field. For
Multi-User fields, each selected user/group receives a
Multi-Group fields, members of each selected group receive a
The following examples illustrate how you can use the (Current
User) value in standard notifications. In these cases, Joe, Laura, and Samir
have privileges to view, own, and submit items into a project. Newton only has
privileges to submit items into the same project. All users are subscribed to
receive e-mail notifications using the following rules:
- State changes AND Owner is (Current User): Laura owns an item
and its state changes. Only Laura receives an e-mail notification.
- State changes AND Submitter is not (Current User): Joe submits
an item. Laura and Samir receive an e-mail notification when the item's state
changes, but Joe does not.
- State changes AND Submitter is (Current User): Newton submits
an item. Joe, Laura, and Samir do not receive a notification when the item
changes state. Newton also does not receive a notification because he does not
have privileges to view the item he submitted.
You can also use the (Current User) value to send escalation
notifications to the correct users. For example, you can send an escalation
notification to the owner of an item that has not been acted on in three days.
In this case, the rule for the escalation notification should include the
condition "Owner Is Equal To (Current User)." This rule ensures that the
escalation is sent only to the owner of an item that has not been acted on in
You can use
Date/Time keywords, such as
startof_last week, as values for
Date/Time fields. These keyword values are recalculated each
time a condition is evaluated.
- Disabled selections for
Multi-Group fields are available and can be used to build
rules. This enables you to build rules for a workflow when projects using that
workflow have disabled field selections.
- You can create notifications that execute when work items are added
to or removed from a backlog in
SBM Work Center.
You can also generate notifications when the priority changes for an item in a
backlog. Rule conditions must be created for each backlog.
Copyright © 2007–2018 Serena Software, Inc., a Micro Focus company. All rights reserved.