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.

Explanation:

To create an approval process in Salesforce for Cloud Kicks (CK) that ensures department members can approve all overnight shipments on the custom object Shipments__c, the app builder needs to route the approval request to a group of users who can collectively handle the approvals. Let’s analyze why Public group is the best choice and why the other options are less suitable:

A. Hierarchy field:
A hierarchy field (e.g., a user lookup field like Manager on the User object) is used to route approvals to a specific user in a reporting hierarchy, such as a user’s manager. While this is useful for approvals requiring a single user in a chain of command, it’s not ideal for routing approvals to multiple department members who share responsibility for approving overnight shipments. Using a hierarchy field would limit the approval to one individual at a time, which doesn’t align with the requirement for department-wide approval.
B. Role:
Roles in Salesforce define a user’s position in the organization’s hierarchy and are primarily used for data access via the role hierarchy in sharing rules. While approvals can be routed to users in a specific role, this approach is restrictive because it includes only users assigned to that exact role, not necessarily all department members who might span multiple roles or teams. For example, department members might have different roles (e.g., Shipping Coordinator, Shipping Manager), making it impractical to route approvals to a single role.
C. Public group:
This is the correct choice because public groups in Salesforce allow you to group multiple users, regardless of their roles or profiles, into a single entity for purposes like sharing rules, queue membership, or approval processes. By creating a public group that includes all department members responsible for approving overnight shipments (e.g., a group named “Shipping Department Approvers”), the app builder can route the approval request to this group. All members of the public group will receive the approval request, and any one of them can approve it, meeting the requirement for department-wide approval. Public groups are flexible and can include users, roles, or even other groups, making them ideal for this scenario.
D. Queue:
Queues in Salesforce are used to manage ownership of records (e.g., leads, cases, or custom objects) and distribute work among a group of users. While queues can include multiple users, they are designed for assigning records to a team for processing, not for routing approval requests. Approval processes cannot directly route to a queue, as queues are not valid targets for approval assignments in Salesforce. Instead, queues are better suited for scenarios where records need to be assigned for further action, not for approving specific actions like shipments.

Why Public Group is Ideal:
Public groups allow the app builder to include all relevant department members, regardless of their role or hierarchy, ensuring flexibility in who can approve overnight shipments.
In the approval process setup, the app builder can configure the approval step to route to the public group, allowing any member of the group to act on the approval request.
Public groups are reusable across other Salesforce features (e.g., sharing rules, manual sharing), making them a scalable solution for managing department-level permissions.

How to Implement:
Create a public group in Salesforce (Setup > Public Groups) named something like “Shipping Department Approvers” and add all department members who should approve overnight shipments.
In the approval process for Shipments__c (Setup > Create > Approval Processes), create an approval step and select “Public Group” as the approver type, choosing the “Shipping Department Approvers” group.
Configure the approval step to allow any member of the group to approve (e.g., “Approve or reject based on the FIRST response” or require unanimous approval, depending on requirements).

Reference:
Salesforce Help: Set Up an Approval Process
Explains how to configure approval processes, including routing approvals to public groups.
Salesforce Help: Create Public Groups
Describes how public groups can be used to manage users for approvals and other purposes.
Salesforce Trailhead: Approval Processes
Covers the basics of setting up approval processes, including assigning approvers via public groups.

Explanation:

To compare case counts by two dimensions—Status (New/In Progress/Closed) and Priority (Critical/High/Medium/Low)—build a Matrix report on Cases and apply grouping: one field on rows (e.g., Status) and the other on columns (e.g., Priority). Among the choices, Grouping is the feature that enables this cross-tab layout.

Why not the others:
B. Bucket Columns — Used to recategorize values; you don’t need to bucket standard Status/Priority values.
C. Custom Report Type — Not required; Cases already have standard report types supporting grouping.
D. Filters — Narrow the dataset but don’t create the cross-tab comparison.