Hard Difficulty Questions

ServiceChannel

Why it fails: ServiceChannel defines the channel itself, not the work item instance being routed. It is tempting because routing configuration references a Service Channel, but the flow interview requires the specific work item record, which is passed as the routing context; ServiceChannel supplies channel metadata only, so no work item ID is available.

AgentWork

Why it fails: AgentWork represents an agent's assignment to a work item and is created after routing, not passed in to initiate it. It is tempting because it links agents and work, but at flow entry no AgentWork exists yet, so it cannot supply the work item ID the interview needs.

User Presence ID

Why it fails: User Presence ID identifies an agent's presence record, not a routable work item. It is tempting because presence drives Omni-Channel routing eligibility, but the flow interview needs the work item record's ID to route; a presence identifier supplies no work item context.

Configure Case Business Hours to exclude times when the status is 'Waiting on Customer'.

Why it fails: Incorrect. Business hours define operating hours, not case status-based pauses.

Create a Process Builder that pauses the Case Milestone record when status changes.

Why it fails: Milestone pausing is native behaviour driven by the milestone's own criteria on the Case Status picklist; Process Builder cannot pause a CaseMilestone record, as its timer is controlled by milestone configuration, not record edits. It tempts because Process Builder automates field updates and record creation, which suits unrelated Case automation.

Enable Milestone Recurrence to reset the timer whenever the status changes.

Why it fails: Recurrence restarts a milestone when its criteria are re-met after completion, so it resets rather than pauses the running timer, losing elapsed time. It tempts because recurrence handles repeating milestones such as reopening a case, where a fresh timer genuinely should begin.

The previous milestone instance is permanently deleted from the database.

Why it fails: Incorrect. Historical milestone records are retained for audit and reporting purposes.

The milestone fails with a system error because recurrence is not supported for active processes.

Why it fails: Incorrect. Recurrence is a fully supported native feature.

The existing milestone timer is reset to zero and continues running.

Why it fails: Incorrect. Recurrence creates a new instance rather than resetting the exact same record if configured for multiple completions.

At 5:00 PM on the following day

Why it fails: That would account for 12 business hours.

At 1:00 PM on the following day

Why it fails: That would be 24 elapsed calendar hours.

At 9:00 AM on the following day

Why it fails: That would account for 8 hours or a different calculation; 1 PM to 5 PM is 4 full business hours.

Write an Apex trigger that modifies the Case Age field whenever a customer sends an email.

Why it fails: Modifying standard system-calculated fields like Case Age directly via Apex is either restricted or bad practice; Entitlement processes should be used.

Configure standard Case Escalation Rules with custom pause criteria fields.

Why it fails: Standard escalation rules do not support pause/resume criteria based on customer interaction.

Use Process Builder to pause the escalation rule timer using scheduled actions.

Why it fails: Process Builder scheduled actions cannot easily inspect and pause native escalation timers dynamically upon customer reply.

Case Team members were not assigned read permissions on the escalation queue.

Why it fails: Queue permissions do not directly prevent escalation rule execution.

The case was created via Email-to-Case, which bypasses escalation rules entirely.

Why it fails: Email-to-Case cases are fully eligible for escalation rules.

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.

Write an assignment rule with formula criteria evaluating User.CurrentCapacity.

Why it fails: Assignment rules execute upon record creation/update, not continuous real-time agent capacity shifts.

Create a scheduled Flow that checks agent capacity every minute and reassigns cases.

Why it fails: A scheduled Flow polling every minute cannot react to capacity-change events, so assignment lags and races with Unified Routing's real-time capacity checks. Flows suit bulk record operations, such as nightly reassignment of stale cases. Unified Routing assigns work items the moment an agent's capacity drops below the threshold and their skills match.

Utilize Einstein Next Best Action to prompt agents to pull cases from queues.

Why it fails: This relies on manual pull behavior rather than automated push routing.

Utilize standard Case Escalation Rules with criteria based on Last Modified Date and Region

Why it fails: Case escalation rules do not integrate cleanly with Omni-Channel agent status and capacity tracking.

Write an asynchronous batch Apex job that queries unaccepted cases every 15 minutes and updates ownership

Why it fails: Batch Apex runs on a schedule, so reassignment waits up to 15 minutes after the query, exceeding the stem's 15-minute acceptance window and risking duplicate updates. It tempts because batch Apex suits bulk, non-urgent record maintenance. Escalation timing here demands time-dependent workflow or scheduled flow logic.

Implement Einstein Next Best Action with automated record updates via Process Builder

Why it fails: Einstein Next Best Action recommends actions to agents rather than automating queue reassignments.

On the Entitlement record layout.

Why it fails: Incorrect. Entitlement records link to the process, but actions are configured in the process builder/admin tool for entitlements.

Inside the Case Process Builder workflow.

Why it fails: Incorrect. Process Builder cannot define milestone warning and violation actions natively.

Using Escalation Rules on the Case object.

Why it fails: Escalation rules act on case age and escalate cases or reassign them; they do not define milestone warning or violation actions. It is tempting because escalation rules also automate time-based case behaviour, and would be correct for escalating overdue cases, but milestone actions are configured on the milestone itself within Entitlement Processes.

Scheduled Apex Batch Jobs

Why it fails: Scheduled Apex Batch Jobs run on a timer against Salesforce records; they cannot ingest high-frequency inbound device events or publish them to subscribers. It is tempting because batch Apex handles large data volumes and could create Case records, and it would be correct for scheduled bulk processing rather than real-time event ingestion.

Standard Inbound Email-to-Case handlers

Why it fails: Email-to-Case converts inbound messages into Cases, but it is request-response and rate-limited, not a scalable publish-subscribe channel for high-frequency telemetry. It is tempting because it does automatically create Case records from inbound data, which matches the Case-creation half of the requirement, yet it cannot handle IoT event volume.

Chatter Feed Tracking triggers

Why it fails: Chatter Feed Tracking publishes record-change events on Salesforce objects, not external device telemetry, so it cannot ingest high-frequency IoT streams or trigger threshold-based Case creation. It is tempting because it does provide publish-subscribe style notifications, but only for user posts and field changes on records.

Encrypted Custom Objects with restricted page layouts

Why it fails: Encrypted custom objects store new data; they cannot relocate existing Case records, so storage and report performance stay unchanged. It is tempting because encryption and restricted layouts suggest controlled read-only auditing, but archiving requires moving records, which only the native archiving capability performs.

External Objects via Salesforce Connect

Why it fails: Salesforce Connect external objects query data held in an external system, so Cases would remain in Salesforce storage and continue affecting reports. It is tempting because external objects give read-only access, but the stem requires removing records from primary storage, which only native archiving achieves.

Standard Case Archiving Batch Job

Why it fails: No standard Case archiving batch job exists in Salesforce; archiving is a licensed add-on with its own setup, not a built-in scheduled batch. It is tempting because a batch job sounds like native automation, but the stem's requirement is met by the dedicated archiving feature, not a standard job.

Hardcode session tokens in custom metadata types for quick retrieval.

Why it fails: Storing session tokens in custom metadata exposes credentials to anyone with metadata access and cannot be rotated per user, breaking the security requirement. Metadata types are for deployable configuration, so they suit environment-specific settings, not secrets.

Execute all external integrations synchronously inside standard before-insert triggers.

Why it fails: Synchronous callouts inside before-insert triggers hold the database transaction open for the duration of the external REST round-trip, exhausting governor limits and locking records under load. Such triggers suit lightweight, in-transaction validation only; external billing calls belong in asynchronous, queueable or callout-enabled classes.

Knowledge translation is only supported for internal users with a full Salesforce license.

Why it fails: Knowledge translation works for external Experience Cloud users; licence type does not gate the feature. Restricting translation to full internal licences would be the answer if the platform limited localisation by licence, but the actual cause lies in language settings, article visibility or data category access.

Translated articles automatically default to 'Archived' status when viewed by community license holders.

Why it fails: Translation status is independent of licence type; articles are not auto-archived on viewing by community users. Archiving is a deliberate lifecycle action, so this would explain invisibility only if an administrator had archived the translation, not as an automatic consequence of external access.

The Knowledge component in Experience Cloud must have hardcoded language codes defined in URL parameters.

Why it fails: Experience Cloud Knowledge components resolve language from the user's locale and article translations, not hardcoded URL parameters. Hardcoding suits forcing a specific language for a single embedded article, but the likely cause here is missing translated article versions or language settings for external users.

Chatter Settings

Why it fails: Chatter Settings control feed tracking, posting and email notification behaviour, not console keyboard navigation. Shortcuts are enabled inside the Lightning Service Console's own settings; Chatter Settings would be the right place to enable feed tracking on a case object or suppress Chatter email digests.

Company Information setup page

Why it fails: Company Information holds org-wide defaults like fiscal year, locale and default currency, none of which govern console navigation. Shortcuts are toggled within the Lightning Service Console itself; Company Information would be the correct destination for changing the organisation's default language or address.

User Detail page settings

Why it fails: User Detail settings hold personal records such as profile, role and locale, and contain no console navigation configuration. Keyboard shortcuts are enabled per user from the Lightning Service Console's own settings; the User Detail page would be the right place to change an individual agent's assigned profile or permission set.

Archived articles must be manually deleted from Experience Cloud workspace CMS spaces.

Why it fails: Archiving already strips an article from Experience Cloud channels, so no CMS deletion step exists or is needed. Manual deletion is tempting because it guarantees removal, and it would be correct for permanently discarding an article rather than archiving it.

Archived articles stay visible to community users unless an explicit sharing rule is removed.

Why it fails: Archiving itself withdraws the article from public channels; no sharing rule governs that visibility. Sharing rules are tempting because they control record access, and they would be the right tool for restricting an article to internal users while it stays published.

Archived articles remain visible in Experience Cloud sites until a batch job runs nightly.

Why it fails: Archiving removes the article from Experience Cloud visibility at once, not through a scheduled batch. Nightly batch processing is tempting because scheduled jobs handle bulk record maintenance, and it would be correct for recalculating stored roll-up or sharing data on a timetable.

Queues are automatically deleted from the system.

Why it fails: Deactivating a Service Channel stops Omni-Channel routing work items for that channel; it does not delete queues, which exist independently of Omni-Channel. It is tempting because an inactive channel clearly breaks routing, but queue records persist regardless of channel activation state.

Agents cannot log into Omni-Channel.

Why it fails: An inactive Service Channel halts routing of its work items; it does not prevent agents logging into Omni-Channel, which depends on presence configuration and permissions. It is tempting because agents receiving nothing looks like a login failure, but the actual impact is routing suspension for that channel.

Existing open work items are automatically closed.

Why it fails: Inactivating a Service Channel suspends routing of new work items for that channel; existing open items are not automatically closed. It is tempting because inactive channels stop work flowing, but closure of open work requires agent or flow action, not channel deactivation.

Create a Case Assignment Rule with a 'Discard' action.

Why it fails: Case Assignment Rules run only after a case record is created, so a spam email still generates a case and any auto-response before assignment logic applies. They are tempting because they route cases by criteria, and would be correct for distributing legitimate cases to queues rather than preventing creation.

Set up spam filters in Web-to-Case settings.

Why it fails: Web-to-Case spam filters apply to web form submissions, not inbound email, so they never evaluate Email-to-Case messages and no discarding occurs. They are tempting because the name suggests shared spam handling, and would be correct if the source were a web form rather than an email channel.

Write an Apex trigger on the EmailMessage object to delete spam emails.

Why it fails: An EmailMessage trigger fires after the email and its case already exist, so deletion is reactive and auto-responses may already have been sent. Triggers are tempting for custom logic, and would be correct for post-creation processing, but Email-to-Case filters block spam before case creation.

Create a separate article type for Spanish and use workflow field updates to copy English content.

Why it fails: Workflow field updates cannot copy translated content between article types, and separate article types do not create the language-variant records Knowledge translation requires. It tempts because workflow field updates and article types are familiar tools for standardising article data across record variations.

Set up a Process Builder flow that calls an external translation API to overwrite the Spanish article fields.

Why it fails: Process Builder cannot overwrite Knowledge article version fields, and external API translation bypasses Knowledge's native translation workflow that generates language-variant articles on submission. It tempts because external translation APIs integrate with Flow for custom objects, where no native translation mechanism exists.

Configure Translation Management to automatically push articles to a localization vendor upon submission.

Why it fails: Translation Management connects to a localization vendor for human translation workflows, not automatic machine translation triggered on submission for review. It tempts because it is the genuine Knowledge feature for managing translations, and is correct when a vendor must translate content manually.

The system automatically converts the chat into an email case and closes the live session.

Why it fails: A lost connection returns the work item to its queue for reassignment once the agent's status changes, preserving the chat session rather than converting channels. Channel conversion is not automatic. Converting chat to email suits asynchronous follow-up when a customer cannot remain online.

The work item is escalated to the supervisor's Omni-Channel work list without changing queue status.

Why it fails: Supervisors see agent work through the supervisor console, but a dropped connection does not push the item onto a supervisor list; it returns to the queue for redistribution. Escalation to supervisors is used when a defined escalation rule triggers, not on connection loss.

The work item remains indefinitely locked to the disconnected agent until an administrator manually reassigns it.

Why it fails: Omni-Channel's routing configuration releases a work item back to the queue once the agent's connection drops, so it is not held indefinitely. Manual administrator reassignment is unnecessary. The option is tempting because indefinite locking does occur when an agent simply leaves a work item open without disconnecting.