Platform-App-Builder Practice Test Questions

Explanation:

Why:
To display the total value of all won Opportunities on the Account, use a Roll-Up Summary field on Account with:
Summary Type: Sum (of Opportunity Amount)
Filter Criteria: Opportunities where IsWon = True (or Stage = “Closed Won”)

Why the others are wrong:
A. Count – counts records, not their monetary value.
B. Max – shows the single highest Amount, not the total.
D. Min – shows the single lowest Amount, not the total.

Explanation:

The scenario describes a one-to-many relationship:
One experienced Realtor can mentor many new Realtors
Each new Realtor is assigned to only one experienced Realtor
The relationship is not tightly coupled (i.e., deleting the mentor shouldn’t delete the mentees)
This setup is best modeled using a Lookup relationship, which allows:
Flexibility in record ownership and deletion
Simple linking between two records without enforcing strict dependency

🔍 Why the other options don’t fit:
A. Indirect lookup
❌ Used for linking external objects via matching fields—not applicable here
B. Many-to-many
❌ Would imply new Realtors could have multiple mentors, which contradicts the requirement
C. Master-detail
❌ Too rigid—deleting the master (mentor) would delete the detail (mentee), which isn’t desired

🔗 Reference:
Lookup vs Master-Detail Relationships – Salesforce Help
Data Modeling – Trailhead

Explanation:

Why this works:
Validation rules can 1) block status regressions using functions like PRIORVALUE() (e.g., disallow moving from a later status back to an earlier one) and 2) require fields conditionally (e.g., when Status = “Closed”, ensure Close Reason, Resolution, etc., are filled). You can add clear error messages (the “help text” here) to guide users on what to fix.
Example ideas:
Prevent going backward: create a rule that evaluates the current Status against PRIORVALUE(Status) based on your defined sequence and throws an error if it’s a regression.
Require fields by criteria: AND(ISPICKVAL(Status, "Closed"), ISBLANK(Resolution__c))

Why the others are wrong:
B. Dependent picklist fields — Dependency controls available values, not status progression, and “required” here won’t enforce conditional requirements across the scenario.
C. Approval process — Approvals don’t inherently prevent status regression or make fields required on edit; they route for sign-off.
D. Page layout required fields — Page layout “Required” is always required (not conditional) and doesn’t stop status regressions. It also doesn’t enforce via API/integrations.

Reference:
Salesforce Help — Validation Rules (including using PRIORVALUE() and conditional requirements).

Explanation:

Service agents at Ursa Major Solar need a more condensed case view and the ability to modify associated Contact and Account records directly from the Case page layout on a Lightning record page. The following components meet these requirements:

C. Related Record:
The Related Record component allows users to view and edit related records (e.g., Contact or Account) directly on the Case page without navigating away. By adding this component and configuring it to display the associated Contact and Account, service agents can modify key fields (e.g., phone number, email) inline, meeting the requirement for editing from the Case layout. This also helps condense the view by reducing the need for separate page navigation.
D. Tabs:
The Tabs component enables the app builder to organize sections of the Case page (e.g., Case Details, Contact Info, Account Info) into collapsible or switchable tabs. This condenses the layout by grouping related information, making it easier for agents to focus on essential data without overwhelming the screen, thus supporting the condensed view requirement.

Why not the other options?
A. Path:
The Path component provides guided navigation for record stages (e.g., Case Status progression) but does not facilitate editing related records or condensing the layout beyond its specific guidance role. It’s unrelated to the core requirements.
B. Rich Text:
The Rich Text component allows adding formatted text or images to the page but does not support editing related records or condensing the view. It’s a static display tool, not a functional solution for this scenario.

Implementation Notes:
Add the Related Record component to the Case Lightning page, configure it for Contact and Account with editable fields (e.g., via Field Sets or custom layout), and ensure the component visibility aligns with agent permissions.
Add the Tabs component, create tab sections (e.g., "Case," "Contact," "Account"), and assign relevant components or fields to each tab for a condensed, organized layout.
Test the page in Lightning App Builder to ensure usability on both desktop and mobile.

References:
Salesforce Help: Related Record Component (Details editing related records).
Salesforce Help: Tabs Component (Explains layout organization).
Salesforce Trailhead: Customize a Lightning Page (Covers component usage).

Explanation:

In a master-detail relationship, the detail (child) record does not have its own independent security or sharing model. Its access is entirely controlled by the master (parent) record.

Why C is Correct:
A key characteristic of a master-detail relationship is that the detail record inherits its sharing and ownership settings from the master record. The detail record does not even have a visible OwnerId field in the database. Its access is determined solely by the owner of the parent master record and the sharing settings applied to that master record.

Why A is Incorrect:
There is no "default owner" setting on a parent object that applies to detail records. The owner of the master record is what matters.

Why B is Incorrect:
Detail records in a master-detail relationship do not have an Owner field. This field is removed from the detail object's schema because ownership is inherited.

Why D is Incorrect:
The detail object cannot have its ownership set independently. This is the defining difference between a master-detail relationship and a lookup relationship. The detail object's sharing model is automatically set to "Controlled by Parent" and cannot be changed.

Reference:
Salesforce Help Article: "Master-Detail Relationship Considerations." The documentation explicitly states: "Sharing access to the detail record is determined by the sharing access to the master record. For example, if a user has Read Only access to a master record, the user has Read Only access to the related detail records." and "The detail record doesn’t have its own owner...".

Explanation:

Why:
When a permission set is deployed (Metadata API v40+), the metadata in the deployment replaces the target org’s permission set—absent permissions are treated as false. This is Salesforce’s documented behavior and applies to change sets as well.

Eliminate the others:
A. “Only contain changes related to the change set” — that describes how profiles behave for included components, not permission sets. Permission sets deploy as a whole.
B. False — field-level security in a permission set is included and applied. (Standard object/field permissions are part of permission set metadata.)
C. Merge behavior was pre-API 40.0; current behavior is overwrite.

Tip:
Always review the full permission set diff before deployment—because it overwrites, any missing permissions in the file will be turned off in production.

Explanation:

To ensure that opportunities with a closed date pushed more than 30 days are automatically submitted for approval without relying on sales reps to manually initiate the process, the app builder can use an automated process to submit the record for approval. This can be achieved using tools like Salesforce Flow, Process Builder (though now retired in favor of Flow), or a Time-Based Workflow to automatically trigger the approval process when the specified criteria are met.

Option A: Change the entry criteria on the approval process to criteria are met and lock the record on initial submission.
This is incorrect because simply changing the entry criteria for the approval process does not address the issue of reps forgetting to submit the opportunity for approval. Entry criteria define when a record is eligible for approval, but they do not automate the submission itself. Locking the record on initial submission is also irrelevant to ensuring submission.

Option B: Use a validation rule and an email alert to the manager requesting approval.
This is incorrect because a validation rule would only prevent saving the record if certain conditions are not met, and an email alert to the manager does not automatically submit the record for approval. This approach still relies on manual intervention and does not solve the problem of automating the submission.

Option C: Submit the record for approval from an automated process.
This is correct. An automated process, such as a Salesforce Flow, can be configured to evaluate the opportunity’s closed date (e.g., using a formula to check if it’s more than 30 days from the current date) and automatically submit the record for approval using the Submit for Approval action. This ensures the approval process is initiated without requiring manual action from the reps.

Option D: Give the manager the "API Enabled" permission to permit approval responses by email.
This is incorrect because the "API Enabled" permission allows programmatic access to Salesforce, which is unrelated to automating the submission of records for approval. While managers can respond to approval requests via email, this does not address the issue of reps forgetting to submit the opportunity for approval in the first place.

Implementation Example (Using Salesforce Flow):
Create a Record-Triggered Flow on the Opportunity object.
Set the trigger to run when an Opportunity record is created or updated.
Add a condition to check if the Close Date is more than 30 days from today (e.g., CloseDate > TODAY() + 30).
Use the Submit for Approval action to automatically submit the record to the approval process when the condition is met.

Reference:
Salesforce Documentation: Automate Approval Submission with Flow
Salesforce Help: Approval Process Automation

Explanation:

Changing the data type of custom fields in Salesforce has specific limitations that need to be considered to ensure system integrity and prevent errors:

A. It is not possible to change the data type of a formula field to any data type. Formula fields are calculated based on other field values and cannot be converted into a storage data type because they do not store data themselves.
D. It is not possible to change the data type of a Text Area (Long) field to Text. Text Area (Long) fields support up to 131,072 characters, which far exceeds the 255 character limit of standard Text fields. Converting such a field to a smaller capacity field would potentially lead to data truncation or loss.

For official guidance on data type changes, refer to Salesforce's Custom Field Considerations.

Explanation:

When importing Opportunities (or any other object that can use a currency) into a multi-currency org, it is critical to specify which currency each record should use. The standard CurrencyIsoCode field is used for this purpose.

Option C is correct:
The import file must include a column for the CurrencyIsoCode field. This column should contain the 3-letter ISO currency code (e.g., 'USD', 'EUR', 'GBP') for each record. This tells Salesforce which currency the Amount field on that specific Opportunity is in.

Option B is correct:
Data Loader is the appropriate tool for this import. It provides the flexibility to map the CurrencyIsoCode field from the import file to the corresponding field in Salesforce. The Import Wizard has more limitations and is generally not recommended for complex data models or for objects that require specific field mappings like CurrencyIsoCode.

Option A is incorrect:
You do not modify the actual currency Amount field itself to include the ISO code. The Amount field should contain only the numeric value (e.g., 1000.00). The association of that number to a currency is handled by the separate CurrencyIsoCode field.

Option D is incorrect:
This option is grammatically incorrect and nonsensical ("Use Import the currency ISO Code Column"). It seems to be a malformed repetition of the correct concept from option C.

Option E is incorrect:
The Import Wizard is a simpler, UI-based tool that is best for importing standard objects with simple data mappings. It is less suited for a multi-currency import where you need to ensure precise mapping of the CurrencyIsoCode field, making Data Loader the more reliable and powerful choice.

Reference:
Salesforce Help: "Enable Multiple Currencies" - Overview of the feature.
Salesforce Help: "Considerations for Working with Currency Fields" - Explains how currency data is handled, including the role of the CurrencyIsoCode field.
Salesforce Help: "Import Data with the Data Import Wizard" vs. "Import Data with Data Loader" - The documentation for these tools highlights the advanced capabilities of Data Loader for complex data operations.

Explanation:

Ursa Major Solar needs to model a many-to-many relationship between:
Contact (standard object)
Solar Project (custom object)
In Salesforce, the best practice for modeling many-to-many relationships is to use a junction object. This is a custom object that connects two other objects via two master-detail relationships.

✅ Why Option D is Correct
You create a junction object (e.g., “Project Contact Assignment”).
This junction object has:
A Master-Detail relationship to Contact
A Master-Detail relationship to Solar Project
This setup allows:
One Contact to be linked to many Solar Projects
One Solar Project to be linked to many Contacts
The junction object holds the relationship records and inherits ownership and sharing from both master objects.

❌ Why the Other Options Don’t Work
A. You cannot have two master-detail relationships directly on the Contact and Solar Project objects. That doesn’t create a junction object.
B. Two lookup relationships on a custom object would work, but lookup relationships don’t support roll-up summaries or strict referential integrity like master-detail does.
C. One lookup on each object doesn’t create a junction object and doesn’t support many-to-many relationships.

📘 Reference
You can read more in Salesforce’s official guide to many-to-many relationships