Explanation:

A  criteria-based sharing rule on the Projects custom object is the correct solution because it can automatically grant view access to project records based on a field value, specifically the  Department field. By creating a Public Group for each department, such as "Marketing Department" and "Sales Department," and adding the appropriate employees to each group, the sharing rule can grant access to project records where the Department value matches the applicable criteria. When an employee changes departments, updating their Public Group membership automatically changes their access to the corresponding project records.

❌ Why Other Options Are Incorrect

B. Create a criteria-based sharing rule using the Project's department that grants access to users through Permission Sets
– This is incorrect because sharing rules grant record-level access to supported groups or hierarchy-based targets, not directly to Permission Sets. Permission Sets are used primarily to grant object, field, and other permissions. They are not valid shared-with targets for criteria-based sharing rules.

C. Create a criteria-based sharing rule using the Project's department that grants access to users through Profiles
– This is incorrect because sharing rules do not grant record access directly to Profiles. Profiles control permissions such as object access and field-level security, while sharing rules extend record-level access. A Public Group, role-based target, or another supported sharing target must be used instead.

D. Create a criteria-based sharing rule using the Project's department that grants access to users through Account Teams
– This is incorrect because Account Teams are designed to provide access to Account records and related collaboration. They are not a general sharing-rule target for custom Project records. Using Account Teams would therefore not provide the required department-based sharing of Project records.

📚 References:

Salesforce Help – Criteria-Based Sharing Rules – Explains how sharing rules can grant record-level access based on record criteria and use supported sharing targets such as Public Groups, Roles, Roles and Subordinates, or Territories.

Explanation:

This validation rule correctly enforces the requirement by checking two conditions: first, that the  Locked__c field is checked (TRUE), and second, that the current user's Profile Name is not  "System Administrator". If both conditions are met, the validation rule fires and prevents the user from saving modifications to the Account record. This ensures that only System Administrators can edit locked Account records, while all other users are blocked regardless of their role or other permissions.

❌ Why Other Options Are Incorrect

A. AND(Locked__c = TRUE, $UserRole.Name != "System Administrator") – This is incorrect because it uses  $UserRole.Name instead of  $Profile.Name. A user's role is different from their profile. A user could have the System Administrator profile while being assigned a different role, or could have a different profile while holding a role with a similar name. Because the requirement specifically identifies the System Administrator  profile, the validation rule must check the user's profile rather than their role.

C. AND(Locked__c = TRUE, Stage = "Closed Won", $UserRole.Name != "System Administrator") – This is incorrect for multiple reasons. First, it adds an unnecessary condition,  Stage = "Closed Won", that is not part of the requirement. This would cause the rule to fire only for Accounts meeting that additional condition. Second, it incorrectly uses  $UserRole.Name instead of  $Profile.Name. The rule should evaluate whether the current user's profile is System Administrator.

D. AND(Locked__c = TRUE, $Profile.Name = "System Administrator") – This is incorrect because the validation rule would fire when the user   is a System Administrator, which is the opposite of the required behavior. The rule must block non-System Administrators from editing locked Accounts. This condition would instead prevent System Administrators from making changes to locked records.

📚 References:

* Salesforce Help – Validation Rules – Explains how validation rules enforce data requirements and can use global variables such as `$Profile` and `$UserRole` to reference information about the current user.

Explanation:

A  custom link with a dynamic URL on the Account object is the correct solution because it allows the App Builder to create a link on the Account record page that dynamically opens a report of the current Assets associated with that Account. By using the Account ID as a filter parameter, such as `?pv0=` or the `{!Account.Id}` merge field, the link can open a preconfigured Asset report filtered for the current Account. This provides Account owners with one-click access to the relevant report directly from the Account record page.

❌ Why Other Options Are Incorrect

A. Dashboard with Account Filter – This is incorrect because a dashboard provides a visual summary of report data rather than direct access to the underlying report. Dashboard filters generally require user interaction and do not automatically apply the Account currently being viewed as the filter context. Therefore, a dashboard does not provide the same direct, one-click access to an Account-specific Asset report.

C. Scheduled Reports – This is incorrect because scheduled reports are designed to deliver report results on a recurring schedule, typically through email. They do not provide on-demand access from the Account record page and cannot automatically use the Account currently being viewed as the dynamic filter context.

D. Custom Report Type – This is incorrect because a Custom Report Type defines the objects and relationships available for reporting, such as Assets and Accounts. It does not provide a direct link from an Account record page or dynamically filter the report based on the current Account. It is a foundational reporting configuration rather than the user-facing access mechanism required here.

📚 References:

Salesforce Help – Custom Links – Explains how custom links can use merge fields such as `{!Account.Id}` to create context-sensitive URLs that provide access to reports, web pages, and other Salesforce resources.

Explanation:

A  record-triggered flow on the Opportunity object, configured with the  Actions and Related Records optimization, is the correct solution because it runs after the record is saved and can perform actions involving related records. This allows the flow to update the related Account record and send an email notification to the Account owner. The Actions and Related Records configuration supports actions such as creating, updating, or deleting records and sending notifications. This makes it appropriate for requirements involving both cross-object updates and email notifications.

❌ Why Other Options Are Incorrect

A. A record-triggered flow configured for Fast Field Updates – This is incorrect because Fast Field Updates are optimized for  before-save scenarios in which fields on the triggering record are updated. This configuration is intended for fast, same-record field updates and does not provide the full set of actions needed for updating related records or sending email notifications. The requirement requires an after-save flow with Actions and Related Records.

B. An autolaunched flow invoked by a validation rule – This is incorrect because  validation rules cannot invoke flows. Validation rules are designed to validate data and display error messages when specified conditions are met. They do not provide a mechanism for launching an autolaunched flow. Therefore, this option cannot satisfy the requirement to update the related Account and send an email notification.

C. A Screen Flow deployed through an AgentExchange package – This is incorrect because Screen Flows require  user interaction and are designed for guided processes rather than background automation triggered automatically by a record change. In addition, "AgentExchange" is not a standard Salesforce platform term. The correct Salesforce marketplace is  AppExchange. This option therefore does not fit the automated requirement.

📚 References:

Salesforce Help – Record-Triggered Flow Optimizations – Explains the differences between Fast Field Updates and Actions and Related Records, including when after-save flows can perform actions on related records and invoke additional automation.

Explanation:

A  custom detail page link on the Contract object is the correct solution because it allows the App Builder to add a direct, easily accessible link to the pricing guidelines document, whether stored as a file, URL, or in Salesforce Content, on the Contract record's detail page. Users viewing a Contract related to an Account can click the link directly from the Contract page to access the document without navigating to another record. Custom detail page links provide a simple declarative method for quick access to external resources or documents.

❌ Why Other Options Are Incorrect

B. Quick Action on the Account object – This is incorrect because a Quick Action on the Account object would be available from the Account record, not directly from the Contract record. Although users could access the action through the related Account, the requirement is to provide quick access while viewing the Contract. Therefore, an Account Quick Action does not meet the requirement as directly as a Contract-level link.

C. A custom detail page link on the Account object – This is incorrect because the link would appear on the Account record page rather than the Contract record page. Users would have to navigate from the Contract to the related Account to access the pricing guidelines, adding an unnecessary step and failing to provide direct access from the Contract page.

D. Quick Action on the Contracts object – This is incorrect because Quick Actions are primarily designed for actions such as creating or updating records, logging calls, or sending emails. Although some actions can launch URLs, a custom detail page link is the more appropriate declarative solution for providing simple, static access to a document or external resource from a Contract record.

📚 References:

Salesforce Help – Custom Links – Explains that custom links can be added to object page layouts to provide users with quick access to URLs, external resources, and other relevant content directly from record pages.