Explanation:

The question is about extending access beyond the baseline restrictions set by Organization-Wide Defaults (OWD). OWDs set the most restrictive level of access (e.g., Private, Public Read Only). The tools used to liberalize or grant additional access on top of these defaults are Sharing Rules and Manual Sharing.

Why A is Correct (Sharing Rules):
Sharing rules are the primary automatic tool for extending access. They are used to automatically grant broader access to records based on criteria (criteria-based) or ownership (owner-based). For example, if the OWD for an object is Private, a sharing rule can be created to automatically share records owned by users in one role with users in another role.

Why D is Correct (Manual Sharing):
Manual sharing allows users to grant access to individual records on a case-by-case basis. This is a manual exception to the OWD. For example, a user who owns a private record can click the "Share" button to grant read or edit access to another specific user or a public group. This directly extends access beyond what the OWD alone would allow.

Why the Other Options are Incorrect:
B is Incorrect (Public Groups):
A Public Group is a tool used within sharing rules and manual sharing, but it is not itself a mechanism for extending access. You create a public group of users and then use a sharing rule or manual sharing to grant access to that group. The group itself does not change record access.
C is Incorrect (Permission Set Groups):
Permission Set Groups are used to bundle and assign user permissions (object-level, field-level, and system permissions). They control what a user can do (e.g., read, edit, delete) if they have access to a record. They do not control which records a user has access to see. That is governed by the sharing model (OWD, sharing rules, roles, etc.).

Reference:
This question falls under the "Data Security and Access" section of the exam guide. It tests the fundamental understanding of the Salesforce Sharing Model, specifically identifying Sharing Rules (automatic) and Manual Sharing (user-driven) as the two tools used to grant additional record access on top of restrictive Organization-Wide Defaults.

Explanation:

Why these are correct
Approval processes can fire automated actions on initial submission (and other stages). The supported action types include Email Alert, Task, Field Update, and Outbound Message. From the choices given, the three applicable ones are Email Alert (A), Outbound Message (B), and Task (C).

Why not the others
D. Invocable Flow — “Flow” isn’t one of the classic approval action types listed for approval processes (those are email alerts, tasks, field updates, and outbound messages).
E. Invocable Process Builder — Process Builder actions aren’t an approval action type.

References:
Salesforce Help & Trailhead overviews of approval-process actions (email alerts, tasks, field updates, outbound messages).

Explanation:

Schema Builder is a powerful visual tool in Salesforce that allows app builders to create and modify objects, fields, and relationships. However, it has some limitations when it comes to layout and UI configuration.

✅ Why B is correct:
Schema Builder lets you create custom objects, fields, and relationships visually.
However, it does not allow you to add fields to page layouts directly from the canvas.
After creating fields, you must go to Lightning Object Manager or Page Layout Editor to manually place those fields on the layout.

❌ Why the other options are incorrect:
A. "Save" should be clicked each time...
Not a limitation—this is standard behavior for any configuration tool.
C. Relationships to standard objects must be built in Lightning Object Manager
Incorrect—Schema Builder supports relationships to both standard and custom objects.
D. Formula fields can't be added
False—formula fields can be created in Schema Builder just like other field types.

📘 Reference:
Salesforce Help: Schema Builder Overview
Trailhead: Data Modeling

Explanation:

To ensure that Reviews are only visible to the submitting employee and the HR department, a combination of security controls is required.

1. Set Organization-Wide Defaults (OWD) to Private
The most fundamental step is to set the organization-wide default (OWD) for the Review object to Private. This ensures that by default, only the record owner (the employee who submitted the review) has access. No other users can see the records unless explicitly granted access. This addresses the "employee who submitted the record" requirement.

2. Disable Grant Access Using Hierarchies
When the OWD is set to Private, users higher in the role hierarchy still have read access to records owned by users below them. To prevent managers or executives from seeing their employees' reviews, you must disable "Grant Access Using Hierarchies" for the Review object. This ensures that only the record owner has access by default, and access is not automatically granted to anyone above them in the hierarchy.

3. Create a Sharing Rule for the HR Department
Since the HR department needs to view all reviews, you must create a sharing rule. A sharing rule grants access to a group of users (in this case, the HR department, which would likely be a public group or a role) to a set of records. A criteria-based sharing rule is a good choice, as you could set the criteria to share all records with the HR group.

Why Other Options Are Incorrect
B. Add a Master-Detail (User) field on the Review object: A master-detail relationship would tightly couple the Review record to a User record. While this helps with data integrity, it's not a primary method for controlling sharing and does not solve the hierarchy issue. The OWD and sharing rules are the direct tools for this.
D. Remove Review Read permission from non-HR Department user Profiles: This is not a viable solution. If a user's profile does not have Read permission on an object, they cannot create or submit records of that type in the first place, which would prevent employees from submitting reviews. The goal is to allow them to submit but restrict who can see them.

Explanation:

The solution that should meet this requirement is updating the support team profile to remove the Bronze record type. This way, the support team users will not be able to create new cases with the Bronze record type, as it will not appear in their record type selection list.

Option A is incorrect because updating the organization-wide defaults to private for Case does not affect the record type availability, but rather the record access level.
Option C is incorrect because creating permission set group for Case that includes Platinum and Diamond record types does not prevent the support team users from creating new cases with the Bronze record type, as they may still have access to it through their profile.
Option D is incorrect because making the record type hidden to support users and updating sharing roles to private does not prevent the support team users from creating new cases with the Bronze record type, as they may still have access to it through their profile.