About Rules and Conditions

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 the SBM Configurator, 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.

For details, refer to:

Conditions Guidelines

Consider the following information when you create conditions:

When a 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 the Incident Company field.
The (Current User) value is available for User, Multi-User, and 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 notification. For Multi-Group fields, members of each selected group receive a notification.
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 three days.
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 Single Selection, Multi-Selection, Multi-User, and 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.