Free Platform-App-Builder Practice Test Questions (2026)

Explanation:

Universal Containers has set the Account object’s Organization-Wide Default (OWD) to Public Read/Write, which means all users—including community users—can view and edit all Account records. That’s a major data exposure issue for external users.
To restrict visibility so that community users only see their own Accounts, Salesforce provides a separate setting:
🔐 External Organization-Wide Defaults (External OWD)
These allow you to set different sharing defaults for external users (e.g., Customer Community, Partner Community).
You can configure the Account External OWD to Private, which ensures:
Community users only see records they own
No access to other users’ Account records
This is the most direct and secure solution to meet the requirement.

❌ Why the other options don’t work:
A. Create an account record type for external accounts
Record types control page layouts and picklist values, not data visibility.
B. Define an owner-based sharing rule for external accounts
Sharing rules grant access, not restrict it. You can’t use them to hide records.
C. Define a permission set for external accounts
Permission sets control object-level access, not record-level visibility.

🔗 References:
Salesforce Help: External Organization-Wide Defaults
Trailhead: Data Security

Explanation:

Universal Containers has implemented duplicate management for Leads, but duplicates are still being created despite the Organization-Wide Default (OWD) for Leads being set to Private. This suggests issues with how duplicate rules or sharing settings are configured. The goal is to prevent duplicate Leads from being created. Below is a concise analysis of each option:

A. Change the lead Matching Rule to Block on create (Correct):
Salesforce Duplicate Rules work with Matching Rules to identify and prevent duplicate records. By default, a Duplicate Rule may be set to Alert (notifying users of potential duplicates) or Allow (permitting duplicates with a warning). Changing the Duplicate Rule to Block on create ensures that if a Lead matches the criteria defined in the associated Matching Rule (e.g., same email or name), the system prevents the record from being created. This directly addresses the issue of duplicate Leads being created.
Steps: Go to Setup > Duplicate Rules > [Lead Duplicate Rule], edit the rule, and set the action to Block for record creation.
Reference: Salesforce Help - Duplicate Rules

B. Change OWD for Leads to Public Read (Incorrect):
Changing the OWD for Leads to Public Read affects record visibility, allowing all users to view all Leads, but it does not prevent the creation of duplicate Leads. OWD settings control access, not data quality or duplicate prevention, making this option irrelevant to the requirement.
Reference: Salesforce Help - Organization-Wide Defaults

C. Change the Lead Duplicate Rule details to Bypass Sharing Rules (Correct):
With the OWD for Leads set to Private, users can only see Leads they own or have access to via sharing rules or role hierarchy. This can prevent Duplicate Rules from identifying duplicates if a user cannot access existing Lead records to compare against. Enabling the Bypass Sharing Rules option in the Duplicate Rule allows the system to check all Lead records (regardless of sharing settings) when evaluating duplicates, ensuring more effective duplicate detection and prevention.
Steps: Go to Setup > Duplicate Rules > [Lead Duplicate Rule], edit the rule, and check the Bypass Sharing Rules option.
Reference: Salesforce Help - Duplicate Rules and Sharing

D. Change the Lead Assignment Rule to check for duplicates (Incorrect):
Lead Assignment Rules determine how Leads are assigned to users or queues based on criteria (e.g., geography or lead source). They do not have built-in functionality to check for or prevent duplicates. While custom logic could be added (e.g., via Flow or Apex), this is not a standard feature of Lead Assignment Rules, making this option incorrect.
Reference: Salesforce Help - Lead Assignment Rules

Recommended Approach:
Modify the Duplicate Rule:
In Setup > Duplicate Rules, edit the Lead Duplicate Rule.
Set the action to Block on record creation to prevent duplicates from being saved.
Bypass Sharing Rules:
In the same Duplicate Rule, enable Bypass Sharing Rules to ensure the system checks all Leads, even those the user cannot access due to the Private OWD.
Verify the Matching Rule (e.g., matching on Email, Name, or Company) is correctly configured to identify duplicates accurately.

Additional Notes:
Ensure the Matching Rule used by the Duplicate Rule is robust (e.g., matches on key fields like Email or Phone) to catch potential duplicates.
Test the Duplicate Rule in a sandbox to confirm it blocks duplicates without impacting valid Lead creation.
If duplicates are still created via API or integrations, ensure those processes respect the Duplicate Rule settings.

References:
Salesforce Trailhead: Duplicate Management
Salesforce Help: Set Up Duplicate Management

Explanation:

The requirement is to allow users to decrease the Estimated Hours field but prevent them from increasing it. This requires a rule that can compare the new value being entered to the old value that was previously saved on the record.

Why D is Correct:
The PRIORVALUE function in a validation rule returns the previous value of a field before the current save operation began. A validation rule can be written to fire (and prevent the save) if the new value is greater than the old value.
Example Validation Rule Formula:
AND(ISCHANGED(Estimated_Hours__c), Estimated_Hours__c > PRIORVALUE(Estimated_Hours__c))
How it works:
This rule checks if the field was changed and if the new value is greater than the old value. If both conditions are true, the validation rule returns "True," triggers an error, and prevents the record from being saved. This successfully blocks increases while allowing decreases and the initial value setting.

Why A is Incorrect:
A formula field is read-only and is used to calculate a value. It cannot be used to enforce a business rule that restricts user input on another field. It cannot prevent a user from saving a value.

Why B is Incorrect:
The PREVGROUPVAL function is used in summary reports and analytics functions to compare the value of a previous grouping to the current one. It is not used in validation rules or for checking the prior value of a field on a single record. The correct function for this context is PRIORVALUE.

Why C is Incorrect:
The ISCHANGED function only detects if a field has been modified. It returns TRUE if the field is different from its original value. However, on its own, it cannot determine if the change was an increase or a decrease. You need to combine it with a function like PRIORVALUE to compare the old and new values to determine the direction of the change.

Reference:
Salesforce Help - "PRIORVALUE" and "Examples of Validation Rules". The PRIORVALUE function is specifically designed for this use case in validation rules, allowing you to compare old and new field values to enforce complex data integrity rules.

Explanation:

Universal Containers wants to roll up sales metrics from the custom object Detailed.Sales__c to Opportunity, but only for records where Status = Active. This is a classic use case for a roll-up summary field, which:
Aggregates values (SUM, COUNT, MIN, MAX) from child records
Can be filtered using criteria (e.g., Status__c = 'Active')
Requires a master-detail relationship between the parent and child objects

✅ Why B is correct:
A master-detail relationship allows the parent (Opportunity) to own the child (Detailed.Sales__c)
You can then create a roll-up summary field on Opportunity that sums sales metrics from child records where Status = Active
This is a declarative solution — no code required

❌ Why the other options don’t work:
A. AppExchange product
Overkill for a simple filtered roll-up — native roll-up summary fields handle this perfectly
C. Lookup relationship
Roll-up summary fields do not work with lookup relationships — only with master-detail
D. Apex code
Apex is powerful but unnecessary here — declarative roll-up summary fields are preferred for maintainability and simplicity

🔗 References:
Salesforce Help: Roll-Up Summary Fields
Trailhead: Data Modeling

Explanation:

Why: To show the highest Offer__c value on each Property__c, you can create a Roll-Up Summary field on Property__c that uses the MAX function on a numeric/currency field from Offer__c. Roll-up summaries are available only when the child (Offer__c) is in a Master-Detail relationship with the parent (Property__c).

Why not the others:
B. Text Area (Long) and C. Multi-select Picklist don’t calculate or summarize values.
D. Lookup Object doesn’t support declarative roll-up summaries (you’d need code or a tool).

Explanation:

Why these work
A. Lead Matching Rule + Duplicate Rule: Salesforce Duplicate Management lets you define a Lead Matching Rule (e.g., match on Email) and a Duplicate Rule that blocks new duplicates during import or UI/API creates.
B. Import Wizard with matching: The Data Import Wizard supports deduping for Leads—choose a matching option (e.g., Email or Salesforce ID) and set it to prevent creating duplicates and/or update existing where appropriate. Perfect for a ~400-record upload.

Why not the others
C. Data Loader update by Email: Data Loader’s Update requires record IDs or an External ID field; Email isn’t an external ID by default, so it won’t reliably match existing Leads.
D. “Duplicate Matching” / “Lead-to_Lead scenario”: Those aren’t real setup options. Use Matching Rules and Duplicate Rules instead.

Explanation:

This scenario tests the understanding of implicit sharing and record access inheritance in Salesforce's sharing model.

Why A is Correct:
In Salesforce, when a user is granted Read access to an Opportunity (a child object), they automatically gain Read access to the parent Account (the parent object) through a mechanism called implicit sharing. This is true even if the sharing model for the Account is Private and the user is not in the Account's territory. Manual sharing of the Opportunity with Sales Rep B grants them Read access to that specific Opportunity. This access implicitly grants them Read access to the related Account, explaining why they can see it.

Why B is Incorrect:
The scenario does not provide any information suggesting that Sales Rep B was added to the Account team. This is an assumption not supported by the facts given.

Why C is Incorrect:
Sharing Sets are a feature used with Customer Portal and High Volume Portal users to grant them access to records based on a relationship between their user account and a field on the record. They are not applicable to standard internal Salesforce users like Sales Reps.

Why D is Incorrect:
The scenario explicitly states that the Account was NOT in Sales Rep B's territory and does not mention the Account being manually shared. The question asks for the reason based on the information given, and manual sharing of the Account is not indicated.

Key Concept:
The principle at work here is that access to a child record can grant implicit read-only access to its parent record. This is a fundamental behavior of Salesforce's security model designed to ensure users can see the context of records they have access to.

Reference:
Salesforce Help - "How Sharing Access Is Calculated". The documentation explains that "Users who have access to a child record (like an Opportunity, Case, or Contact) generally need access to the parent record (like an Account). To ensure users have the access they need, Salesforce automatically grants Read access to the parent record if the user has access to the child." This is known as implicit sharing.

Explanation:

Why this is correct:
ROI for marketing spend is tracked in Salesforce via Campaigns. Create a parent campaign for the advertising buy and child campaigns for each channel/ad/creative. Salesforce rolls up child metrics to the parent via Campaign Hierarchy “statistics” fields, and you can run the built-in Campaign ROI Analysis Report to calculate ROI using costs and influenced/won opportunity amounts. This works fine with a private sharing model; no need to change org-wide defaults—just share the specific Campaigns as required.

Why the others are wrong:
A. Account Hierarchies and Roll-Up Summary fields — Account roll-ups don’t measure marketing ROI; ROI is a Campaign concept with Campaign-to-Opportunity attribution. Salesforce
B. Opportunities pipeline report — Shows stage/amount forecasts, not campaign spend vs. return.
C. Change to a public security model — Unnecessary; Campaign ROI can be measured without altering OWDs.

Reference:
Salesforce docs on Campaign Hierarchies (roll-up stats) and the Campaign ROI Analysis Report.

Explanation:

In Salesforce, when creating new automation on an object, the recommended best practice is to consolidate record-triggered automation into one Flow per object (or per trigger event, such as before/after save). This approach, often called the "One Per Object" design pattern, minimizes the number of triggers firing on the object, improves performance by reducing context switches and governor limit consumption, simplifies debugging and maintenance, and ensures predictable order of execution using features like Flow Trigger Order. It builds on the legacy Process Builder model and aligns with modern Flow-only automation strategies.
This practice helps avoid issues like unintended record updates from multiple overlapping automations, excessive CPU time, or challenges in tracing logic across disparate tools. For complex orgs, use subflows or decision elements within the single Flow to handle branching logic, rather than creating multiple independent Flows.

Why not the other options?
A. One Workflow rule per object:
Workflow Rules are a legacy automation tool (retired in Winter '24) that only support field updates, tasks, emails, and outbound messages. They cannot handle complex logic like Flows and are not recommended for new automation. Consolidating to one Workflow Rule per object was never a primary best practice, as multiple could be used but often led to order-of-execution problems.
B. One invokable process per object:
Invocable processes (autolaunched Flows) are designed for reusable sub-processes called from other Flows or Apex, not for primary record-triggered automation on an object. Limiting to one per object isn't a standard practice and doesn't address core record-change scenarios.
C. One record change process per object:
This phrasing refers to legacy Process Builder terminology (a "record-change process" is a Process Builder process triggered by record changes). While the one-per-object pattern originated here for performance reasons, Process Builder is retired (end-of-life in 2025). New automation must use Flows, making this outdated.

References:
Salesforce Architects: Record-Triggered Automation
Salesforce Help: Best Practices for Designing Processes (Note: Applies to Flow design patterns post-Process Builder retirement)

Explanation:

Why B is Correct:
The requirement is to improve the process to create Opportunity records related to an Account. A Quick Action placed on the Account page layout is the perfect solution. This allows a user to be viewing an Account and instantly create a new, related Opportunity without navigating away. The key benefit is that this action can be pre-configured to:
Pre-populate fields from the Account: The action can automatically set the Opportunity's AccountId and map any other relevant fields from the Account (e.g., Account Number, Billing Address) to the new Opportunity record using pre-defined field values.
Require input from the user: The action can present a compact form where the user must fill in the required fields that cannot be pre-populated (e.g., Close Date, Stage, Amount).

Why A is Incorrect:
Process Builder is an automation tool, not a user interface tool. A Process triggered on Opportunity update fires after a record is saved. It cannot help with the initial creation process or provide a UI for user input during creation.
Why C is Incorrect:
A Quick Action on the Opportunity object itself would be useful for updating existing Opportunities, but it is not the most efficient way to create one from a specific Account. The user would first have to navigate to the Opportunities tab, click "New," and then manually find and select the Account. This adds extra steps compared to starting from the Account record.
Why D is Incorrect:
Like option A, this uses an automation tool (Process Builder) incorrectly. A Process triggered from an Account update would fire when the Account is edited, not when a new Opportunity is being created. It cannot interact with the user to gather required input for the new Opportunity.

Reference:
Salesforce Help Article: "Create Object-Specific Actions." Quick Actions are designed specifically to streamline common tasks, like creating related records, directly from the parent record's page, making them a cornerstone of efficient UI design for App Builders.