In MatchGroups, you can set a Priority, and enable Overflow. How do these options work, how do they differ from each other, and how do they cooperate?
When configuring your MatchGroups, you can set a Priority, and enable ‘Overflow to the Next MatchGroup’. This article will explain a bit more in depth what these options do in relation to each other.
In short
- Priority used without Overflow will only determine which MatchGroup will be evaluated first when a record comes in. If a record doesn't match (fully) with its MatchRule logic, it will proceed to the MatchGroup with the next priority. Once a MatchGroup matches, the record is assigned either to an Assignee of the MatchGroup, or to its Queue User.
- Overflow acts as a backup in case all Assignees of a matching MatchGroup are unavailable. Instead of assigning the record to the Queue User, it will proceed to the MatchGroup with the next priority where it also matches the MatchRule logic.
Priority
The Priority of MatchGroups determines in which order the MatchGroups are evaluated. Priority 1 MatchGroups are evaluated first, then Priority 2, etc. However, this only applies if you have MatchGroups that are not mutually exclusive with regard to their MatchRules.
When records are analyzed by Plauti Assign, to see which MatchGroup should handle them and assign an Assignee, a match is determined based on the MatchRules of a MatchGroup. The MatchRules will check the values of certain fields on the record to see if they match their settings. For example, a MatchRule can be “Country equals Canada”, or “Lead Type equals B2B”.
In some situations, like in Multi Stage Sales Processes, you first want to check if a record matches a strict set of rules, e.g. both “Country equals Canada” AND “Lead Type equals B2B”. You set up a MatchGroup ‘A’ with both these rules, and certain Assignees. If the record matches both rules, it will be assigned to one of the Assignees of the MatchGroup.
If the record does not match both rules, but only one, you want it processed by a different MatchGroup with different Assignees. So you set up a second MatchGroup ‘B’, e.g. with only “Country equals Canada” as a MatchRule.
However, when a new record comes in with country: Canada, there are now two MatchGroups that match the record. If you do not set a different Priority, the second MatchGroup B might fetch it first, while in this example you want the strict MatchGroup A to try and match first.
This is where Priority comes in. You set the Priority of the strict MatchGroup A to ‘1’, and of the other MatchGroup B to ‘2’. When a record with country Canada comes in, Plauti Assign will now first see if it matches the full MatchRule logic of MatchGroup A.
- If it does, it will assign one of the Assignees of MatchGroup A.
- If it does not, it will try if it matches with MatchGroup B.
In this example the MatchRules are partly overlapping (both have MatchRule “Country equals Canada”). But the same can happen with fully different MatchRules: e.g. MatchGroup C looks for City equals Arnhem, MatchGroup D looks for Type equals Open, and a record with both City = Arnhem and Type = Open comes in. Without a Priority sequence set, the record can be picked up by both MatchGroups, whoever happens to catch it first.
MatchGroups without MatchRules
This is also the reason you want to give so-called “greedy" MatchGroups, that do not have any MatchRules and are therefore able to match with all records, a Priority at the end of the sequence (e.g. 9 or 10 if you have a large number of non-exclusive MatchGroups). With such a low Priority, it will only match with records that did not match any of the other MatchGroups with more MatchRules.
MatchGroups with the same Priority
There is some priority flow built in, in case a record matches two MatchGroups with the same Priority set: the MatchGroup that has matched with records most often in the past will match. This is determined by the MatchGroup's LeadCount number (it is called LeadCount but counts other Objects' records as well). But you'll probably want to set an actual Priority instead.
Most of the time you can get by with setting up sufficient MatchRules. If a record will never match two MatchGroups, it doesn't matter that they have the same Priority set.
Not used for unavailability
One thing to remember when it comes to Priority, is that it purely looks at MatchRules. If a record does not match all MatchRules of the MatchGroup with Priority 1, Plauti Assign will see if it then matches the MatchRules of the MatchGroup with Priority 2, and so on and so forth.
If a record does match all MatchRules of a MatchGroup, but all Assignees are unavailable, it will NOT proceed to the MatchGroup with the next Priority in line. Instead, the record is assigned to the Queue User of the matching MatchGroup, and will wait until an Assignee of that group becomes available again.
Overflow to the next MatchGroup
The Assignee availability is the difference between only using Priority, and using Overflow as well. Overflow is intended to set up a backup system in case all Assignees of the intended MatchGroup are unavailable. Assignees can be unavailable for example because they are marked as ‘out of office’, are at maximum capacity, or set to ‘inactive’. Unavailable Assignees cannot be assigned records.
When Overflow is enabled for a MatchGroup, and a record comes in that matches the MatchRules but the Assignees are all unavailable, the record will NOT be assigned to the Queue User to wait until an Assignee is available again. This waiting for availability might take too long for your workflows. Instead, with Overflow enabled, Plauti Assign checks if there is another MatchGroup that has MatchRules that the record matches with, but with a lower Priority, e.g. 2 instead of 1.
- If there is another matching MatchGroup, and an Assignee is available there, the record will be assigned to them.
- If there is another matching MatchGroup, but no Assignee is available there either, and Overflow is enabled on that MatchGroup as well, the record will move to see if there is a third, fourth, etc MatchGroup that matches.
- As long as there are MatchGroups with MatchRules that match the record, and Overflow is enabled on these groups, the record will continue moving from one MatchGroup to the next; either until it is assigned, or until there are no more matching MatchGroups left.
- When there are no more matching overflow MatchGroups left, the record is NOT assigned to the Queue User of the last matching MatchGroup, but is instead assigned Use Round Robin status: NOMATCH. This is the same as when Overflow is not used and a record doesn't match with any MatchGroup. Set up a notification of some sort for records with that status, or for example have them assigned to a Salesforce Queue, so that they can be picked up in another way.
If you do not want records to end like this, make sure the last matching MatchGroup has Overflow disabled: - If the record is matched to another matching MatchGroup, but no Assignee is available there either, and Overflow is NOT enabled on that MatchGroup, then that is considered the final MatchGroup in the line. Even if there are other overflow MatchGroups with matching MatchRules left.
The record is assigned to the Queue User of that non-overflowing MatchGroup and will wait until an Assignee is available there.
So do make sure Overflow is enabled on all MatchGroups that should overflow.
Overflow MatchGroups with the same Priority
In combination with Overflow, Priority can be used to create a full sequence of overflow MatchGroups in a set order (1-2-3-4-etc), but it is also possible to give different overflow MatchGroups all the same Priority (e.g. all ‘2’). A record will then move from one random Priority 2 group to the next (the MatchRules still have to match though, and Overflow should be enabled on each MatchGroup). Plauti Assign will keep track of which MatchGroups the record already tried but found unavailable, so it will meet all backup MatchGroups only once until either an available Assignee is found, or there are no more matching overflow MatchGroups left.
You can also set up multiple main MatchGroups, with Priority 1 and extensive (and mutually exclusive) MatchRules, and an overflow MatchGroup with Priority 2 and less, more general MatchRules, so that the latter can be a backup for several main MatchGroups.