This article only applies to older versions of SRR before v8.22. Check your version, and consider upgrading, before implementing unnecessary automation.

Sometimes you have multiple 'owners' looking after different aspects of the record. For instance an Account may have a primary owner (OwnerId) - perhaps an Account Manager, but also there may be a dedicated Support Agent, or Training Agent. These other 'owners' are often created as custom user lookup fields. We can use Flow or Process Builder to have SuperRoundRobin assign to those custom user lookup fields instead of OwnerId.

Concept: 
After SuperRoundRobin has set the OwnerId (in the same transaction) we will copy this user into the desired custom user lookup field, and then reset the OwnerId back to what it was before the transaction using the PRIORVALUE() formula function. We can use Flow or Process builder to achieve this - here we show a Process Builder example.

Example Use Case:
The example described in this article is one where an org has a custom user lookup field called Account Executive that they want assigned by SRR. The main Account Owner should remain unchanged by SRR. Any account record that is changed to Account Status == Subscriber Account should be assigned an Account Executive.

We need:

1. A MatchGroup with appropriate MatchRules (we won't cover the creation of this here)
2. A Process Builder process with two steps:
   1.  When the record reaches a state that requires the custom user lookup to be assigned, it should set the Use_Round_Robin__c field to TRUE
   2.  When the record has been processed by SuperRoundRobin and the Use_Round_Robin__c field is set to ASSIGNED, it should copy the OwnerId value to the custom user lookup field and then update the OwnerId value back to its prior value.

The overall Process Builder looks like this:

The first step (blue diamond) has criteria that triggers the copying of the assigned user to the custom user lookup field and then the OwnerId reversion. We're going to start by looking at this first step in the Process Builder:

The criteria in the blue diamond 'Record Just Assigned' looks like this:

We trigger that first set of actions only when the record has just been assigned by SRR, and we do a check to ensure that the custom user lookup field is null. Your business logic might be different to this. Also note that the checkbox at the bottom is ticked - ensuring that the actions are only executed when changes are made to the record that make the criteria evaluate to true.

The actions for this first step look like this:

Here we simply set the custom user lookup (in this case it is called 'Account Executive') to the value of the Account.OwnerId

Then the next action is the one that resets the OwnerId back to what it was before the transaction started, using the PRIORVALUE formula function.

The second blue diamond is the one that triggers SuperRoundRobin to assign the record in the first place. Note that we intentionally make this the second action group. When the criteria here are met (the point at which you want the record to be assigned to the custom user), the the Use_Round_Robin__c field is updated to TRUE.

The criteria here will depend on your business logic - it will contain criteria that determine at what point you want your custom user lookup to be assigned. In this example, we are triggering SRR when a Account Status picklist field is changed to 'Subscriber Account':

Again note that we have checked the box at the bottom ensuring we only trigger the actions when the record has been changed to meet this criteria. Then the subsequent action is to simply update the Use Round Robin field to TRUE (which will trigger SRR).

Transaction Walkthrough
Using this example, where we have an Account with an Account Executive user lookup field that we want to assign. We want to assign the Account when the picklist Account Status changes to the Subscribed Account status.

This is what happens in the transaction:

1. The Account Status picklist on an Account record is changed to Subscribed Account and the user saves the record
2. The update causes our Process Builder to be invoked. At this stage of the transaction, SuperRoundRobin has not been fired and the Use Round Robin field is not ASSIGNED, so the first action group is skipped.
3. The conditions for the second action group in our Process Builder have been met, because the Account Status picklist has just been changed to Subscribed Account. So the actions are executed: the Use Round Robin field is updated to TRUE.
4. Because the record has just been updated, all before triggers are re-run, including SuperRoundRobin. SuperRoundRobin now sees that the record has Use Round Robin set to TRUE, so it processes the record. We're going to assume that SRR has been configured with a MatchGroup that will match this record, and SRR assigns the record to one of the Assignees.
5. The transaction continues, and our Process Builder is invoked again - this time though the first action group is executed because the conditions are now met (Use Round Robin == ASSIGNED). The Account Executive user lookup is populated with the value of OwnerId (that SRR has just set) and then the OwnerId is reverted to its prior value.
6. The transaction ends, and the record has a new Account Executive assigned to it, and the OwnerId (primary owner) remains unchanged.