SRR automatically attempts assignment if all your assignees are unavailable. This article goes into detail about how SRR does this.
Assignees can be unavailable for a number of reasons: they might be Out of Office, Out of Hours, Inactive, At Capacity or Unlicensed. If all the Assignees in a MatchGroup are unavailable then SRR has nobody to assign the record to. In this situation the record is temporarily assigned to the Queue User specified on the MatchGroup:
This doesn't have anything to do with Salesforce Queues. The Queue User above is simply a user that the record is 'parked' with until it gets assigned to one of the designated Assignees. As such it is a good idea if the person you set as the Queue User is not normally dealing with these records on a day to day basis. It can be a system administrator account, or team manager etc.
SRR Automatically Attempts Assignment
In the Setup and Status tab there is a button at the bottom labeled 'Create Jobs'. This should be pressed once during initial setup of SuperRoundRobin to initialise the scheduled jobs that do the automatic assignments. The only purpose of these jobs is to query Salesforce for QUEUED records, and run them through SRR rules to attempt assignment. This job runs every 10 minutes once set up.
Changing The Batch Size (available from v8.60)
By default these jobs will query the oldest 50 QUEUED records for each object you use SRR for. You may want to increase or decrease this number; for example if you receive many hundreds of leads over the weekend you may want to increase this to 200, or it might be that you use High Velocity Sales and you are hitting the 'You can only add 20 targets to a Sales Cadence at once' error - so you'll want to set the batch size to 20 or less.
To do this navigate to:
- Setup > Custom Metadata Types
- Against SRR Queue Processor Batch Size select Manage Records
- Click Edit next to Batch Size
- Change the Batch Size value to a number between 0 and 9999
Setting the value to 0 will effectively stop the job from querying and processing any QUEUED records. You may wish to do this if you wanted to temporarily halt the processing of QUEUED records.
Be aware that increasing this to a high number (thousands) will consume more resources and depending on the level of automation against your records upon update, this may cause the job to fail. Remember this job runs every 10 minutes so if you can reduce this number and allow the QUEUED records to be processed over a period of time this will have less impact on resource usage.
