Free Platform-App-Builder Practice Test Questions 2026

Explanation:

The business requirement is to automatically start an approval process when an Opportunity reaches a certain stage ("Secure Commitment"), eliminating the need for manual submission. This is a classic automation scenario.

Why B is Correct (Process Builder):
Process Builder is a powerful, declarative automation tool that can be triggered when a record is created or edited. A process can be built on the Opportunity object to fire when the Stage is changed to "Secure Commitment." Its immediate action can be to Submit for Approval, launching the predefined approval process. This is a standard, out-of-the-box action in Process Builder.
Why C is Correct (Apex):
Apex code (a trigger) can be written on the Opportunity object. The trigger would detect when the Stage field is updated to "Secure Commitment" and then use the Approval. ProcessSubmitRequest method to programmatically submit the record to its approval process. This is a fully customizable and powerful code-based solution.
Why E is Correct (Flow):
A record-triggered flow is the modern successor to Process Builder for automation. It can be configured to run when an Opportunity is created or updated and its stage equals "Secure Commitment." Within the flow, you can use the Submit for Approval element to achieve the exact same result as Process Builder. Salesforce is increasingly directing users to use Flow for this type of automation.

Why A is Incorrect (Workflow):
Workflow Rules are a legacy automation tool. Their available actions are limited to:
New Task
Email Alert
Field Update
Outbound Message
Workflow Rules cannot submit a record for approval. This critical functionality was added in the more modern tools like Process Builder and Flow.

Why D is Incorrect (Chatter Action):
A Chatter Action is a button or link in the Chatter publisher that lets users perform quick actions, like posting a message or updating a record. It is a manual user interface component, not an automation tool. It does not help automatically trigger an approval process.

Summary:
The three features capable of automatically submitting a record for approval based on a criteria change are the modern automation tools: Process Builder, Apex, and Flow.

Reference:
Salesforce Help:
"Start an Approval Process with Process Builder"
"Use Apex to Submit Records for Approval"
"Submit for Approval Element in Flow"

Explanation:

Sales reps need a fast and efficient way to add new Contacts on mobile, with the ability to fill in additional details later. This calls for a solution that’s:
Quick to access
Streamlined for minimal input
Mobile-optimized
✅ Global Actions are perfect for this:
They allow users to create records from anywhere in the Salesforce mobile app.
You can design the action layout to include only essential fields, making it fast to complete.
Reps can later edit the Contact record to add more details.
Global actions appear in the publisher layout, making them easy to access on mobile.

❌ Why the other options don’t work:
A. Customize the mobile menu
This only changes navigation order — it doesn’t streamline record creation.
C. Add a compact layout
Compact layouts affect record display, not how records are created.
D. Use Path and set pre-defined values
Path is used for guiding users through stages (like Lead or Opportunity), not for quick record creation.

🔗 References:
Salesforce Help: Global Actions
Trailhead: Customize the Salesforce Mobile App

Explanation:

Roll-up Summary Field: A roll-up summary field is designed to aggregate data from a set of related detail records and display the result on the master record. In this case, you can create a roll-up summary field on the Account object (the master) to summarize data from the related Opportunity records (the details).
MIN Function: The MIN function is used to find the earliest date in a set of date fields. By applying MIN to the Opportunity Close Date, the roll-up summary will return the date of the earliest successful purchase.
Filter IsWon = TRUE: This filter is crucial. It ensures that only Won opportunities are included in the calculation, so the roll-up summary only considers actual purchases and ignores opportunities that were lost or are still in progress.

Why other options are incorrect
B. Create a new date field called First Order Date, create a new Workflow to set the date, and roll up the value with a filter where IsWon = TRUE: A workflow rule cannot perform a roll-up summary. This approach is incorrect because it mixes two different functionalities in an unworkable way.
C. Create a new roll-up summary field called First Order Date, using Type SUM on Opportunity Close Date: You cannot use SUM on a date field. The SUM type is used for number fields, not dates.
D. Create a new date field called First Order Date, then create a roll-up summary to update the field using Type MIN: This describes a two-step process that is unnecessary. The roll-up summary field itself is the field that will store the date. You don't need to create a separate date field and then have the roll-up summary update it. The roll-up summary field is a dedicated field type.

Explanation:

Why: In Lightning, Chatter Streams let users build a custom feed from specific records (e.g., key Accounts and Opportunities), people, or groups. The rep can add those key records to a stream and view only posts from them—perfect for filtering a noisy feed.

Why not the others:
A. Chatter group: Groups organize people/topics, not posts from specific records.
B. Chatter bookmarks: Save individual posts; they don’t create a filtered feed.
D. Chatter notification: Alerts you, but doesn’t provide a dedicated filtered feed view.

Explanation:

The requirement is to:
Add a custom Sync button to the Account record page
Trigger a Lightning Web Component (LWC) that connects to an external system
Ensure the button is conditionally visible only when the Status field = "Ready to Sync"

✅ Why Dynamic Action is the right choice:
Dynamic Actions allow you to conditionally show or hide buttons on Lightning record pages based on field values, user profiles, or record data.
You can configure the Sync button to appear only when Status = "Ready to Sync".
The button can be tied to a custom Lightning Web Component via a Lightning Action or Quick Action.
This is a declarative, flexible, and mobile-friendly solution.

❌ Why the other options don’t work:
A. Formula field
Formula fields are read-only and cannot trigger actions or components.
C. AppExchange product
Overkill for this use case — no need to install a third-party app for a simple conditional button.
D. Custom link
Custom links are static and cannot be conditionally displayed based on field values. Also, they don’t integrate cleanly with LWCs.

🔗 References:
Salesforce Help: Dynamic Actions on Record Pages
Trailhead: Lightning App Builder

Explanation:

To show a related list on a parent object (in this case, Asset), you must have a relationship field on the child object (Asset Inventory) that points to the parent.

Create a lookup relationship on Asset Inventory to Asset:
Creating a lookup relationship field on the Asset Inventory object that references the Asset object is the correct way to establish this parent-child connection.
Add the Asset Inventory related list to the Asset page layout:
Once the relationship is established, Salesforce will automatically make the child object (Asset Inventory) available to be added as a related list on the parent's (Asset) page layout.

Why other options are incorrect
A. Create a roll-up on Asset. Add the Asset Inventory related list to the Asset page layout:
A roll-up summary is used to aggregate data from child records onto a parent record; it does not create a related list. The related list is a result of the relationship itself, not a roll-up summary.
B. Create a junction object to relate Asset Inventory and Asset. Add the Asset Inventory related list to the Asset page layout:
A junction object is used to create a many-to-many relationship between two objects. While it would create related lists, it's an unnecessary and overly complex solution for a simple one-to-many relationship, where Asset Inventory is the child of Asset.
D. Create a master-detail relationship on Asset-to-Asset Inventory Add the Asset Inventory related list to the Asset page layout:
This is incorrect. The master-detail relationship field must be created on the child object (Asset Inventory) and reference the parent object (Asset). The option incorrectly states the relationship direction.

Explanation:

Changing a field's data type is a significant modification that can have unintended consequences, especially when dealing with data limits and history tracking.

Why B is Correct:
Converting a field from one data type to another can often result in data truncation or loss. A Text Area (Long) field can hold up to 131,072 characters. A Rich Text field can only hold up to 32,768 characters in most contexts (and is often effectively limited to much less when stored in HTML format). If any existing records have text longer than the new Rich Text field's capacity, that data will be truncated and lost during the conversion process. The team must analyze their existing data to ensure no values exceed the new limit before proceeding.
Why C is Correct:
Field History Tracking has a known limitation: it only captures the first 255 characters of any changed field value for the history trail. This is true regardless of the original field's data type (Text, Text Area, Rich Text) or length. If the business requirement for tracking changes relies on the full content of these potentially long descriptions, this limitation makes Field History Tracking an inadequate solution. The team may need to consider a different auditing strategy, such as using a custom object or an external logging system.

Why A is Incorrect:
This statement is false. In Salesforce reports, Rich Text fields are truncated and do not display their full content. You typically see a preview or a shortened version. To see the full value, a user must click into the individual record. This is an important UI consideration when choosing to use Rich Text fields.
Why D is Incorrect:
While the Field History Tracking data is accessible via the API, the specific term "Audit Trail" in Salesforce typically refers to the Setup Audit Trail, which logs changes to your org's configuration, not changes to individual record data. This option is a distractor and does not address the core considerations of data loss and history tracking character limits related to the field type change.

Reference:
Salesforce Help:
"Convert Field Type Considerations": Explicitly warns that converting fields can lead to data loss.
"Field History Tracking Considerations": States "Field history tracking retains the previous 255 characters for any changed field whose length is greater than 255 characters."

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:

The scenario describes a master-detail relationship between the custom Service Plan object (the detail or child) and the standard Contact object (the master or parent). The reason a master-detail relationship is likely in use is the requirement that a Service Plan be "associated to one and only one contact," which is a defining characteristic of this type of relationship.
By default, the Allow reparenting option is disabled when a master-detail relationship is created. This means that once a child record (the Service Plan) is created and assigned to a parent record (the Contact), the relationship field becomes read-only and cannot be changed. To allow the parent record to be changed, an App Builder must explicitly enable the Allow reparenting setting by editing the master-detail relationship field definition.

Why other options are incorrect
A. The Read Only radio button, Allows users with at least Read access to the Master record to create, edit, or delete related Detail records, is selected: This option describes a setting for defining access for the child record, not the ability to change the parent record itself. It determines what users with read access to the master can do with the child, not whether the master can be reparented.
C. The Read/Write radio button, Allows users with at least Read/Write access to the Master record to create, edit, or delete related Detail records, is selected: Similar to option A, this setting concerns the access rights on the child record based on the master record's security, and does not directly control the reparenting functionality.
D. The Allow reparenting checkbox...is checked: This is the opposite of the correct answer. If the Allow reparenting checkbox were checked, the reps would be able to change the associated contact.

Explanation:

Why: 60,000+ records exceeds the Data Import Wizard limit (50k per load). Data Loader is built for bulk operations (up to millions of rows), supports CSV templates aligned to your data model, and is the standard tool for inserting a large volume of Account records quickly.

Why not the others:
B. Lightning Object Creator: Creates a new custom object from a spreadsheet; it doesn’t bulk-insert into standard Accounts.
C. Import Wizard: Easy UI, but capped at 50,000 records per job—too small for 60k+.
D. Schema Builder: For designing metadata (objects/fields/relationships), not loading data.

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.