How does the “Allow Duplicates” setting for a Group affect recipient notifications and Scenario fill counts?

The Group Details page has a setting, “Allow Duplicates”, that determines whether the Group can have the same recipient listed more than once. How does this setting affect the number of notifications delivered to a recipient within nested Groups, and how does it affect the fill count of a Scenario?

There are three basic rules to consider when determining how the “Allow duplicates” setting affects the recipients within a Group:

  • The “Allow duplicates” setting for a Group applies to all nested Group recipients within that Group.
  • Notifications are determined to be duplicates at the Event level, not at the Group level.
  • Notifications are only considered duplicates if a duplicate live notification exists. Therefore, any delayed events set for delivery are not factored into the determination.

The following examples use three Groups (Group1, Group2, Group3) and one User (User1) to help illustrate these rules and the situations in which they apply:

  • Group1 consists of a single recipient, User1.
  • Group2 consists of two recipients, Group1 and User1. Duplicates are NOT allowed.
  • Group3 consists of two recipients, Group2 and Group1. Duplicates ARE allowed. 

The recipient tree for Group3 would resemble the following:

-- Group3 (allow duplicates)  
 |-- Group2 (do not allow duplicates)  
 | |-- Group1 (do not allow duplicates)  
 | | `-- User1  
 | `-- User1  
 `-- Group1  
 `-- User1  

Notification Delivery

A Scenario is created with the following recipients:

  • Group2
  • Group3
  • User1

Example 1:

With no delays specified, the notifications are delivered as follows:

-- Group2  
 |-- Group1  
 | `-- User1 (not notified)  
 `-- User1 (not notified)  
-- Group3  
 |-- Group2  
 | |-- Group1  
 | | `-- User1 (notified)  
 | `-- User1 (notified)  
 `-- Group1  
 `-- User1 (notified)  
-- User1 (notified)

Example 2:

With delays set as indicated, the notifications delivered are as follows:

-- Group2 (1 minute delay)  
 |-- Group1  
 | `-- User1 (not notified)  
 `-- User1 (not notified)  
-- Group3 (2 minute delay)  
 |-- Group2  
 | |-- Group1  
 | | `-- User1 (notified)  
 | `-- User1 (notified)  
 `-- Group1  
 `-- User1 (notified)  
-- User1 (notified)

Example 3:

With the same delays in place, User1 is removed from the list of recipients, and the notifications delivered are as follows:

-- Group2 (1 minute delay)  
 |-- Group1  
 | `-- User1 (notified)  
 `-- User1 (not notified)  
-- Group3 (2 minute delay)  
 |-- Group2  
 | |-- Group1  
 | | `-- User1 (notified)  
 | `-- User1 (notified)  
 `-- Group1  
 `-- User1 (notified)

Scenario Fill Counts

The examples in this section use the following Groups:

  • Group4 contains one recipient, User2. Duplicates are NOT allowed.
  • Group5 contains one recipient, User2. Duplicates ARE allowed.

Example 1:

User2 and Group4 are Scenario recipients

The Scenario notification only goes to User2 directly, not via User2’s membership in Group4. Thus, any response from User2 counts toward the Scenario’s additional fill count and not towards Group4’s fill count.

Example 2:

User2 and Group5 are Scenario recipients

User2 would receive two notifications: one directly, and one via their membership in Group5. If User2 responded to both notifications, one response would count against any additional fill count for the Scenario, and the other response would count against the fill count for Group5.

Further information

Click here for another article about "Allow Duplicates" and nested Groups.

xMatters Reference

JDN-1133 Originally created by Don Clark

Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.
Powered by Zendesk