## Lifecycle model overview Our new case lifecycle model enables teams to forecast, staff, and report on the units of work that comprise a support case. Key benefits include: - Forecasts that account for all “touches” / units of work done by your agents - More accurate staffing for cases that transfer or escalate - Visibility into case breakdown (reopens, transfers, etc) - Optimize staffing to meet SLA requirements for each touch ## Units of work for omni vs. non-omni cases In Salesforce, cases can be routed in two ways: Omni-channel routing and manually. It’s common for customers to use both types of routing methods. In this section, we’ll walk through how units of work are defined for both types of cases. Note that in the instance that a unit of work is not created in Salesforce, we consider that excluded and it will not be added to the ticket volume in Assembled. ### Omni cases and units of work Definition: - Cases routed automatically via [omni-channel routing](https://help.salesforce.com/s/articleView?language=en_US&id=sf.omnichannel_psr_lifecycle.htm&type=5). When routed through Omni-Channel, an [AgentWork](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_agentwork.htm) object is created. Omni units of work: - Begin when an `AgentWork` object is created. - `AgentWorks` are mapped one-to-one to units of work in Assembled. AgentWork basics: An AgentWork object is created when a case, live chat transcript, or other work item is routed to an agent via Omni-Channel. This can happen under several circumstances: - The work item enters a queue with Omni-Channel routing enabled and is directly assigned to an agent. - The work item is transferred or reassigned to another agent. - The work item status changes from a completed to a non-completed state (e.g., a case is reopened or re-engaged). ### Non-omni cases and units of work Definition: - Cases routed manually without Omni-Channel. Non-Omni units of work: - Created using an inference model since no `AgentWork` objects are created. - Begin when the case history shows: - **Transfer**: Case is transferred to a new Assembled mapped queue AND the `Owner` or `Status` of a case changes - **Reassign**: Case is reassigned to a new agent. (i.e the case’s `Owner` changes) - **Reopen**: Case is reopened (ie. `Status` goes from solved or closed to open) - **Re-engage**: Case is re-engaged (ie. `Status` goes from paused to open) Example of how omni & non-omni periods combine to create units of work in Assembled ## Queues and exclusions in Assembled For both omni and non-omni cases, the queue, channel, and status of a case are determined by its final unit of work. ### Omni configuration Out of the box, for omni-channel routing cases, we support skill-based or queue-based queue & exclusion configurations. #### Queue-based omni-channel routing - Create queues in Assembled based on the `Queue ID` field, matching the `OriginalQueueID` on `AgentWork`. #### Skill-based omni-channel routing - Create queues in Assembled based on the `Skill ID` field, matching any skills tagged on `AgentWork`. _Note: We have the option to use custom non-omni fields as well for queue configurations. This requires backend configuration, so please [contact us for help](mailto:support@assembled.com)._ ### Non-omni configuration Several options exist for defining queue and exclusion rules for non-omni cases: #### Owner ID (inferred) - Use the `Owner ID` field on the case object. - Use the case history to infer the owner at any given time, determining the queue for each unit of work. #### Skill ID (inferred) - Use `Skill IDs` from previous omni-routing segments to determine skills on manually routed units of work. #### Custom non-omni field (inferred) - Use a custom field on the case object. - Use the case history to infer the custom field at any given time, determining the queue for each unit of work. ## Channels in Assembled Several options are available for defining unit of work channels, independent of routing type: ### Custom non-omni fields (default) - Use the history of a custom field on the case object to infer the channel. - i.e. there’s a `channel` field that tracks changes to the channel ### Queue-channel mappings - For queues with specific channels, determine the channel of a unit of work based on its queue. - i.e. units of work in `queue A` = chat channel, `queue B` = email channel ### Default channel _The simplest channel mapping strategy._ - Map all units of work to a single channel per object type - i.e. `Case` = email channel, `LiveChatTranscript` = chat channel ### Case `Origin` mapping _Recommended for cases that don’t generally switch from asynchronous to synchronous interactions (or vice versa) during their lifecycle._ - Map `Origin` values on the case object to a channel, ensuring consistency across all units of work for a given case. - i.e. Units of work from a case with `Web origin` = email channel. Units of work from a case with `API origin` = chat channel. ## Appendix Related Case Lifecycle articles: - [Case Lifecycle Staffing Timeline](https://support.assembled.com/hc/en-us/articles/27913439886733-Case-Lifecycle-Staffing-Timeline) - [Case Lifecycle Real-Time Dashboard](https://support.assembled.com/hc/en-us/articles/27913526460685-Case-Lifecycle-Real-Time-Dashboard-Salesforce-Service-Cloud) - [Case Lifecycle Metrics](https://support.assembled.com/hc/en-us/articles/27927588435085-Case-Lifecycle-metrics)