Select Two (Multi-Select) Questions

Automatically convert the escalated case into a standalone Knowledge Article for future containment.

Why it fails: Escalation rules only reassign ownership or send notification emails; they cannot generate Knowledge Articles. Article creation needs a separate process, such as a Flow or Apex trigger. It tempts because converting resolved cases into articles supports future containment, but that is a knowledge management workflow, not an escalation action.

Instantly execute a custom Invocable Apex Action to provision replacement physical inventory.

Why it fails: Escalation rule actions are restricted to case reassignment and email notification; invoking Apex, even Invocable methods, is not supported. It tempts because provisioning replacement inventory suits high-priority escalations, but that automation must run through Flow, Process Builder, or a trigger instead of the escalation rule itself.

Publish the escalated case details automatically to an external public Chatter feed group.

Why it fails: Escalation rule actions are limited to reassigning the case owner or sending email notifications; publishing to an external public Chatter feed group is not an available action. It tempts because Chatter feeds can broadcast case updates, but that requires separate automation such as Flow or Apex triggers, not escalation rule entry actions.

Auto-Response Rules

Why it fails: Auto-response rules are strictly for sending email responses to customers based on case creation. They have absolutely no integration with Knowledge article quality or visibility. Using this feature to manage content would be impossible, as the two features operate in completely different areas of the Salesforce Service Cloud platform.

Assignment Rules

Why it fails: Assignment rules are used for routing case records to queues or users. They cannot be used to route knowledge articles or control their publication lifecycle. Applying assignment rule logic to articles is a fundamental misunderstanding of the platform's architecture, as article lifecycle management requires specific Knowledge-based workflow capabilities.

Public Groups

Why it fails: While Public Groups can be used for record sharing, they are not the primary tool for Knowledge article visibility. Data Categories are the specific mechanism designed to classify and manage access to Knowledge articles. Using groups would be an inefficient and less scalable workaround for managing complex article visibility requirements.

Disable all Chatter notifications for users to prevent information overload.

Why it fails: Disabling all notifications would prevent users from receiving any updates, which contradicts the goal of keeping users informed without overwhelming them. The requirement is to avoid overwhelming, not eliminate notifications entirely. This action would hinder collaboration and awareness. Therefore, it is not appropriate; a more balanced approach is needed.

Configure default email notification settings to 'Daily Digest' for all users.

Why it fails: While email digests can reduce notification volume, they do not directly enable collaboration on records or file sharing. The daily digest is a personal setting, not an administrative default that can be enforced org-wide. Moreover, it does not address the need for real-time collaboration; it only summarizes activity. Thus, it does not fulfill the requirement to enable collaboration and sharing.

Enable 'Chatter Email Notifications' and set them to 'Never' for all users.

Why it fails: Setting email notifications to 'Never' would stop users from receiving email updates, which may cause them to miss important information. While it reduces volume, it does not support the goal of receiving relevant updates. It also does not facilitate collaboration or file sharing. Thus, it is not a recommended action for this scenario.

A defined Auto-Number field.

Why it fails: While auto-number fields are useful for record naming, they are not mandatory. Administrators can choose to use a Text-based Name field instead. This flexibility allows businesses to choose between systematic numbering and descriptive naming conventions for their primary record identifiers depending on their specific operational workflows.

An assigned Tab visibility setting.

Why it fails: Tab creation is an optional step during the custom object setup process. An administrator can choose not to create a tab if the object is intended to be used solely as a lookup for other objects or if it will only be accessed via API integrations.

A set of custom fields.

Why it fails: Custom objects do not require custom fields upon creation. The system automatically creates standard system fields like Created By, Last Modified By, and the Name field. Administrators can add specific custom fields later based on the evolving business requirements after the object has been successfully provisioned in the system.

Grant the agent's running user Modify All Data to ensure it can reset any user's password.

Why it fails: Granting Modify All Data is a security anti-pattern and is not a testing practice. Least privilege should be applied to the agent's user, and the password reset action should be scoped to the requesting user. Broad permissions increase risk without validating correctness. Testing should confirm the agent works within appropriate permissions, not bypass them.

Activate the agent in a production org and monitor real customer conversations for the first week.

Why it fails: Testing in production with real users risks exposing sensitive behavior and poor responses before the agent is validated. For a password reset flow, a mistake could lock users out or leak information. Production monitoring is valuable after go-live, but it is not a pre-activation testing practice and does not satisfy the requirement to validate safely first.

Disable all topics except the password reset topic to force the agent to always use the correct flow.

Why it fails: Disabling topics is a configuration change, not a testing practice. It would also mask routing problems that testing should reveal, and it could break the agent for other legitimate requests. The goal is to validate behavior, not to constrain it artificially. This does not verify response quality or action execution.

Configure Chatter to allow customers and partners to join public groups without moderation.

Why it fails: Allowing external users to join public groups without moderation can lead to unauthorized access and data leakage. While Chatter External can be used for collaboration with customers and partners, it should be tightly controlled with moderation and clear policies. Unmoderated access does not support security and compliance goals and could expose sensitive information.

Enable Chatter feed tracking on sensitive fields to automatically post changes to the record feed.

Why it fails: Enabling feed tracking on sensitive fields can inadvertently expose confidential data to users who have access to the record feed but should not see those field changes. While feed tracking is useful for collaboration, it must be carefully configured to avoid security breaches. For sensitive fields, it is better to disable feed tracking or restrict feed visibility. This action does not align with maintaining security and compliance.

Enable unlisted groups so that users can create private groups without administrator approval.

Why it fails: Unlisted groups allow users to create groups that are not visible in searches or group lists, but they can still be accessed by anyone with the link. This can lead to unmanaged collaboration spaces and potential security risks. While unlisted groups have their uses, enabling them without oversight does not support security and compliance. Administrators should instead use approval processes for group creation if control is needed.

Add the 'Hazardous' field to a new page layout and assign the layout only to the profiles that should see it.

Why it fails: Page layouts control which fields appear on the record detail page, but they do not grant or restrict access to the field itself. If field-level security allows a profile to see the field, that profile could still access it through reports, list views, or the API even if it is not on the page layout. The requirement is to control visibility based on profile, so field-level security is the correct mechanism, not page layout assignment alone.

Create a validation rule that checks the 'Hazardous' field value and prevents saving when the user is not in the correct profile.

Why it fails: Validation rules enforce data quality at save time; they cannot hide a field from view. A user would still see the 'Hazardous' checkbox and could attempt to change it, only to be blocked on save. The requirement is to control visibility based on profile, which is a field-level security concern. Using a validation rule would create a confusing experience and does not meet the visibility requirement.

Create a Master-Detail Relationship field on Shipment__c to the Account object.

Why it fails: A Master-Detail Relationship tightly couples the child record to the parent, making the parent required and controlling ownership, sharing, and deletion behavior. While it can relate a Shipment to an Account, it forces the Account to be required and changes the sharing model, which may not be desired. The requirement says 'relate to a single Account record' but does not require the strict ownership and cascade behaviors of master-detail, so this is not the best fit.

The flow can create the Task in a before-save flow if the Task is related to the Opportunity.

Why it fails: Even if the Task is related to the Opportunity, creating it requires a DML operation on a different record, which is not allowed in a before-save flow. Before-save flows are limited to modifying the triggering record itself. The administrator must use an after-save flow to create the Task, regardless of the relationship.

The flow must use a scheduled path to create the Task at a later time.

Why it fails: A scheduled path is used to execute flow logic at a future time, not immediately when the record changes. The requirement is to create a follow-up Task when the stage changes to Negotiation, which implies immediate action. Using a scheduled path would delay the Task creation and is not necessary unless a time delay is explicitly required.

The flow can update the Opportunity and create the Task in a single before-save flow.

Why it fails: A before-save flow cannot create records because it does not support DML operations on records other than the triggering record. Attempting to create a Task in a before-save flow would result in an error or require an after-save flow instead. The administrator must separate the update of the triggering record from the creation of related records, typically using an after-save flow for the Task.

Set the organization-wide default for opportunities to Private and manually share each opportunity with the team.

Why it fails: Setting opportunities to Private would restrict access, making it harder for the team to collaborate. Chatter posts on records are visible only to users with access to the record. Private sharing would require manual sharing for each opportunity, which is inefficient and contrary to the goal of open collaboration.

Grant 'Modify All Data' permission to all sales team members so they can see all Chatter posts and files.

Why it fails: Granting 'Modify All Data' is a severe security risk and violates the principle of least privilege. It is unnecessary because Chatter visibility is based on record access, not on this permission. Users only need access to the opportunities to see related posts and files. This action would not specifically address the collaboration requirement and could expose sensitive data.

Create a Chatter group for the sales team and instruct members to post updates there instead of on records.

Why it fails: While Chatter groups are useful for collaboration, posting updates in a group instead of on records means the posts are not directly associated with the opportunities. This can lead to context loss and does not ensure that all team members see posts related to specific opportunities. The requirement is to collaborate on opportunities, so record-level Chatter is more appropriate.

Reduce the agent's topic scope so it only answers questions about store hours and shipping times.

Why it fails: Narrowing topics limits what the agent attempts to answer, which can reduce risk incidentally, but it does not mask card digits when payment data does enter context and it generates no compliance record of interactions. The security team's requirements are technical controls, and scope reduction is a design choice that leaves both controls absent.

Assign the agent user a profile with Modify All Data so it can retrieve any record a customer references.

Why it fails: Granting Modify All Data would let the agent read and change virtually every record, which expands exposure instead of limiting it and violates least privilege. Broader access does nothing to prevent raw card digits from reaching the model or to create an audit record, so it works against both security requirements rather than satisfying either of them.

Create a validation rule on the payment object that blocks saving records containing full card numbers.

Why it fails: A validation rule restricts what users and integrations can persist, which is useful data hygiene, but it does not govern what an agent sends to or receives from a model at runtime. Existing records with digits would still be retrievable and could appear in responses, and the rule produces no interaction trace, so neither requirement is met.

Set the organization-wide default for Leads to Public Read/Write.

Why it fails: Public Read/Write allows all users to view and edit all Leads, but it also grants that access to everyone, which may not be desired. The requirement is for a specific user to have this access, not all users. This setting is too broad.

Create a sharing rule to share all Leads with the marketing user.

Why it fails: A sharing rule can share records with a user, but it is not the most efficient way to grant access to all Leads. Sharing rules are typically used for groups or roles, and they may not cover all records if criteria are used. The 'View All' and 'Edit All' permissions are more direct.

Assign a permission set with the 'Modify All Data' permission.

Why it fails: Modify All Data grants broad access to all data and is excessive for this requirement. It also does not specifically grant the ability to import Leads. This permission is typically reserved for administrators and violates least privilege.

The Omni-Channel Supervisor wallboard, which displays real-time agent status and workload.

Why it fails: Omni-Channel Supervisor is designed for supervisors to monitor queue depth, agent presence, and workload in real time. It does not present case-specific knowledge or customer history to the agent handling the case, so it does not help the individual agent resolve cases faster and is not the capability described.

The Macros feature, which lets agents run a set of predefined actions on a case with one click.

Why it fails: Macros automate repetitive updates such as sending an email, updating a field, or adding a comment, improving efficiency on routine tasks. Macros do not surface knowledge articles or customer history to inform the agent's decision, so they do not satisfy the requirement to bring relevant reference information into the console.

The Path Assistant for the Case object, which guides agents through status picklist values.

Why it fails: Path Assistant shows a chevron of status values with key fields and guidance for each stage, helping agents follow a defined process. While useful for consistency, it does not surface knowledge articles or customer history, so it does not meet the stated goal of bringing relevant information to the agent during case work.

Use a Wait element configured to resume after one minute, then send the email.

Why it fails: The Wait element pauses an interview and is intended for asynchronous timing, but it does not create the Case record. Adding a wait would delay the confirmation without satisfying the insert requirement, and it introduces unnecessary complexity. The Flow still needs a Create Records element to persist the Case.

Use a Post to Chatter action to notify the support team instead of sending email.

Why it fails: Posting to Chatter creates a feed item, not an email, so it does not meet the requirement of sending a confirmation email. While it can notify users, the recipient experience and channel differ from email. This option changes the requested behavior rather than implementing it.

Use a Record-Triggered Flow with a before-save update to insert the Case.

Why it fails: A Record-Triggered Flow requires an existing record event to fire; it cannot be launched interactively by a user to collect screen input. Mixing a Screen Flow with a Record-Triggered Flow is not how a single interview both gathers input and inserts a record. The Screen Flow itself should perform the create.

Path Assistant component

Why it fails: The Path Assistant component visualizes a record's progress through a defined sales or service process, showing stages and key fields for each stage. It is designed for process guidance on the current record, not for displaying related Contact information or a list of Case Comments. This component addresses workflow guidance rather than related data display.

Highlights Panel component

Why it fails: The Highlights Panel displays key fields and actions for the current record at the top of the page, such as Case Number, Status, and owner. It does not display related parent records or related child lists. While useful for summarizing the Case itself, it cannot show the related Contact details or the Case Comments list, so it does not meet either requirement.

Report Chart component

Why it fails: The Report Chart component embeds a chart from a report directly on the record page, often filtered by the current record. It displays aggregated reporting data, not individual related records such as a specific Contact or a list of Case Comments. This component is intended for analytics visualization rather than showing parent or child record details.

Set the flow to run only when a record is created, not updated.

Why it fails: The requirement is to react to a change in BillingCountry, which occurs on update, not on creation. Restricting the flow to create-only would prevent it from ever firing when the country changes on an existing Account. This option contradicts the scenario's need and would result in no Contact updates.

Use a before-save flow to update the Account's BillingCountry field directly without additional DML.

Why it fails: A before-save flow can update the triggering Account record without extra DML, but the requirement is to update related Contacts, not the Account itself. Before-save flows cannot update related records because they operate before the record is committed and lack the record ID for related updates. This option does not address the stated need.

Configure the flow to run asynchronously to avoid governor limits.

Why it fails: Asynchronous execution can help with callouts and long-running operations, but it does not reduce the need to query and update Contacts, nor does it make the flow run only when necessary. It may introduce delays and complexity without addressing the core efficiency requirement. Synchronous execution is appropriate for simple cross-object updates.

Set the flow to run in system context without sharing.

Why it fails: Running in system context without sharing affects record access and is not related to filtering by Priority or trigger type. This setting would not help ensure the flow runs only on create and for High priority Cases. It is irrelevant to the requirement.

Add a Get Records element to retrieve the Case's Priority.

Why it fails: A Get Records element is not needed to retrieve the Case's Priority because the triggering record's fields are available directly in the flow. Using Get Records would add an unnecessary query and could cause performance issues. The Priority can be referenced directly from the trigger.

Add a Decision element that checks if the Priority equals 'High'.

Why it fails: A Decision element can check the Priority, but it is not the most efficient way to filter. Entry criteria are evaluated before the flow runs, reducing unnecessary executions. However, a Decision element would still work, but it is not a required configuration if entry criteria are used. The question asks for required configurations, and the best practice is to use entry criteria.

Create a trigger on 'Package__c' that updates the parent 'Shipment__c' record.

Why it fails: Apex triggers can achieve aggregation, but they require code and maintenance. The scenario asks for a declarative solution, and triggers are not necessary when roll-up summary fields are available. Triggers also consume governor limits and are more error-prone than standard functionality.

Create a formula field on 'Shipment__c' that uses a cross-object formula to reference 'Package__c'.

Why it fails: Cross-object formula fields can reference fields on parent objects, not child records. Since 'Package__c' is a child of 'Shipment__c', a formula cannot aggregate multiple child records. This approach would not work because formulas operate on a single record and cannot sum related lists.

Use a Process Builder to update the total weight field whenever a 'Package__c' record is created or updated.

Why it fails: Process Builder can automate field updates, but it is not designed for real-time aggregation across many child records. It would require complex logic and may hit governor limits. Moreover, it is not the standard declarative solution for roll-up summaries, which are more efficient and reliable.

Configure a Named Credential for each Salesforce object the agent needs to access.

Why it fails: Named Credentials are used for external callouts to authenticate to third-party services, not for accessing internal Salesforce data. The agent accesses Salesforce objects directly through the platform, so Named Credentials are unnecessary and would not enable data retrieval. They are relevant only when the agent needs to call external APIs.

Enable the Einstein Trust Layer and set data masking rules for all fields.

Why it fails: The Einstein Trust Layer provides data masking and zero-data retention to protect sensitive information, but it does not grant access to data. Enabling it is a security best practice, but it does not enable the agent to retrieve data from objects. Data masking rules would actually restrict the data shown, so they are not a requirement for access.

Assign the agent's running user a profile with the 'Modify All Data' permission.

Why it fails: The 'Modify All Data' permission grants broad access to edit all data, which is excessive and violates the principle of least privilege. The agent only needs read access to specific objects and fields. Assigning this permission would not only be a security risk but also unnecessary for enabling data retrieval. Proper access is achieved through targeted permission sets.

Sales Cloud

Why it fails: Sales Cloud is focused on lead and opportunity management. While it can exist in the same instance, it is not a requirement for building a self-service support portal. The focus of the portal is on service, which relies on Service Cloud features rather than sales-specific pipeline management.

Email-to-Case

Why it fails: While useful, Email-to-Case is an alternative ingestion method and is not strictly required for a portal. A portal allows for direct case entry via web forms, which is often preferred over email. Therefore, it is not a foundational requirement for the functionality of the self-service portal itself.

List Views

Why it fails: While list views are useful, they are typically used for navigation rather than as embedded components within a record's console view. Adding a full list view as a component inside a case record would clutter the interface and provide little utility for the agent tasked with a specific case.

Report Charts

Why it fails: Report charts are valuable for management dashboards but generally do not contribute to agent productivity during active case handling. Including them in the console layout would take up valuable screen real estate without helping the agent resolve the current customer issue, creating an inefficient user interface for the frontline staff.