This post provides a technical view on the Salesforce Omni-Channel feature-set added in the Summer ’15 (beta) and Winter ’16 (GA) releases.
In functional terms Omni-Channel enables use-cases where work items are proactively pushed to specific agents based on defined rules in relation to priority, capacity and availability. The model extends the traditional Queue approach through routing configurations that define how work items (Cases, Leads etc.) are sized, prioritised and the required routing logic (least active agent or most available). Agent capacity and availability is configurable per work item type, or service channel in Omni-Channel terminology. Queue membership controls the applicability of a given agent for a given work item. As such queues are defined to represent the work item assignment structure (skills, regions, teams, products, knowledge etc.) – as would typically be the case outside of Omni-Channel. Once a work item is assigned to an Omni-Channel enabled queue automated routing to an available queue member takes place. Where automated assignment fails, pending work-items are held on the queue and routing attempts made each time agent availability changes. Agent work load is represented by ownership of the records represented by work items.
From an agent perspective Omni-Channel interactions are handled via an Omni-Channel Widget in the Salesforce Console. The widget supports accept/decline behaviour and manual presence status setting. “Away for Lunch”, “Available for Cases” being illustrative examples. The work item display in the widget is controlled via the primary compact layout for the object the work item represents.
Omni-Channel integrates seamlessly with Live Agent, enabling a standardised approach to routing and agent capacity across channels. Seamless in this context relates to the end-result, there are configuration changes required to transition from standalone Live Agent to an Omni-Channel integrated state. The objects supported by Omni-Channel are limited to those objects supported by Queues i.e. Cases, Chats, SOS video calls, Social posts, Orders, Leads, Custom objects.
Hopefully the preceding paragraphs sufficiently set the scene for the technical aspects covered below.
Data Model
As the model above shows Omni-Channel is underpinned by a significant number of standard objects. The majority of the objects support queryable, createable and updateable access levels which provides extensibility where standard features require augmentation. The one notable exception to this is the UserPresenceStatus object which records the current presence status for agents, this object is read-only. This limitation will prevent custom solutions (or more likely 3rd party AppExchange solutions) from programmatically manipulating the agent presence; this could be significant where solutions wish to share state with Omni-Channel at the application level.
Extension Points
Beyond the ability to extend Omni-Channel through direct data-level interactions (Apex or API) there are additional extension points to consider.
1. Custom Fields. The UserServicePresence (aka User Presence) and AgentWork objects support the addition of custom fields.
2. Apex Triggers / Validation Rules. The UserServicePresence object supports both Apex Triggers and Validation Rules. In the former case custom logic could be introduced to take action when specific presences are set. In the latter case conditional logic could be applied to prevent presence changes, although the console widget behaves erratically in response to validation rule failures.
3. Custom Console Footer Components. For each Service Channel (Lead, Case etc.) a footer component can be specified to open when a work item of the service channel type is opened. The customisation potential here is considerable.
4. Omni-Channel SOAP API Objects. Full set of objects exposed via the standard SOAP API.
5. Omni-Channel Objects for the Salesforce Console Integration Toolkit. Extensions to the standard console JavaScript API to support manipulation of Omni-Channel objects. Straightforward enough. A key point here to note is that unlike Apex or API transactions, the JavaScript API does support update of agent presence.
[code language=”javascript”]
sforce.console.presence.setServicePresenceStatus(statusId, function(result) { ..}
[/code]
6. Pre-assignment. Omni-Channel routing is applied when a work item is assigned to a Queue via record ownership. Automated routing logic then assigns the work item to a user based on priority, availability and capacity rules. Granular control of the user-assignment is not provided. Use cases that require one agent to be preferred over another based on logic such as last customer contact are not supported. Finer grained routing of this type should be addressed in the pre-assignment step, i.e. before the queue assignment. Agent presence and capacity are accessible via code and could therefore be queried as part of a custom user-level routing process. The AgentWork object is also createable suggesting that a record representing a pre-assignment could be added to ensure visibility of the work item to Omni-Channel.
References
Omni-Channel for Administrators
Omni-Channel Developer’s Guide
Update – 10th March
With Omni-Channel current agent workload is determined by work item records open in the Salesforce console not record ownership. Closing the tab for a Lead record has the effect of setting the related AgentWork record status to closed.