Service and Support Applications practice questions

Record Types

Why it fails: Record Types determine business processes and picklist values available to users, but they do not control the layout of fields on the screen independently. They are used in conjunction with Page Layouts to show different fields, but the layout itself is what holds the field positioning and visibility.

Lightning App Builder

Why it fails: Lightning App Builder allows for the arrangement of components on a page, but it does not control field-level display within the record detail component. For distinct field layouts assigned to different profiles, Page Layouts assigned via the Page Layout Assignment tool are the required architectural solution for this requirement.

Field Level Security

Why it fails: Field Level Security restricts access to fields across the entire organization, regardless of the page layout. While it is useful for hiding sensitive data, it does not provide the capability to customize the visual arrangement or section grouping of fields to improve the workflow for the support team.

Field Level Security

Why it fails: Field Level Security hides or makes fields read-only for all records regardless of the case status. It cannot dynamically change the field behavior based on the value in the Status field. It is a static security setting that does not provide the conditional logic required for this specific case management scenario.

Sharing Rules

Why it fails: Sharing rules define record access (read/write) at the object level based on ownership or criteria. They do not prevent users with existing write access from editing fields. Sharing rules manage visibility and broad access, not the ability to perform field-level edits on records the user can already see.

Organization-Wide Defaults

Why it fails: Organization-Wide Defaults set the baseline access level for records. They are not intended to control field-level behavior or prevent editing on closed records. Changing OWDs would impact the access level for all users for all cases, which is too broad and does not address the specific business requirement.

The Automated Case User is not set correctly.

Why it fails: The Automated Case User is used for audit trails and system notifications. An incorrect user setting would not prevent a case from being created; it would simply result in the case being stamped with the wrong user in the audit history, which does not disrupt the actual intake process.

The Default Case Owner does not have access.

Why it fails: If the Default Case Owner is a valid queue, the case creation will succeed. Even if the queue members have restricted access, the system will still create the record. Issues with owner permissions usually surface after the case is created, rather than preventing the initial ingestion of the record.

Notify Case Owner is set to True.

Why it fails: The 'Notify Case Owner' setting controls whether an email alert is sent to the owner upon case creation. It does not influence the actual creation process. Disabling this would only stop an email from being sent; it would have zero impact on whether the case itself is successfully persisted.

Formula Fields

Why it fails: Formula fields are read-only and derived from other fields. They cannot be used as input fields on a form because the user cannot provide a value for a formula. They are meant for internal data calculation and display, not for user-provided categorization during the case submission process.

Auto-Response Rules

Why it fails: Auto-response rules are for sending emails back to the customer after a case is created. They have no role in collecting data or categorizing the case. Their function is strictly limited to post-submission communication, confirming that the company has received the request, and managing customer expectations regarding follow-up.

Escalation Rules

Why it fails: Escalation rules manage time-based follow-up for open cases. They are not used to collect data from customers during the submission phase. Using them for categorization would be technically impossible, as they are triggered by the passage of time on existing records, not by user input on a web form.

Component A

Why it fails: The Highlights component is for field display, not article searching. Its configuration would not impact the availability or functionality of the Knowledge base. Incorrectly diagnosing this would result in wasted time investigating the wrong area of the Lightning page, leaving the actual issue with the Knowledge component unresolved.

Component C

Why it fails: Related List Quick Links allow for fast navigation to related records like Contacts or Assets. They do not handle search or knowledge article display. Checking this component is irrelevant to the agent's inability to see knowledge articles, as it serves an entirely different purpose for record navigation and management.

Component D

Why it fails: A custom Lightning component could contain any logic, but it is not the standard location for Knowledge articles. Unless the company built a custom article viewer (which is rare), the standard 'Knowledge' component is the expected place to look. Troubleshooting a custom component first is an inefficient diagnostic approach.

Case creation is synchronous and fails immediately if validation rules fail.

Why it fails: Web-to-Case submissions are processed asynchronously by background batch queues rather than synchronously. Therefore, validation rules do not prevent initial submission on the web page, though they can impact subsequent automated processing depending on configuration settings.

Web-to-Case automatically encrypts all submitted customer data in transit and at rest.

Why it fails: While Salesforce enforces HTTPS for secure data transmission, standard Web-to-Case does not automatically apply platform encryption to stored case fields at rest unless Shield Platform Encryption is explicitly purchased, configured, and applied to those specific fields.

Submissions from untrusted domains are automatically blocked by IP filters.

Why it fails: Web-to-Case does not inherently block submissions based on domain trust or IP filters by default. Administrators must implement reCAPTCHA verification or custom Apex code to filter out spam and secure the public-facing submission endpoint against malicious bots.

Salesforce Knowledge

Why it fails: Salesforce Knowledge is a repository for creating, managing, and publishing informational articles to empower agents and customers. While it aids in troubleshooting, it does not enforce sequential business processes or track time-dependent service milestones for case resolution.

Email-to-Case

Why it fails: Email-to-Case converts inbound customer emails into support cases within Salesforce. Although it automates the intake channel for customer inquiries, it has no functionality related to guiding agents through internal case resolution steps or managing time-based service milestones.

Macro Builder

Why it fails: Macros allow support agents to execute repetitive multi-step actions with a single click, such as updating case fields and sending emails. While macros improve operational efficiency, they do not enforce a mandatory sequential milestone structure or validate SLA compliance.

The daily limit for Web-to-Case submissions has been entirely exhausted.

Why it fails: Web-to-Case and Email-to-Case are separate inbound channels with independent processing architectures. Exhausting the daily Web-to-Case quota of 500 records does not impact the operational capacity or email processing functionality of Email-to-Case.

The running user lacks permission to modify Omni-Channel presence statuses.

Why it fails: Omni-Channel presence statuses govern real-time agent availability and work distribution in the utility bar. They do not affect the asynchronous background processing of inbound email messages converted into cases by Email-to-Case.

Entitlement process milestones are missing a designated time-to-resolve target.

Why it fails: Entitlement processes and milestones apply service level agreements to cases after they have been successfully created. A misconfigured milestone will not prevent an inbound email message from generating a case record in the first place.

Implement sharing rules directly on Knowledge articles to restrict internal visibility.

Why it fails: Salesforce Knowledge does not support traditional criteria-based or owner-based sharing rules in the same manner as standard custom objects. Access control is managed exclusively through data category visibility and profile-level object permissions.

Enable Public Knowledge Base to automatically expose draft articles to search engines.

Why it fails: Exposing draft articles publicly would leak unverified internal instructions to external customers and web crawlers. Only published articles marked for public channels should ever be exposed via communities or public knowledge bases.

The case owner field is on a page layout that Tier 2 agents cannot access.

Why it fails: Page layout access controls field visibility and editability for users viewing the case record; it does not prevent the system from writing a new owner value when an Escalation Rule executes. Escalation Rule actions run in system context, unaffected by the layout assigned to the running user. A hidden or read-only owner field would confuse agents visually, but it cannot be the reason the underlying OwnerId never changed after the rule action ran.

The Tier 2 queue does not have any queue members assigned to it.

Why it fails: Queue membership determines which users can take ownership from a queue, but it does not block an Escalation Rule from assigning the case owner to that queue. Even an empty queue can technically be set as the owner; the agents simply could not retrieve the case until they were added as members. So missing queue members explains why Tier 2 agents cannot pull the case, not why the owner field itself never changed when the rule fired.

The case is currently locked by an approval process, which prevents automated owner reassignment.

Why it fails: A record locked by an approval process can block certain field edits, but Escalation Rule actions still execute their defined assignment. Approval locks restrict user edits, not the escalation engine's system-level updates to ownership. If the lock truly prevented the change, the administrator would see the case still owned by Tier 1 and likely other rule actions also failing, which is not the reported symptom pattern here.

The article type's page layout assignment for the agent's profile

Why it fails: Page layout assignment determines which fields and related lists appear when viewing an article, not whether draft articles are visible in search or lists. Even with a permissive layout, a user without the draft viewing permission will not see draft articles authored by others. The layout does not control record-level visibility of drafts, so changing it would not resolve the issue.

The article type's field-level security for the Draft Articles field

Why it fails: Field-level security controls access to individual fields on the article type, not the visibility of draft article records. The Draft Articles field is not a standard field that toggles draft visibility; draft visibility is governed by the article's publication status and the user's permission to view drafts. Adjusting field-level security would not grant agents the ability to see other agents' draft articles.

The data category visibility settings for the article type

Why it fails: Data category visibility controls which categories of articles a user can see, but it works in conjunction with the user's permission to view drafts. If the 'Allow Viewing of Draft Articles' permission is missing, the user will not see drafts regardless of category visibility. Category settings alone do not override the draft visibility restriction, so they are not the primary fix here.

A Lightning Web Component placed on the Case Record Page that queries Opportunities with SOQL.

Why it fails: A custom Lightning Web Component could technically surface opportunity data, but it requires development work, Apex controller permissions, and ongoing maintenance. The requirement is achievable with declarative Related Lists, so building custom code introduces unnecessary complexity, deployment risk, and a maintenance burden that the administrator does not need.

The Activity Timeline component on the Case Record Page.

Why it fails: The Activity Timeline consolidates tasks, events, and logged calls related to the case into a chronological view. It surfaces activities rather than related business records, so it would not show the account's open opportunities or recent cases, and therefore does not meet the stated requirement.

A Path Assistant configured on the Case object with guidance for each status value.

Why it fails: Path Assistant displays a guided chevron of picklist values and key fields for the case's current status, helping agents follow a process. It does not render related records such as the account's opportunities or other cases, so it cannot satisfy the requirement to view related customer data alongside the case.

Case Milestones with an Entitlement Process

Why it fails: Case Milestones track progress against entitlement terms, such as first response or resolution targets, but they require an Entitlement Process and are not the standard mechanism for simply reporting average first response time. They are more complex and intended for contractual SLAs, not basic time-to-first-comment measurement.

Case Reports with a custom formula field calculating the difference between CreatedDate and FirstCommentDate

Why it fails: Salesforce does not provide a standard FirstCommentDate field. While a custom formula could calculate a difference, there is no native field capturing the timestamp of the first agent comment, so this approach would require custom development. It is not the standard feature designed for this measurement.

Case Age report with a summary formula on the Age in Business Hours

Why it fails: Case Age measures elapsed time since creation, not time to first response. It does not distinguish between cases that have been responded to and those still awaiting a first reply. Using Case Age would report how long cases have been open, which does not answer the manager's question about response time.

Create a formula field on Case that subtracts the milestone target from the current time and display it as a read-only field on the layout.

Why it fails: Formula fields cannot reference the CaseMilestone object or its target date, because milestones are stored in a separate related object. A formula field can only use fields on the Case record itself, so it cannot compute remaining time to a milestone target dynamically. Even if it could, it would not color-code or refresh live, so it fails the visual warning requirement.

Configure Entitlement Milestone actions with a custom Visualforce header component that queries the CaseMilestone object.

Why it fails: Building a custom Visualforce header is possible but unnecessary and adds maintenance overhead when the platform already provides a native countdown indicator. Milestone actions themselves (such as 'Notify Assigned User') trigger on milestone completion or violation, not on a live visual timer. This approach also requires developer resources, which contradicts the administrator-first intent of the scenario.

Add a Case Milestone related list to the case page layout and enable the 'Show Milestone Timer' setting on the case page layout.

Why it fails: A Case Milestone related list only lists milestones and their completion status; it does not render a live countdown or color-coded warning on the record. The related list also does not surface a visual alert as the milestone nears breach, so agents would have to manually open the list to see remaining time. It does not satisfy the requirement for an at-a-glance warning indicator.

Create a workflow rule that overwrites the From field on the EmailMessage record after the agent sends the reply.

Why it fails: The From address on an outbound email is set when the message is sent and cannot be retroactively rewritten by a workflow rule on EmailMessage. Workflow rules also fire after save and cannot intercept the outbound SMTP envelope. This approach would not change what the customer sees in their inbox, so it does not satisfy the requirement and is technically unworkable.

Enable Email-to-Case and configure the routing address as the organization-wide email address for the support queue.

Why it fails: Simply routing cases to a queue does not change the From address on outbound agent replies. The routing address determines where inbound email is fetched and how cases are created, not what recipients see when an agent responds. Agents would still send from their personal address unless a separate shared-sender mechanism is configured, so this alone does not meet the requirement.

Configure a Case Auto-Response Rule so that every reply is sent from the support address.

Why it fails: Auto-Response Rules only fire once when a case is created from an inbound email, sending a single acknowledgment to the sender. They do not govern the From address of subsequent agent replies. Using an auto-response rule would notify the customer but would not change the sender identity on ongoing correspondence, so it fails the stated goal of shared-address replies.

Create a new entitlement process version that excludes the 'Resolution Time' milestone and activate it for the relevant entitlement.

Why it fails: Removing the milestone from the process stops tracking for all cases using that entitlement, not just cases whose entitlement has expired. It also applies at the entitlement level rather than dynamically per case based on expiry. This would prevent the milestone from ever running, including while the entitlement is still valid, which breaks the intended behavior for active customers.

Set the case's Entitlement field to blank when the entitlement expires, using a scheduled flow that detects expiry.

Why it fails: Clearing the Entitlement field does stop milestone tracking, but it also removes the entitlement association entirely, which the requirement explicitly forbids. It would also strip the case of any entitlement-based access or reporting and could trigger other automations tied to that field. The requirement says the case must remain linked while milestone counting stops, so blanking the field is not acceptable.

Add a milestone action to the entitlement process that fires on milestone violation and sets the case status to 'Closed'.

Why it fails: Closing the case on milestone violation contradicts the requirement that the case remain open and assignable. Milestone actions execute when a milestone is completed or violated, but they change case state rather than halting milestone tracking. Closing the case would also stop any further milestone evaluation entirely, which is a heavier side effect than the team asked for and would disrupt ongoing work.

Milestone breach counts can only be displayed with a Custom Report Type on the Entitlement object, because milestones belong to entitlements.

Why it fails: Milestones are associated with cases through the entitlement process, but the milestone records themselves live on the CaseMilestone object linked to Case. Reporting from the Entitlement object would not expose per-case breach counts or allow grouping by support queue. This option misidentifies where the data resides and would produce a report that cannot answer the supervisor's question.

The dashboard must use a Dynamic Dashboard so each supervisor sees only the queues they own, otherwise milestone data leaks across teams.

Why it fails: While a Dynamic Dashboard can filter by the running user, it is not required to prevent data leakage; sharing rules and report folder access already control visibility. The requirement is simply to show breach counts by queue, which a standard dashboard component satisfies. Claiming a dynamic dashboard is mandatory misstates the platform behavior and adds unnecessary complexity.

Milestone reports can only be grouped by Case Owner, so queue-based breakdowns are impossible and must be replaced with owner-based groupings.

Why it fails: Case records have an Owner field that can reference a queue, and reports can group by Owner, so breaking results down by support queue is entirely feasible. There is no platform restriction limiting milestone reports to user owners. This statement is false and would mislead the administrator into abandoning the required queue breakdown.

Web-to-Case and Escalation Rules

Why it fails: Web-to-Case is designed specifically for capturing inbound inquiries directly from a company website rather than processing incoming email messages. Escalation rules are used to automatically escalate cases that remain open past a specific timeframe, rather than handling initial routing based on product categories.

Omni-Channel and Macros

Why it fails: Omni-Channel routes work items based on agent availability and capacity rather than evaluating incoming case field criteria for initial assignment. Macros are productivity tools used by agents to execute repetitive steps on a case rather than serving as an automated routing mechanism.

Case Milestones and Entitlement Processes

Why it fails: Entitlement processes and milestones enforce service level agreements by tracking required support steps and timeframes. They do not perform the initial evaluation and routing of newly created cases to specific agents based on product categories.

It automatically creates a Knowledge article for every case closed.

Why it fails: Case Feed does not include an automated Knowledge creation engine. While Knowledge integration exists, it requires explicit agent interaction or custom automation like Flow to convert case details into a Knowledge article. Automating this without validation would lead to low-quality, redundant content in the knowledge base.

It replaces the need for the Service Console application.

Why it fails: Case Feed is a component commonly used within the Service Console, not a replacement for it. The Console provides the tab-based navigation and multi-column layout necessary for efficient case management, while the Feed provides the communication interface within those consoles. They are complementary, not mutually exclusive features.

It allows agents to bypass entitlement processes.

Why it fails: Entitlement processes are distinct features that track service level agreements. Using Case Feed does not grant agents the ability to ignore or skip these processes. The feed merely presents the interactions; the backend entitlement engine continues to enforce the rules regardless of the UI used to view cases.

Use the Assignment Rule.

Why it fails: Assignment Rules are only triggered upon the creation or manual update of a case. They cannot evaluate the passage of time or trigger actions based on how long a case has been open. They are meant for initial routing and load balancing of incoming work requests to agents.

Use the Entitlement Process.

Why it fails: Entitlement processes track milestones, such as first response time or resolution time, based on service contracts. While they can perform actions upon milestone completion or violation, Escalation Rules are the standard tool specifically intended for time-based oversight of open cases that have exceeded set threshold durations.

Use a Workflow Rule.

Why it fails: Workflow rules do not support time-dependent actions based on the duration of a case record existing in the system in the same flexible manner as Escalation Rules. While time-dependent workflow actions exist, Escalation Rules are purpose-built for service scenarios and offer superior management of case status queues.