Troubleshooting Scenario 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.

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.

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.

Modify the article type to mark the field as 'Required' so it appears on the article detail page.

Why it fails: Marking a field as required in the article type definition enforces data entry at creation or edit time, but it does not control whether the field is displayed on the article detail page for viewers. Required fields are a validation mechanism, not a layout mechanism. Changing the field to required could also disrupt existing publishing processes. The correct approach is to update the page layout, not the article type's field properties.

Create a new article type that includes the 'Steps to Resolve' field and migrate existing articles to it.

Why it fails: Creating a new article type would require migrating all existing articles, which is unnecessary and disruptive. The field already exists in the current article type; the issue is only its visibility. Article types define the structure of an article, but page layouts control the user interface. This approach does not address the visibility problem and introduces data migration overhead. The consultant should simply adjust the page layout instead.

Edit the field-level security for the 'Steps to Resolve' field to ensure the agent's profile has read access.

Why it fails: Field-level security determines whether a user can view or edit a field's data, but it does not control whether the field appears on a page layout. Even with read access, the field will not show on the article detail page unless it is added to the page layout. Field-level security is a permission control, not a layout control. Therefore, this action alone would not make the field visible to agents in the Knowledge component.

Business hours are not assigned to the User profile.

Why it fails: Milestone timers run against the entitlement's business hours, but missing hours on the User profile do not stop milestones from being created — they only affect target calculations. It tempts because business hours govern milestone timing, yet the failure here is that no milestone record is generated at all.

The Entitlement is associated with a Service Contract instead of an Account.

Why it fails: Entitlements attach to Accounts or Products, not Service Contracts, so this association cannot exist as described. It tempts because Service Contracts also define support coverage, but milestone generation depends on the entitlement's channel and SLA, not on contract linkage.

The Entitlement Template has not been applied to the Contact record.

Why it fails: Entitlement Templates seed default entitlements when a Contact or Account is created; they are not applied afterwards to activate an existing entitlement. It tempts because templates sound like the assignment step, but the stem already states the entitlement is active and assigned, so template application is irrelevant.

Omni-Channel Supervisor real-time metrics dashboard.

Why it fails: Omni-Channel Supervisor metrics report agent presence, capacity and work-item routing in real time; they expose nothing about API callouts or ERP synchronisation errors. API failures are diagnosed through API Usage notifications and debug logs. Supervisor metrics are correct for live queue and agent performance monitoring.

Knowledge article version history.

Why it fails: Knowledge article version history tracks revisions to article content and publication state; it holds no record of inbound API requests or their error responses. ERP synchronisation failures are investigated with API Usage notifications and debug logs. Version history is correct when auditing Knowledge article changes.

Standard Case History related lists on individual records.

Why it fails: Case History related lists record field changes made to a Case record over time; they do not capture API request payloads, status codes or integration errors. API failures require API Usage notifications and debug logs. Case History is correct for auditing user edits to individual case fields.

It relies entirely on manual tagging performed by agents when closing previous cases.

Why it fails: Recommendations are generated by matching case fields against article content, not by agent tagging. Manual tagging is tempting because tags do aid search, and it would be correct where agents curate a controlled vocabulary for article findability rather than relying on automated matching.

It requires custom Apex triggers that query articles using SOSL and push them to a custom related list.

Why it fails: The Lightning Knowledge component surfaces recommendations natively, so no Apex or SOSL query is required. Custom Apex is tempting because SOSL searches article text, and it would be correct for bespoke search behaviour the standard component cannot deliver.

It uses Assignment Rules configured in Setup to match case categories to data categories.

Why it fails: Assignment Rules route cases to owners or queues; they do not surface article recommendations. They are tempting because they match case fields to criteria, and they would be correct for distributing incoming cases to the right support queue.

Rich Text Component

Why it fails: A Rich Text Component displays formatted content on a record page but provides no insertion mechanism into case comments, so agents would still copy manually. It is tempting as reusable formatted content, and would be correct for displaying guidance or instructions on a page.

Email Templates

Why it fails: Email Templates populate outbound email bodies, not case comment fields, so they cannot insert pre-approved text into comments. They are tempting because they store reusable text, and would be the right choice when agents send standardised replies by email.

Custom Buttons

Why it fails: Custom Buttons execute URLs, JavaScript or Visualforce actions, not text insertion into a comment field, so they cannot paste pre-approved wording. They are tempting as one-click automation, and would suit launching an action or navigating elsewhere rather than inserting text.

Cases created outside business hours immediately trigger escalation actions upon creation.

Why it fails: Cases created outside business hours do not escalate immediately; the age clock starts only when business hours resume. It is tempting because creation is the obvious event, but escalation age accrues against the business-hours calendar, so the trigger fires later than the raw creation timestamp suggests.

The escalation rule will throw a system exception due to timezone mismatch.

Why it fails: No exception is thrown; escalation rules simply evaluate against the business-hours calendar without erroring. It is tempting because timezone and business-hours settings are related configuration, but the real effect is that the age clock excludes non-business time, delaying the trigger rather than failing.

Escalation rules ignore business hours entirely and always use 24/7 calendar time.

Why it fails: Escalation rules respect the business hours defined in your org, so they do not run on 24/7 calendar time. It is tempting because escalation age calculations can appear continuous, but the actual behaviour is that the clock pauses outside business hours, delaying the trigger.

Check that the Debug Log level for Workflow is set to Maximum.

Why it fails: Debug Log levels apply to Apex, Visualforce and process logs, not to Omni-Channel routing configuration, so raising Workflow to Maximum captures nothing about why work items fail to route. It is tempting because Maximum logging is genuinely useful when diagnosing Apex execution or flow interview errors in a developer sandbox.

Verify that external API endpoints are configured for native queue routing.

Why it fails: External API endpoints belong to Omni-Channel integrations and custom routing, not native queue routing, which relies on routing configurations, presence statuses and capacity settings. It is tempting because endpoint configuration genuinely matters when work items arrive through external systems, so it would be the right check for an API-driven integration scenario rather than this queue-routing failure.

Increase the API request limit by purchasing additional API calls in the org

Why it fails: Exceeding API request limits produces a REQUEST_LIMIT_EXCEEDED error, not a 401 or UNABLE_TO_LOCK_ROW. Purchasing more API calls does not address authentication failures or record lock contention. This action would not resolve either of the two errors described in the logs, so it is not a valid remediation for this scenario.

Convert the integration to use the Bulk API so records are processed asynchronously

Why it fails: Bulk API is intended for large data volumes and does not fix authentication errors or row lock contention. In fact, concurrent Bulk API batches can increase lock contention on shared parent records. Switching APIs does not address the root causes of either error and could worsen the locking symptom, so it is not an appropriate action here.

Enable field history tracking on the Case object to capture the cause of the failures

Why it fails: Field history tracking records changes to field values for auditing and reporting; it does not diagnose API authentication or record locking issues. Enabling it would consume data storage and add no diagnostic value for HTTP 401 or lock errors. This option misidentifies an auditing feature as a troubleshooting tool for integration failures.

Use Web-to-Case to automatically attach knowledge articles.

Why it fails: Web-to-Case creates new cases from web forms; it does not attach CRM Content files to an outbound agent email. It is tempting because it does link knowledge to cases automatically, and would be correct when capturing inbound web submissions rather than replying from Case Feed.

Paste the file URL into the subject line of the email.

Why it fails: A URL in the subject line is plain text, not an attachment, and recipients cannot open the PDF from it. It is tempting because sharing a link is a common workaround, and would be correct if the guide were hosted on an externally accessible site and a link sufficed.

Use a Macro to upload the file from the agent's desktop.

Why it fails: A Macro inserts predefined text or performs quick actions; it cannot pull a PDF from Salesforce CRM Content into an email. It is tempting because Macros do speed up Case Feed replies, and would be correct for inserting canned response text, not for attaching a stored content file.

Create a validation rule that prevents articles from being published unless the legal reviewer's name is entered in a field.

Why it fails: A validation rule can block saving or publishing based on field values, but it does not route the article to a reviewer or trigger a review step automatically. An author could type any name into the field to satisfy the rule, bypassing genuine legal review. This enforces data entry, not an approval workflow, so it does not meet the requirement.

Build a Flow that sets the article status to Published whenever the author saves the record.

Why it fails: Automatically publishing on save removes the legal review entirely, which is the opposite of what is required. The articles must be gated behind review before agents can use them, and this automation would expose unreviewed content immediately. Setting status to Published by flow is therefore a direct violation of the stated process.

Assign the articles a Draft validation status and manually notify the legal team by email when each draft is finished.

Why it fails: Draft status keeps an article unpublished, but relying on manual email notification means the review is not triggered by the author's submission and can easily be skipped. The requirement explicitly calls for an automatic trigger when the author submits, which manual notification cannot guarantee. This leaves the process error-prone and does not satisfy the automation requirement.

Milestone actions are configured on the entitlement but the milestone itself is not marked as active.

Why it fails: An inactive milestone would prevent that specific milestone from tracking after the entitlement is applied, but it would not explain why the entitlement lookup on the case is blank. The reported symptom is the missing association, not a milestone that fails to start once associated, so this is a secondary check rather than the first issue to investigate.

The Omni-Channel routing configuration is not assigning cases to a queue that has entitlement permissions.

Why it fails: Omni-Channel routing determines which agent receives work; it has no bearing on whether a case is linked to an entitlement or whether milestones accrue. Queues do not gate entitlement association, so this does not explain blank lookups, and it introduces an unrelated mechanism that would send the investigation in the wrong direction.

The Entitlement version records are not active, so milestone tracking cannot start.

Why it fails: An inactive entitlement version would prevent the entitlement from being selectable or applied, but the scenario states the account has an active entitlement. That makes this a less likely first suspect than the mechanism that actually links a case to an entitlement, and the described symptom of blank lookups points to the association logic rather than version status.

Standard Case Comment related list

Why it fails: Case comments are unstructured text boxes and do not provide dynamic step-by-step guidance.

Quick Actions with predefined field values

Why it fails: Quick actions execute predefined field updates or record creations, not interactive conditional questionnaires.

Entitlement Processes

Why it fails: Entitlement Processes define milestone and entitlement timelines for service contracts, not interactive question branching. They cannot present dynamically changing questions based on prior answers. A guided flow or Omni-Channel script is required for adaptive troubleshooting steps. Entitlement Processes would be correct when enforcing support term milestones and actions.