Explanation:

To communicate with the CK website's SOAP web service when a shoe's inventory changes due to an order status being updated to "Activated," Salesforce needs to trigger an action after the order record is saved. Here's a breakdown of why the After-Save Record-Triggered flow is the best choice and why the other options are less suitable:

A. After-Save Record-Triggered flow: This is the correct choice because the requirement involves calling an external SOAP web service after the order's status is updated to "Activated" and the inventory is reduced. An After-Save Record-Triggered flow (also known as an after-update flow) runs after the record is saved to the database, ensuring that the order status change and inventory reduction are committed before the external web service is called. Salesforce Flow supports making outbound SOAP calls via an "External Service" or an "Apex Action" (if custom Apex is used to handle the SOAP call). This ensures the website is updated with the correct inventory amount after the transaction is complete.

B. Before-Save Record-Triggered flow: This option is incorrect because a Before-Save flow runs before the record is committed to the database. If the SOAP web service call were made before the inventory update is saved, there’s a risk that the website could display incorrect inventory data if the save operation fails (e.g., due to validation rules or other errors). Additionally, external calls are typically more reliable after the record is confirmed to be updated.

C. Process Builder: While Process Builder can invoke processes after a record is saved and supports calling out to external services (via invocable Apex), it is a legacy tool. Salesforce recommends using Flows over Process Builder for new implementations due to Flow's greater flexibility, scalability, and ongoing support. Process Builder is being phased out, and Flows are the preferred automation tool for scenarios like this.

D. Workflow rule: Workflow rules are also a legacy tool and have limited functionality compared to Flows. They cannot directly make SOAP web service calls. While workflow rules can trigger outbound messages (which use SOAP), they are less flexible and harder to maintain for complex integrations compared to Flows, which can handle external service calls more robustly through integrations or Apex.

Why After-Save Flow is Ideal:
The flow can be triggered when the order status changes to "Activated" (using entry conditions in the flow).
It ensures the inventory update is committed before the SOAP call is made, avoiding inconsistencies.
Flows can integrate with external services using External Services (for SOAP APIs) or Apex to handle complex web service interactions.
Flows are Salesforce's recommended automation tool for modern development, offering robust debugging and error-handling capabilities.

Reference:
Salesforce Help: Record-Triggered Flows
Explains the difference between Before-Save and After-Save flows, highlighting that After-Save flows are suitable for actions like external callouts.
Salesforce Help: External Services
Describes how Flows can integrate with external SOAP APIs using External Services.
Salesforce Trailhead: Automate Your Business Processes with Flow
Covers the advantages of Flows over legacy tools like Process Builder and Workflow Rules.

Explanation:
A Reporting Snapshot is a powerful analytics tool that allows you to periodically capture historical data from a source report and store it in a custom object. This is useful for tracking trends over time. The source report for a Reporting Snapshot has specific format requirements.

Why A is Correct (Tabular format):
Tabular reports are the simplest report format and are eligible to be used as a source report for a Reporting Snapshot. They present data in a simple list, similar to a spreadsheet, without groupings.

Why B is Correct (Summary format):
Summary reports are the most common report type and are also eligible. They allow you to group rows of data, view subtotals, and are the basis for creating dashboards. The grouped data from a summary report can be mapped to the target custom object fields in a Reporting Snapshot.

Why C is Incorrect (Joined format):
Joined reports are not eligible to be used as a source for a Reporting Snapshot. A joined report allows you to create multiple report blocks based on different report types within a single report. This complex structure cannot be mapped to the single, standard target object required for a Reporting Snapshot.

Why D is Incorrect (Matrix format):
Matrix reports are not eligible to be used as a source for a Reporting Snapshot. Matrix reports group data by both rows and columns. This complex, cross-tabbed structure is incompatible with the linear, record-based structure needed to populate a custom object via a Reporting Snapshot.

Reference:
This question falls under the "Reporting and Dashboards" section of the exam guide. It specifically tests the knowledge of the prerequisites for configuring a Reporting Snapshot. The key detail is that only Tabular and Summary report formats can serve as the source report.

Explanation:

When an object has its Organization-Wide Default (OWD) sharing setting set to Private, access is restricted. To manually grant access to individual records on a case-by-case basis, users can utilize the Sharing button on a record. This button provides a menu to share the record with specific entities.

The options available for manual sharing are:

A. Public Groups: A Public Group is a collection of individual users, other groups, roles, or territories. Sharing a record with a Public Group grants access to all members of that group. This is a highly efficient way to share with a defined set of people.

C. Roles: The Role Hierarchy is a key component of the Salesforce sharing model. Sharing a record with a role grants access to all users in that role and all users in roles below it in the hierarchy. This is useful for sharing upward for visibility or across departments.

E. Users: This is the most granular option. A user can manually share a record with specific, named individual users. This is ideal for one-off sharing with colleagues who wouldn't be covered by a public group or role.

Why the Other Options are Incorrect:
B. Permission Sets: Permission Sets are used to grant object-level and field-level permissions (e.g., Read, Edit) and system permissions. They do not grant access to specific records. You cannot manually share a record with a Permission Set. Permission Sets determine what a user can do if they have access to a record, but they do not control which records a user can see.
D. Profiles: Profiles are the baseline for a user's functional permissions and object settings. Like Permission Sets, they control a user's abilities, not their access to individual records. You cannot manually share a record with a Profile.

Reference:
This question falls under the "Data Security and Access" section of the exam guide. It tests the understanding of manual sharing capabilities for an object with Private OWD. The key concept is knowing the three key entities (Users, Roles, Public Groups) that appear in the manual sharing dialog.

Explanation:

The feature that the app builder should use to allow users to create the opportunity is a quick action. A quick action is a type of custom button or link that can create or update records, log calls, send emails, or launch flows from a record page or a global menu. The app builder can create a quick action on the account object that creates an opportunity record with pre-populated fields.

Option B is incorrect because a default action is not a valid term, but rather a standard action that appears on every record page by default, such as Edit or Delete.
Option C is incorrect because a custom button is not suitable for this requirement, as custom buttons can only display a URL or execute JavaScript when clicked.
Option D is incorrect because a custom link is not suitable for this requirement, as custom links can only display a URL or execute JavaScript when clicked.

Explanation:

Why B is correct
Web-to-Case lets you place a public HTML form on an external website that creates Cases directly in Salesforce—exactly for “customers opening cases from a public-facing site.” It handles spam controls, auto-response, and case assignment options.

Why the others are wrong
A. Outbound message — Sends data out of Salesforce to an endpoint; doesn’t capture cases from a public site.
C. Screen flow — Could work if embedded in an Experience Cloud site, but not on a generic public website without authentication and hosting considerations; Web-to-Case is the native fit.
D. Email-to-Case — Creates cases from inbound emails, not from a web form.