What lies beneath Salesforce Omnichannel?

Queue-based routing — that is, how it all started

In other words: how does it happen that the assignments end up at agents?

Omnichannel in Salesforce initially worked only in the queue-based routing model. It means that the agents were assigned to queue without taking their skills into account. The appearance of the assignment in the queue meant that it would be displayed to agents automatically. The benefit of this solution was mainly  fast implementation, literally by a few clicks.

However, when a need to design advanced configuration and  to better match assignments to agents appeared, a problem arose. It turned out that Salesforce does not offer too many configuration options, and if we would like to do some magic, we would hit a wall quickly. But when the things at Salesforce get tough, the developers get going, and that is how the skill-based routing was created. The admin job ends here, but it starts for the developers.

Skill-based touring step by step and many more

Obviously, we start the configuration with defining the list of agent skills, for example foreign language skills. By defining and assigning agents, we determine the skill on a 1-to-10 scale. What is more important, we decide by ourselves when the case should go to Omnichannel because it happens in the Apex code, which the figure below shows:

Figure 1. Omni-Channel configuration — defining the lists of agent skills. Source: Trailhead.

A useful option is the possibility to extend settings by linking particular skills with the waiting time for the order completion. Let us assume that a specific case requires knowledge of English and French, but we do not want to prolong the customer service due to the lack of a proper agent. In that case, the configuration entails setting the time limit. For example, if an agent, who knows these both languages, is not available within three minutes, the French language is rejected, and the system starts looking for someone who knows just English. Probably the quality of service will go down a little, but it will be quicker. Quid pro quo ?

The next possibility is the attribute setup. It allows using skill-based routing without  Apex. How? The figure below shows it.

Figure 2. Omnichannel configuration — attribute setup. Source: Trailhead.

This tool comes handy not only in simple configurations in which there are few dependencies. But it is worth remembering that in this case, work goes to Omnichannel as in queue-based routing — the moment it is queued.

What else can you implement in Omnichannel?

• The continuation option. It applies to an already closed assignment. However, for a variety of reasons, a customer may come back with the case because there is still something wrong with it. Of course, this case might be directed to all the agents: as a result, it will be assigned to the currently available one. But it is much better to assign it to the agent who dealt with it before. We gain the service consistency and time: the agent knows the subject, so the customer does not have to explain everything from the start. And maybe when the agents will log in to Omnichannel, it would be worth reminding them where they have finished their job recently? There are quite a lot of possibilities. Definitely, it is worth checking the object agent work documentation.
• Ignoring capacity. Regardless of how many tasks an agent works on, there is a possibility to add him/her another one, though Omnichannel does not provide that option. You can find an explanation in the figure below.

Figure 3. Omni-Channel configuration – ignoring capacity. Source: Trailhead.

Omnichannel can surprise you

Be ready for what seems obvious but not always is, and for impossible turning out to be possible. Here are the specifics.

When does the agent work close? In a perfect world, probably it would close at the same moment the case is closed. The agent has finished his work on the case so that they can take care of another one. Nothing could be more wrong. Capacity is released only when the tab in the service console is closed. There are always two sides to the story — also in this case.

One situation is as follows: the agent has not finished their job yet, but they would like to handle it later, so they close the tab and release capacity. For Omnichannel, it means that another task could be assigned to this agent.

The other situation: the agent leaves the opened tab in the console though they have closed the case, but they have not released the capacity, and other cases will not be assigned to the agent. What happens next? There are three possible scenarios. The agent takes a break if the supervisor does not see the downtime. In the second case, the assignment will go to JIRA. The third possibility, unfortunately, does not seem as great as the first two ones: everything comes out, and soon you have a phone call from your supervisor saying, “We have not spent all that money on licenses to have a service that does not work.”

From the developers’ point of view, the fact that the agent work cannot be closed from the Apex code level adds fuel to the fire. Ultimately, when agents do not want to collaborate with us,  Lightning API comes to help us with its proven method. It is illustrated by the figure below.

Figure 4. Omnichannel configuration – the use of Lightning API. Source: Trailhead.

When does the owner of the record change? That is another issue that might bring irritation. Here is an example: a case starts to ring in Omnichannel. The configuration does not allow the agent to reject the call, only to accept it. However, the agent does not do that. And at this moment, you may be surprised for the first time — the agent is already the owner of the case, despite not accepting it. But there is another surprise for you: the agents cannot reject the incoming assignment, but they are allowed to change their status to offline. Then, the case will be passed on further. Who will be its owner — see the figure below.

Figure 5. Omnichannel configuration – settings of the record’s owner. Author’s compilation.

However, the biggest surprise was left for the very end. On the slide, we see that there are at least three changes of the record’s owner. Therefore, we can draw a theory that the record was updated three times. The question is: how many times triggers, workflows, and process builders were activated? The answer might take its toll on developers, because it was not done even once.

In the end, I have a question for you. Is a good Omnichannel configuration equal to skill-based routing and Apex? Maybe it is possible to work miracles without writing a single line of code?