Omni Channel practice questions

Broadcast Message to Agent

Why it fails: Broadcast Message sends a one-way internal alert to the agent's console; the supervisor cannot see or contribute to the chat transcript, so no discreet assistance reaches the customer conversation. It is tempting for quiet coaching, but it suits general announcements rather than live chat intervention.

Open and Take Over Chat

Why it fails: Taking over transfers the chat to the supervisor and notifies the customer that a different participant has joined, breaking the discreet requirement. It is tempting because it gives full control of the conversation, but it is designed for escalation when the supervisor should visibly own the chat.

Force Status Change to Offline

Why it fails: Forcing the agent offline changes their Omni-Channel routing status and stops new work being assigned; it does nothing to assist with the active chat. It is tempting as a supervisory control, but it is intended for managing capacity, not discreet in-conversation support.

Least Active

Why it fails: Least Active routes to agents with the fewest open work items, not the longest idle time. It is tempting because the name suggests inactivity, and it would be correct for balancing workload by volume rather than by waiting time.

Round Robin

Why it fails: Round Robin distributes work evenly in sequence, ignoring how long each agent has waited. It is tempting because it is the default even-distribution model, and it would be correct where fairness of assignment volume matters rather than idle duration.

Skill-Based Direct

Why it fails: Skill-Based Direct routes by matching agent skills to work item requirements, not by idle time. It is tempting because it correctly handles skill-matched routing, which would be the right choice when work items demand specific agent competencies rather than longest-idle distribution.

Agents are set to the wrong Presence Status.

Why it fails: Presence Status governs whether an agent is routable at all, so a wrong status would block every work item, not only those needing flow-assigned skills. The flow's skill assignment itself is the suspect. Presence Status is the correct focus when agents receive nothing regardless of skill matching.

The service channel capacity is set to Tab-Based instead of Status-Based.

Why it fails: Tab-Based versus Status-Based capacity changes how many work items an agent may hold simultaneously, not whether skill-matched work routes at all; agents with spare capacity still receive items. Status-Based capacity is chosen when the administrator wants agents limited by presence status rather than a fixed tab count.

Omni-Channel Supervisor lacks read access to the Flow object.

Why it fails: Omni-Channel Supervisor access controls what supervisors can observe in the supervisor console; it has no bearing on routing decisions or queue dispatch. The failure lies in the flow's skill assignment logic. Supervisor read access matters when supervisors must monitor or intervene in agent work.

Routing Configuration Overflow Settings

Why it fails: Overflow settings route work to alternative queues when capacity thresholds are breached; they do not change an agent's presence status after a decline. The decline-to-offline behaviour requires Omni-Channel's agent status configuration on the presence setting itself. Overflow is correct when queues exceed wait-time or capacity limits.

Omni-Channel Supervisor Alert Rules

Why it fails: Supervisor Alert Rules notify supervisors when thresholds such as wait time or agent inactivity are breached; they take no action on agent presence. Automatically setting an agent offline or away after declining a work item is governed by the presence status configuration tied to the decline action, not alerting.

Service Channel Push Timeout

Why it fails: Push Timeout governs how long a work item rings before being routed elsewhere; it does not change the agent's status after a decline. It suits limiting ring duration. Automatically setting away or offline on decline requires the Omni-Channel agent status decline behaviour setting.

Customer Community License

Why it fails: Customer Community licenses serve external portal users and cannot access the internal Service Console or Omni-Channel presence. It is tempting because community users can raise cases, but that is external case submission, not internal agent routing.

Salesforce Platform License

Why it fails: Salesforce Platform licenses lack the Service Cloud user features Omni-Channel routing requires; agents need Service Cloud User permission via a full Salesforce licence. It is tempting because Platform licences support custom apps, which would suit internal apps without Service Cloud routing needs.

Salesforce Integration License

Why it fails: Salesforce Integration licenses are for system-to-system API access without a user interface, so no Omni-Channel presence or console login is possible. It is tempting because integrations can create and update work items, which would be correct for middleware pushing cases rather than agents receiving them.

Set the Push Timeout on the Presence Status to 3 minutes.

Why it fails: Push Timeout on Presence Status governs how long a routed work item waits before the agent's status changes, not queue-level rerouting after three minutes. It is tempting because it involves a timer, but the requirement needs Omni-Channel flow or queue routing configuration to redirect to tier-1.

Configure a secondary Routing Configuration with a lower priority weight.

Why it fails: Routing Configurations assign work by priority and capacity, not by elapsed time, so a lower-weight secondary configuration cannot trigger a 3-minute fallback. It is tempting because multiple Routing Configurations genuinely do distribute Omni-Channel work across queues, but that is for load balancing, not time-based escalation.

Enable Overflow Routing on the primary Service Channel.

Why it fails: Overflow Routing activates when a queue's agents are at full capacity, not when a required skill is absent, so it cannot fire after 3 minutes of no skilled match. It is tempting because Overflow Routing does move work to a backup queue, which is correct for capacity-driven spillover rather than skill-based timeouts.

Queue-Based Capacity Model

Why it fails: Queue-Based Capacity assigns work by queue and ignores per-channel concurrency rules, so it cannot block chat while a phone call is active. It is tempting because queue-based limits suit teams wanting simple per-queue caps, which would be correct if channels did not need differing concurrency behaviour.

Unified Omni Capacity Model

Why it fails: Unified Omni Capacity applies one shared capacity number across all channels, so a phone call consuming capacity still permits chat if the total is not reached. It is tempting because unified capacity suits agents handling any mix of channels interchangeably, which would be correct if simultaneous phone and chat were acceptable.

Tab-Based Capacity Model

Why it fails: Tab-Based Capacity limits the number of concurrent work items per agent regardless of channel, so it cannot prevent chat arriving during a phone call. It is tempting because tab limits suit controlling total open tabs, which would be correct if channel-specific blocking were unnecessary.

Use Queue Overflow settings.

Why it fails: Queue overflow routes work to a fallback queue after a wait period; it does not drop secondary skills from the routing requirement. Overflow suits redirecting unaccepted cases, whereas broadening skill criteria requires Omni-Channel's skills-based routing with a secondary-skill drop rule.

Set up a Workflow Rule on the AgentWork object.

Why it fails: Workflow Rules on AgentWork fire on record save events such as status changes, not on elapsed-time triggers, so they cannot broaden skills after a five-minute wait. They are tempting because AgentWork drives Omni-Channel routing, but time-based skill escalation requires Omni-Channel Flow or routing configuration instead.

Adjust the Push Timeout on the Presence Status.

Why it fails: Push Timeout controls how long a work item is offered to an agent before being re-routed, not which skills the routing engine requires. It is tempting because it is time-based, but it never alters skill matching; dropping secondary skills after five minutes needs an Omni-Channel Flow with a time-based escalation path.

Standard Email-to-Case Apex Handlers

Why it fails: External Routing requires the Omni-Channel REST API or the AgentWork/ServiceChannel Apex objects to push work items; Email-to-Case Apex handlers only convert inbound email into cases. Email handlers suit email channel ingestion, not external telephony work routing.

Custom Platform Events with standard triggers only

Why it fails: External systems push work into Omni-Channel through the REST API or by creating AgentWork records; Platform Events with standard triggers cannot themselves create routable work items. Platform Events suit asynchronous notifications, not the routing handshake External Routing demands.

Salesforce Visualforce Routing Controllers

Why it fails: Visualforce routing controllers render UI inside Salesforce; they cannot receive inbound work items from an external telephony platform. External Routing requires the REST-based Omni-Channel API (or the corresponding Apex/API integration) to push work into routing, which this option does not provide.

Presence Status Definition Page

Why it fails: The Presence Status Definition page configures status names, channels, and options, not notification behaviour. It is tempting because presence statuses drive Omni-Channel availability, but single-click accept settings live in Omni-Channel Supervisor or the Service Channel notification configuration, not in status definitions.

Service Channel Object Mappings

Why it fails: Service Channel Object Mappings link Salesforce objects to service channels for routing; they do not control notification or accept behaviour. They are tempting because service channels underpin Omni-Channel routing, but the single-click accept setting is a notification preference configured elsewhere, not an object mapping.

Console Navigation Rules in App Manager

Why it fails: Console Navigation Rules in App Manager govern how records open in console tabs, not Omni-Channel notification settings. They are tempting because console apps host the Omni-Channel widget, but accept behaviour is configured in Omni-Channel settings, not navigation rules.

Work items are immediately deleted from the database.

Why it fails: Omni-Channel preserves active work items during a connectivity loss, holding them for the agent to reclaim; records are never deleted from the database. It is tempting because disconnection does eventually free capacity, but that happens through status change and reassignment, not deletion of the underlying records.

Agents are immediately logged out and work items are reassigned instantly with no delay.

Why it fails: A dropped session does not instantly log the agent out or reassign work; Omni-Channel applies a configurable timeout before changing status and routing the items onward. It is tempting because reassignment does ultimately occur, but only after that delay, not immediately as the option claims.

Work items are automatically marked as closed and resolved.

Why it fails: Losing connectivity does not close or resolve work items; Omni-Channel preserves the agent's status and routed work so it can be resumed on reconnection. It is tempting to assume cleanup happens automatically, but automatic closure applies to abandoned sessions only after configured timeouts, not immediately on disconnect.

Manage Omni-Channel Setup permission

Why it fails: Manage Omni-Channel Setup is an administrative permission, not required for frontline agents.

API Enabled permission

Why it fails: API access is not required for standard console agent usage.

Modify All Data permission

Why it fails: Modify All Data is overly broad and unnecessary for standard agents.

Maximum Queue Capacity limit

Why it fails: Maximum Queue Capacity limits how many work items an agent handles simultaneously; it is configured on the service channel or routing configuration, not on a Presence Status. Presence Statuses define channel availability and status options. This setting would be correct when capping agent workload per channel.

Associated Service Channels

Why it fails: Associated Service Channels specify which channels an agent can handle while in a status, but they do not define the status itself; the required settings are the status name and its channel-agnostic capacity. This option is tempting because channel association genuinely matters when routing work, and it would be the right choice if the question asked how to restrict a status to specific channels.

Default Skill Requirement list

Why it fails: A Presence Status defines capacity and channel availability, not skill routing; skill requirements are assigned to queues, routing configurations and Omni-Channel flows instead. It is tempting because skill-based routing genuinely needs a default skill set, and a Default Skill Requirement list would be the right choice when configuring which skills an agent must hold to receive work.

Transfer ownership to the supervisor

Why it fails: Declined work returns to the queue, not direct supervisor ownership.

Automatically close the work item record

Why it fails: Omni-Channel never automatically closes records upon agent decline.

Escalate the work item priority weight instantly

Why it fails: Priority escalation requires routing configuration rules or flows, not decline settings.

Capacity is calculated solely based on open browser tabs

Why it fails: Status-Based capacity counts work items per status, using configured capacity weights per channel and status rather than browser tabs. It is tempting because tab counts loosely reflect workload, but the model derives capacity from statuses and their assigned weights, not from the agent's browser session.

Requires external CTI middleware to calculate weights

Why it fails: Status-Based capacity is configured natively through capacity weights per status and channel; no external CTI middleware is involved. It is tempting because CTI integrations do handle telephony routing, but capacity calculation here is internal to Omni-Channel's status-based model.

Service Channel object type icon

Why it fails: The channel type icon is purely a visual identifier on the work item; it does not set any priority value or ordering rule. It is tempting because channel type does distinguish cases from chats, but prioritisation comes from the routing model's priority field and queue ordering, not the icon.

Agent Profile name

Why it fails: An Agent Profile name is only a label for a set of agent attributes; it carries no priority value and cannot order work items. It is tempting because profiles group agents by skill, which matters for matching, but the stem asks about prioritising critical cases ahead of chats, not agent selection.

Queue membership list size

Why it fails: Queue membership count is not a routing configuration setting and does not influence work item ordering. It is tempting because larger queues suggest more capacity, but prioritisation is driven by the routing model's priority field and the queue's ordering, not by how many agents belong.

Permanently delete agent user profiles from Salesforce

Why it fails: Deleting agent user profiles is a setup task performed in Setup by administrators, not a supervisor console action. The console surfaces agent status, work, and capacity for monitoring and intervention. Profile deletion would be correct when deactivating or removing a user entirely, which requires administrative permissions.

Modify custom fields on the parent Account record

Why it fails: Editing Account custom fields is standard record editing, unrelated to the supervisor console's real-time agent and work monitoring. The console lets supervisors change agent status and reassign work. Account field edits would be correct when a user with the relevant profile and field-level security updates customer data directly.

Service Channel activation toggles

Why it fails: Service channel toggles enable object tracking, not individual login behaviors.

Global Action menu layout assignments

Why it fails: Global actions do not control agent presence states.

Queue membership expiration dates

Why it fails: Queues do not have expiration dates affecting Omni-Channel login.

Create a Skills-Based Routing rule that assigns VIP skills to all high-priority cases.

Why it fails: Skills-Based Routing matches work items to agents possessing required skills; it does not reorder queue position or bypass earlier cases. It is tempting because skills correctly target VIP-trained agents, which would be the right choice if the requirement were agent competency rather than queue priority.

Configure a secondary Queue with a higher Routing Configuration priority and a Process Builder to move cases.

Why it fails: Omni-Channel priority is set per routing configuration and evaluated when a work item is routed; a secondary queue plus Process Builder cannot reorder already-queued work to jump ahead of earlier cases. It is tempting because queue-based routing with automation is the classic pattern for standard case assignment, not real-time queue prioritisation.

Adjust the Capacity Model to reserve agent capacity specifically for VIP customers.

Why it fails: Capacity models control how many work items an agent can handle concurrently, not the order in which queued items are selected, so reserving VIP capacity never lets a case bypass earlier arrivals. It is tempting because capacity planning is genuinely used to ring-fence agent time for specific work types.

Queue-based Capacity Model

Why it fails: Queue-based capacity counts records per queue and ignores agent ownership, so it cannot measure each agent's number of open cases across product families. It suits routing where queues, not agents, define workload limits; the stem requires per-agent case counts.

Tab-based Capacity Model

Why it fails: Tab-based capacity counts open console tabs, so a case consuming multiple tabs would be weighted more heavily than one tab. The stem explicitly requires counting open cases regardless of tab consumption, which this model cannot deliver.

Agent-based Capacity Model

Why it fails: Agent-based capacity limits the total number of records assigned to an agent, but it does not support the product-family routing logic described. It suits simple per-agent workload caps where skill or product segmentation is unnecessary.