Salesforce Certified Platform App Builder Free Sample Questions

A record-triggered Flow running after save is the modern, recommended solution. It can handle bulk operations efficiently by querying for all sibling records (Loan Applications under the same Account) and updating them in a single DML operation. This approach avoids the recursion risks inherent in Process Builder for this scenario, as Process Builder can re-trigger itself on the related record updates. Workflow rules cannot update child records, and an approval process is not appropriate for this automatic status change.

A master-detail relationship is required for two key reasons: 1) It allows the creation of a roll-up summary field on the master (Patient) to count the detail (Medical Encounter) records. 2) By default, master records in a master-detail relationship cannot be deleted if they have child records, which fulfills the undeletable requirement. A required lookup relationship would not allow for a roll-up summary field.

Component visibility filters in the Lightning App Builder allow for multiple conditions. To meet the requirement that BOTH conditions must be true, the App Builder must add two separate filter criteria and set the filter logic to '1 AND 2'. Using 'OR' logic would incorrectly display the component if only one of the conditions were met.

When Flows are deployed via change sets, they are deployed as the most recent version but in an inactive state by default. This is a safety measure to prevent partially configured or incorrect automation from running in the target environment. A common post-deployment step is to manually navigate to the Flow in the target org's setup and activate it.

Roll-Up Summary fields can only aggregate data from a single child object. Therefore, to combine totals from two different child objects (Donation and Pledge), the correct declarative approach is to create two separate Roll-Up Summary fields on the parent Account object. The Pledge roll-up would use filter criteria Status = 'Committed'. Then, a simple Formula field on the Account can be created to add the values of these two roll-up fields together.

Flow is the most efficient tool because it can handle all the required logic in a single, consolidated process. A record-triggered Flow can create the new Student record and then use a Decision element to route the logic based on the 'Program' field. Each path in the decision can then have a 'Create Records' element for the Task, assigning it to the specific coordinator for that program. This avoids having multiple Process Builders or a combination of tools, which is less maintainable.

While simply marking a field as an External ID doesn't change its data type, if you also intend for it to be a unique identifier (which is common practice), you must ensure all existing records have unique values in that field. Salesforce will prevent you from marking a field as both 'External ID' and 'Unique' if duplicate values exist. The other options are incorrect; you can change a text field to be an external ID, and references in reports or automation do not need to be removed first.

A criteria-based sharing rule can be configured to share records where the Project equals Project X with the consultant. This is a scalable and maintainable solution.

If the Project Task object's sharing is controlled by its parent Project, manually sharing the Project X record can grant the consultant access to all its child tasks. This is suitable for ad-hoc access needs.

Change sets deploy metadata, which includes the definition of the permission set and the user assignments if the users are included. However, it is best practice and often necessary to manage user assignments in the target org. The deployment itself only moves the permission set definition; the assignment to specific users (which is data) is typically handled post-deployment.

This formula correctly checks for the fiscal quarter logic. Since the fiscal year starts in February, we subtract 1 from the month before calculating the quarter. The formula checks if the stage is correct, and then compares the fiscal quarter of the CloseDate with the current fiscal quarter, along with the year, to prevent it from being moved to a prior fiscal quarter. The other options either check for a past date incorrectly or don't account for the custom fiscal year.