Explanation:

 Feed Tracking is the correct Chatter feature for displaying field value changes prominently in the Chatter feed for a record. When Feed Tracking is enabled on the House__c custom object and specific fields, such as Asking_Price__c and Real_Estate_Agent__c, are selected for tracking, Salesforce automatically posts updates to the record's Chatter feed when those fields are changed. These updates show the old and new values, allowing users following the record to quickly identify important changes without requiring custom code.

❌ Why Other Options Are Incorrect

A. Topics – This is incorrect because Topics are used to categorize and group records or content by keywords or subjects, such as "Luxury Homes" or "Beachfront." Topics help users discover related records and discussions, but they do not track field value changes or automatically display those changes in the Chatter feed.

C. Pin Field – This is incorrect because there is no standard Chatter feature called "Pin Field." Although users can pin certain posts or comments to highlight important discussions, pinning does not track or display changes to field values on a record.

D. Publisher Actions – This is incorrect because Publisher Actions allow users to perform actions such as creating records, logging calls, or sending emails from the Chatter publisher. They are user-initiated actions and do not automatically track changes to fields or publish field updates to the Chatter feed.

📚 References:

Salesforce Help – Feed Tracking – Explains that Feed Tracking allows administrators to select fields on standard and custom objects for tracking and that changes to tracked fields can be posted to the record's Chatter feed.

Explanation:

An after-save record-triggered flow with a Scheduled Path is the correct design because it allows the flow to schedule an action exactly  7 days after the record is updated, such as when the Status changes to "On Hold." The flow triggers when the Status changes, and the Scheduled Path runs after the specified time offset. This ensures the reminder is sent 7 days after each individual project is placed on hold, independent of other projects.

❌ Why Other Options Are Incorrect

A. A platform event-triggered flow that sends the reminder email 7 days after a platform event message is received – This is incorrect because platform event-triggered flows respond to platform events rather than directly to record changes on the Project__c object. The App Builder would need additional automation to publish the event when the Status changes. This adds unnecessary complexity and does not directly provide the required record-based scheduled action.

B. A schedule-triggered flow on Project__c that runs once each day and sends a reminder email to each record that has been in On Hold status for 7 days – This is incorrect because schedule-triggered flows execute according to a fixed schedule and evaluate multiple records at the scheduled time. Although this approach could identify projects that have been on hold for 7 days, it is less precise than scheduling an action from the individual record update that caused the Status change.

D. An after-save record-triggered flow on Project__c, triggered when Status is changed to On Hold, with a Scheduled Path set to run 7 days after the record's CreatedDate – This is incorrect because the requirement is to send the reminder 7 days after the Status changes to On Hold, not 7 days after the record was created. The Scheduled Path must use the appropriate record update time reference rather than CreatedDate to meet the requirement.

📚 References:

Salesforce Help – Scheduled Paths in Flows – Explains how Scheduled Paths allow record-triggered flows to execute actions at a future date and time based on a configured time offset from a record date or time field.

Explanation:

A  roll-up summary field on the Account object is the correct solution because it can aggregate related Opportunity records that meet specific filter criteria. The App Builder can configure the field to count Opportunities where  StageName = 'Closed Won' and the  Close Date is within the last year. The resulting count can be displayed directly on the Account detail page, providing the required summary of recently won Opportunities.

❌ Why Other Options Are Incorrect

A. Activity timeline – This is incorrect because the Activity Timeline displays a chronological list of activities such as tasks, events, and emails associated with a record. It does not aggregate related Opportunity records or count them based on fields such as StageName and Close Date. It is designed for tracking interactions, not summarizing related business data.

B. Formula field – This is incorrect because formula fields cannot aggregate data from child records. They can reference fields on the current record and related parent records, but they cannot count or filter child Opportunities. Therefore, a formula field cannot calculate the number of Closed Won Opportunities within a specified date range.

C. Validation rule – This is incorrect because validation rules are used to enforce data quality by preventing records from being saved when specified conditions are met. They do not display calculated values on page layouts and cannot aggregate related Opportunity records. A validation rule is therefore unrelated to the requirement to display an Opportunity count on the Account.

📚 References:

Salesforce Help – Roll-Up Summary Fields – Explains that roll-up summary fields can calculate values from related child records using functions such as COUNT, SUM, MIN, MAX, and AVG, with filter criteria available to limit the records included in the calculation.

Explanation:

To move from a public sharing model to a more restrictive model while ensuring the Sales team continues to access all Account records with the Sales record type, the App Builder must take two key actions. First, update the  Organization-Wide Defaults (OWD) for Accounts to a more restrictive setting, such as  Private or  Public Read Only, depending on the required access level. Second, create a  criteria-based sharing rule on the Account object that grants the Sales team access to records where the Record Type equals "Sales." This preserves the required access while restricting access for other users.

❌ Why Other Options Are Incorrect

C. Update the Sales profile – This is incorrect because Profiles control  object-level permissions such as Create, Read, Edit, and Delete, along with field-level security. They do not provide record-level access based on record type or criteria. The Sales team still requires OWD, sharing rules, role hierarchy, or other record-level access mechanisms to access the appropriate Account records.

D. Create an owner-based sharing rule – This is incorrect because owner-based sharing rules grant access according to the  record owner, such as records owned by users in a particular role or group. The requirement is based on the Account's  Record Type, not ownership. Therefore, a criteria-based sharing rule is the appropriate choice.

📚 References:

Salesforce Help – Organization-Wide Defaults – Explains that OWD settings establish the baseline level of record access and can be made more restrictive to support a private sharing model.

Explanation:

The correct approach is to create a  sharing rule on the Application object that grants Read/Write access to recruiters. Because the OWD for Internships, the master object, is Private and Applications are child records in a master-detail relationship, child records inherit the sharing settings of the parent master record. However, the requirement is specifically to allow recruiters to  Edit Applications, not necessarily the Internship records. A sharing rule on the Application object can provide the required access to the Application records while avoiding unnecessary access to sensitive Internship data.

❌ Why Other Options Are Incorrect

A. Add a sharing rule that grants the users Read/Write access to Internship records – This is incorrect because granting Read/Write access to Internship records would be overly permissive and expose sensitive Internship information that recruiters do not need. The requirement is to provide access to Application records, not the parent Internship records themselves.

B. Create a queue for the web applications and assign access to users who will edit the records – This is incorrect because queues are primarily used for record ownership and assignment. A queue does not independently grant users Edit permissions. Recruiters would still require the appropriate object-level permissions and record access to edit Application records.

C. Set the OWD on the Applications object to Read/Write – This is incorrect because Applications are in a master-detail relationship with Internships. Detail records inherit the sharing settings of the master record and do not have independent OWD settings. Therefore, the Applications object cannot have its own separate OWD configuration.

📚 References:

* Salesforce Help – Master-Detail Relationships and Security – Explains that detail records inherit the sharing and security settings of their master records and do not have independent sharing settings.