5

So, on a completely unrelated issue, I was checking the PendingServiceRouting field reference in the omni-channel developer guide, when I came across a field called PreferredUserId and I was like shut-the-front-door! This is exactly what omni-channel has been missing - a way to route to a specific user.

Further digging reveals this was slipped into Summer '19 (API v46.0) with little fanfare. In fact, it's mentioned only once in the release notes.

There's practically nothing out there that I can find relating to this new feature. So, I figured the enquiring minds on StackExchange could help me test it / validate my findings, for the benefit of others.

Everybody loves sample code. This shows the properties I'm setting on the PendingServiceRouting record (various helper methods excluded for brevity).

private static void createPSR(Case cse, List<String> skills, Id preferredUserId, Integer weight)
{
    // create a new skills-based PendingServiceRouting
    PendingServiceRouting psr = new PendingServiceRouting(
        CapacityWeight = weight,
        IsReadyForRouting = false,
        RoutingModel  = 'MostAvailable',
        RoutingPriority = getRoutingPriority(cse),
        RoutingType = 'SkillsBased',
        ServiceChannelId = getChannelId('Omni_Cases'),
        WorkItemId = cse.Id,
        PreferredUserId = preferredUserId,
        PushTimeout = 0,
    );
    insert psr;

    // do stuff here to create SkillRequirements based on the skill names passed in
    // ...

    // update PendingServiceRouting as IsReadyForRouting
    psr.IsReadyForRouting = true;
    update psr; 
}

What I've discovered, so far:

If you set PreferredUserId and the preferred user is logged in

  1. If you don't have SkillRequirements, omni-channel assigns the case to the preferred user. This is expected, so great.

  2. However, if you do have SkillRequirements, omni-channel steamrolls over them and assigns the case to the preferred user anyway, regardless of whether they also meet the skill requirements. Awesome, that's not quite right.

If you set PreferredUserId and the preferred user IS NOT logged in

  1. If you don't have SkillRequirements, omni-channel assigns the case to any logged in agent based upon the RoutingModel set in the PendingServiceRouting.

  2. If you do have SkillRequirements, omni-channel assigns the case to any logged in agent based upon the SkillRequirements and RoutingModel set in the PendingServiceRouting.

In summary

The preferred user needs to be logged into omni-channel. If they're logged in, it'll route to them regardless of skills. If they're not logged in, it ignores the property completely and behaves as you would expect had it not been set.

Issues

If it's going to completely ignore the skills when the preferred user is online, it's pretty much treating it like 'give it to this person - no matter what'. So the user experience is selecting an agent and the WorkItem ends up with them.

However, the user experience when selecting an offline agent is that it routes as normal if you use skills (but doesn't end up with the preferred user), or disastrous if you don't use skills (any random agent is getting that one).

Why wouldn't it throw the request to the skills backlog if the agent was offline? The user experience would be the same (when they came online again).

Anyway, my fix for this is to only let users select agents that are online.

@AuraEnabled
public static List<User> APEXgetUsers()
{
    // select only logged in users
    // PendingServiceRouting.PreferredUserId is exactly that. Preferred.
    // if the user isn't logged in, it'll go to whoever meets that skills
    // if it's routed without skills, just a preferred user, and that user
    // isn't logged in, it'll go to anyone
    List<User> users = [SELECT Id, FirstName, LastName 
                        FROM User 
                        WHERE IsActive = true 
                        AND Id IN(
                            SELECT UserId FROM UserServicePresence 
                            WHERE IsCurrentState = true
                        )
                        ORDER BY LastName ASC];
    return users;
}

So (I think) the rules are:

  1. You can only route directly to an agent that is online.
  2. You cannot route directly to an agent and also specify skills.

Happy to hear anyone else's feedback.

  • You cannot route directly to an agent and also specify skills, this is done by the system not you – Remario Dec 10 '19 at 19:03
  • I found your StackExchange post while looking for a way to target a specific user with Omni Channel routing. This helped me get some setups done in a sandbox. What I am finding is that this is not 100% directed to the preferred user, even if they are logged into Omni Channel. I have users who have been logged into Omni Channel in our Sandbox with 0% capacity, and this routes to a random logged in user. I cannot reproduce this issue on command, as a subsequent push routes correctly. But, it is definitely an odd occurrence that I am not sure how to prevent. – smckitrick Jul 29 '20 at 18:54
  • Hello @smckitrick. Were you able to debug anything else? I am currently on the same situation as I have 2 users logged-in and with capacity and the AgentWork is not being correctly assigned even though the Preferred User Id it's specified. Tried with and without creating SkillRequirements but the behavior is the same. – user1067017 Oct 8 '20 at 16:20
  • @user1067017 I was not able to debug anything else. I ultimately had to change to a direct ownerId update. It doesn't add to capacity (so other cases are allowed to route to the user), but at least the cases are routing correctly. Most of our cases are routing to a main group. However, through our integrations, cases created via api by a user action in another system needed to route to that specific user in Salesforce. This is what I was trying to route specifically via PendingServiceRouting so that Omni Supervisor would show the case as being on the user's current workload. – smckitrick Oct 9 '20 at 18:00
  • Thanks for the update @smckitrick. Even though I used OwnerId as well the behavior is not the expected one as Cases are not being routed directly to who they should. Guess we will wait until Winter21 release to test the newly introduced IsPreferredUserRequired field – user1067017 Oct 12 '20 at 7:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.