Explanation:

This question tests the feature that helps reps perform multiple case updates with one user-friendly action. The requirement includes sending an email, changing case status, and updating the case owner, which is exactly the kind of repetitive work a macro with quick actions can streamline. It gives agents a simple way to apply several updates at once without navigating through multiple screens.

✔️ Correct Option:

Option B: Macros with Quick Actions
Macros are designed to automate repetitive service tasks by running a sequence of actions on a case. When combined with quick actions, they can update fields like Status and Owner and can also trigger an email-related action. This makes them the best choice for giving reps a fast, easy way to complete all required updates in one step.

❌ Incorrect options:

Option A: Case Assignment Rules
Case assignment rules automatically route cases based on criteria, but they do not give reps a one-click way to update multiple fields and send an email. They are useful at case creation, not for helping agents perform manual follow-up actions efficiently.

Option C: Quick Text with Email Templates
Quick Text and email templates help agents insert standard text into messages, but they do not change case owner or status. They support faster communication, but they do not handle the full set of updates required in this scenario.

Option D: Autolaunched Flows with Email Alerts
Autolaunched flows can automate backend logic, but they are not the easiest user-facing tool for reps to trigger manually. This option is more suited to process automation than to giving agents a simple, interactive update method.

🔧 Reference:
→ Create Macros in Salesforce Classic — Confirms macros automate repetitive service tasks and can run multiple actions.
→ Create Quick Actions — Confirms quick actions can update records and streamline user work.

Explanation:

This question tests knowledge of Salesforce's case management features that help enforce SLA compliance. The scenario requires a mechanism that automatically moves unresolved cases to a higher support tier after a defined time period has passed — a core escalation use case in Service Cloud.

✅ Correct Option:

D. Escalation Rules — Salesforce Escalation Rules automatically reassign or notify when a case has remained open beyond a set time threshold. They can route cases to a Tier 2 queue or team if no action is taken within the SLA window, making them the ideal built-in tool for time-based case escalation without custom automation.

❌ Incorrect Options:

A. Milestones and Entitlements — These track SLA terms and time-based targets per customer contract (e.g., first response time). While related to SLAs, they do not automatically route or escalate cases to another team when a deadline is missed. They measure compliance, not enforce routing action.

B. Omni-Channel Routing — This feature intelligently distributes work items to available agents based on capacity and skill. It handles initial case routing in real time but does not provide time-based escalation logic to move cases to a Tier 2 team after an SLA breach.

C. Auto Response Rules — These send automated email replies to customers when a case is created or updated. They are purely outbound communication tools and have no functionality to monitor case age, enforce SLA timelines, or reroute cases to escalation teams.

🔧 Reference:
→ Salesforce Help – Set Up Escalation Rules
Confirms that Escalation Rules automatically reassign or escalate cases based on time criteria to meet SLA requirements.

Explanation:
Within a Salesforce Approval Process, the administrator can configure immediate actions that execute automatically at various points (Initial Submission, Final Approval, Final Rejection, Recall). Among the available action types are Field Updates (to modify record values) and Email Alerts (to send notifications to users). These are standard, declarative actions supported natively in approval processes.

Correct Option: A

Field Update allows automatic modification of field values on the record when approval actions occur.

Example: Set Status__c = "Approved" upon final approval, or Status__c = "Denied" upon final rejection.

No code required; supports formula values and references.

Correct Option: B

Email Alert sends automated email notifications to specified recipients (e.g., requester, approvers, HR team).

Example: Notify employee when time-off request is approved, or notify manager when a request is submitted.

Uses email templates and can be triggered at any action point in the approval process.

Incorrect Option: C

Chatter Post is not a native action type directly available in standard approval process actions.

While approval processes can trigger email alerts and field updates, Chatter posts require Flow or Process Builder as a workaround.

Not a built-in, point-and-click option within approval action configuration.

Incorrect Option: D

Autolaunched Flow is not a direct action type in approval process setup.

A Flow can be triggered by an approval process indirectly via a field update that then invokes a Flow, but it is not a native action button in the approval action wizard.

The question asks for automated actions "available as part of the approval process" — Field Update and Email Alert are the two correct native options.

Reference:
Salesforce Help Article: Approval Process Actions – The available immediate actions in an approval process are: Field Update, Email Alert, Task, and Outbound Message. Autolaunched Flows and Chatter Posts are not directly available as approval actions. Use native actions for declarative automation.

Explanation:
Salesforce dashboards respect the running user's record-level access. By default, a dashboard shows data based on the viewer's permissions. To display an enterprise-wide view without changing individual user sharing settings (e.g., role hierarchy or sharing rules), the administrator can set the running user to a user profile (e.g., an integration user or admin) who has "View All" access to Opportunities. All viewers then see data as that running user.

Correct Option: A

Setting running user to a user with "View All Data" or "View All Opportunities" allows the dashboard to bypass individual user sharing restrictions.

No changes to user sharing settings (OWD, role hierarchy, sharing rules) are required.

The dashboard displays all open opportunities to all viewers without granting them direct record access.

This is the standard approach for executive or company-wide dashboards.

Incorrect Option: B

Filter by owner role would restrict data based on role, which does not solve the problem of users seeing only their own opportunities.

Users would only see opportunities owned by their role (or subordinates), not the entire pipeline.

Does not use a "running user" override.

Incorrect Option: C
Individual dashboards per profile would require duplicating the dashboard many times, each with a different running user—inefficient and hard to maintain.

Does not address the core issue; still requires a running user with full access on each.

Not scalable.

Incorrect Option: D

Dashboard folder settings (e.g., Manager for sales reps role) control who can view or edit the dashboard itself, not the data displayed within it.

Changing folder settings does not override record-level sharing for opportunity data.

Irrelevant to the requirement.

Reference:
Salesforce Help Article: Set the Running User for a Dashboard – Use the "Run As" option to specify a running user with broader record access. This allows viewers to see data they wouldn't normally have access to without changing individual sharing settings. Dashboard folder permissions do not affect data visibility.

Explanation:

The question tests Email-to-Case setup and case routing. Northern Trail Outfitters needs customer emails to auto-create cases that go straight to the appropriate support queue without manual assignment. You must know which native feature controls initial case ownership at creation.

✔️ Correct Option:

Option D:
When you set up Email-to-Case, each routing address has a Case Owner field that can be set to a queue. This field overrides the Default Case Owner and routes all new cases from that specific email address directly to the chosen queue. It’s the native, declarative way to ensure emails like support@ or billing@ create cases for the right team immediately.

❌ Incorrect options:

Option A:
Create an escalation rule to send cases to the correct queue: Escalation rules reassign cases based on time-based criteria after creation, not at intake. They’re for SLA breaches, not initial queue routing.

Option B:
Use a custom email service to set the owner of the case upon creation: Email services require Apex code for custom processing. That’s overkill when Email-to-Case routing addresses already provide a declarative field to assign a queue as owner.

Option C:
Utilize a flow to identify the correct queue and assign the case: A Flow runs after the case is created and adds maintenance overhead. Native routing address settings assign the queue at the moment of case creation with no automation needed.

🔧 Reference:
→ Add Routing Addresses for Email-to-Case - Confirms the Case Owner on a routing address sets the queue for new cases from that emai