Free Platform-App-Builder Practice Test Questions 2026

Explanation:

Universal Containers (UC) needs a custom component built within a tight 4-week timeline, but their developers are backlogged for months and require additional enablement. An AppExchange solution is the most suitable option to meet this time-sensitive requirement, as it allows UC to leverage pre-built, third-party components or applications that can be quickly installed and configured, bypassing the need for extensive custom development.

A. Use an AppExchange solution (Correct):
The AppExchange is Salesforce’s marketplace for pre-built apps, components, and solutions created by Salesforce partners or ISVs (Independent Software Vendors). These solutions can often be installed and configured quickly, meeting UC’s 4-week timeline without requiring significant developer effort. AppExchange solutions can range from free to paid and often include components that address common business needs, reducing the need for custom coding and enabling faster deployment.
This option is ideal given the developer backlog and the need for additional enablement, as many AppExchange solutions come with documentation, support, and configuration options that non-developers (like app builders) can utilize.
Reference: Salesforce Help - AppExchange Overview

Why not the other options?
B. Build a screen flow page (Incorrect):
While Screen Flows are powerful for creating guided user experiences, building a custom component using flows still requires significant design and configuration effort. Given the developer backlog and the need for additional enablement, creating a flow from scratch within 4 weeks may not be feasible, especially if the component is complex.
Reference: Salesforce Help - Screen Flows

C. Build a Lightning record page (Incorrect):
Creating a Lightning Record Page involves customizing the user interface for a specific object using the Lightning App Builder. While this is within an app builder’s skill set, it does not address the creation of a custom component (e.g., custom logic, functionality, or reusable code). Building a record page from scratch would also require developer input for any custom components, which is not viable given the backlog and timeline.
Reference: Salesforce Help - Lightning Record Pages

D. Use a Boit solution (Incorrect):
The term “Boit solution” appears to be a typo or misinterpretation in the context of Salesforce, likely intended to mean “Bolt solution” (Salesforce Bolt solutions are pre-built industry-specific templates). However, even if corrected to “Bolt solution,” this option is not ideal. Bolt solutions are typically industry-specific and may not address UC’s specific custom component needs. Additionally, Bolt solutions are less common and not as broadly applicable as AppExchange solutions for general custom component requirements.
Reference: Salesforce Help - Salesforce Industry Solutions

Recommended Approach:
Visit the AppExchange (accessible via Salesforce or at appexchange.salesforce.com).
Search for solutions or components that match UC’s requirements for the custom component. Evaluate options based on functionality, reviews, cost (free vs. paid), and compatibility with UC’s Salesforce org.
Install the solution in a sandbox for testing, then configure it to meet specific needs within the 4-week timeline.
Work with the provider’s documentation or support team to ensure proper setup without requiring extensive developer involvement.

Additional Notes:
AppExchange solutions can include managed packages, unmanaged packages, Lightning components, or flows, many of which are designed to be plug-and-play or easily configurable by app builders, aligning with UC’s resource constraints.
If no AppExchange solution fully meets the requirements, a partially suitable solution can often be customized more quickly than building from scratch, still addressing the time-sensitive need.
The app builder should verify licensing costs and security compliance (e.g., passing Salesforce’s security review) when selecting an AppExchange solution.

Reference:
Salesforce Trailhead: Explore AppExchange
Salesforce Help: Install a Package from AppExchange

Explanation:

DreamHouse Realty wants each team member to begin small projects in their own sandbox before moving into shared environments like partial or full sandboxes. The key requirements here are:
Low cost
Individual use
Quick setup
Basic development and testing
🔹 Developer Sandbox is ideal for this:
It’s lightweight and cost-effective
Provides a copy of metadata only (no data)
Perfect for unit testing, configuration, and development
Refreshes quickly and can be spun up for each team member

❌ Why the other options don’t work:
A. Full sandbox
Too resource-intensive and expensive for individual use; meant for performance testing and staging
C. Developer pro sandbox
Similar to Developer sandbox but with more storage — useful for larger dev tasks, but not necessary for small projects
D. Partial sandbox
Includes sample data and is better suited for integration or UAT testing, not individual dev work

🔗 References:
Salesforce Help: Sandbox Types and Considerations
Trailhead: Application Lifecycle and Sandbox Strategy

Explanation:

A validation rule on the Contact object is the correct solution for this conditional requirement. The validation rule can use a cross-object formula to check the value of the Customer Status field on the parent Account record.
The formula would look something like ISPICKVAL(Account.Customer_Status__c, 'High Priority') && ISBLANK(Region__c).
This formula will return TRUE (and prevent the record from saving) if both conditions are met: the associated Account is 'High Priority' AND the Contact's Region field is blank.

Why other options are incorrect
A. Make the Region field required on Contact:
This would make the field required for all Contact records, regardless of the Account's priority, which does not meet the specific condition requested.
C. Create 4 validation rule on Account:
The validation needs to happen on the Contact record, as that is where the required field (Region) is located. A validation rule on the Account object cannot prevent a Contact from being saved.
D. Make the Customer Status field required or Account:
This would ensure the Customer Status field is filled out on the Account, but it would not enforce the conditional requirement for the Region field on the Contact.

Explanation:

Why these work
A. Big objects: Built for archiving massive/historical datasets without consuming your standard data storage. You can query them with SOQL/Async SOQL and they support certain field types including Lookup (from the big object to standard/custom objects). Standard reporting isn’t built directly on big objects; the recommended pattern is to use Async SOQL to extract a working subset into a (custom) reporting object or analytics dataset for dashboards, while keeping the archive in the big object.
D. External objects (Salesforce Connect): Keep archived data outside Salesforce (so it doesn’t count toward org storage) but still surface it in Salesforce as External Objects. These support reports (with limits), SOQL queries, and lookup-style relationships (External Lookup/Indirect Lookup) so users can relate archived records to Salesforce data and run reports on them.

Why not the others
B. Custom objects: Data would still live in Salesforce, so this doesn’t alleviate storage limits.
C. Related objects: Not an archiving mechanism—just a generic term for relationships.

References
Big Objects: Implementation guide & capabilities; querying & reporting guidance.
External Objects / Salesforce Connect: Reporting support; relationships; behavior.

Explanation:

The TODAY() function returns the current date, ideal for calculating whole days elapsed since a marketing communication was sent (e.g., TODAY() - Last_Communication_Sent__c). It ensures a whole number result, meeting the requirement for whole units.

A. DATETIMEVALUE(): Converts text to DateTime, not needed for current date.
C. DATEVALUE(): Converts DateTime/text to Date, unnecessary since TODAY() is simpler.
D. NOW(): Returns current date and time, producing decimal days, not whole units.

Reference:
Salesforce Help - TODAY()

Explanation:

Deploying a Lightning record page (often referred to as a "detail page layout" in the context of Lightning Experience) requires deploying all its dependent components to ensure it works correctly in the target org.

Why A is Correct:
The Detail page layout (officially called a Lightning Page) is the primary component you intend to deploy. This is the core item that must be included in the Change Set.

Why B is Correct:
If your page layout contains any custom fields, those fields must also be deployed. If the custom fields do not exist in the production org, the page layout will fail to load or will show errors for those missing fields. The deployment of the page layout will likely fail during validation if its dependent fields are missing.

Why C is Correct:
If you have added any custom actions (like an update record action) to the page's publisher layout, those actions must be deployed. The page layout references these actions. If they are missing in production, those specific components will not appear or function on the page.

Why D is Incorrect:
Lightning App Builder is the tool used to create and edit Lightning Pages. It is not a deployable component itself; it is a feature of the Salesforce platform. You deploy the output of the tool (the Lightning Page), not the tool.

Why E is Incorrect:
While profile settings control who can see the page layout, the System Administrator profile itself is not a component you include in a Change Set to make the page layout deploy or render correctly. Profile visibility for the page is handled by the page's assignment (which is part of the page deployment) or by permission sets. You do not deploy entire profiles for this purpose.

Reference:
Salesforce Help - "Change Sets Overview" and "Deploy Lightning Page Resources". The key principle is that when deploying any component, you must also deploy all its dependencies—the other metadata components it relies on to function. For a Lightning Page, this includes the fields, actions, and any other custom components placed on it.

Explanation:

The issue is that a sales rep reports that their Contact is unavailable for other users to see in Salesforce. This suggests a visibility problem, likely related to sharing settings, object access, or record relationships. An app builder needs to troubleshoot using methods that align with Salesforce’s security and access model. Below is a concise analysis of each option:

A. Create an Account Sharing Rule to give the users access to all records (Incorrect):
Creating a sharing rule to grant access to all Account records is overly broad and does not specifically address the issue of a single Contact’s visibility. Additionally, Contact visibility is often controlled by the parent Account’s sharing settings due to the Account-Contact relationship. This action could unnecessarily expose unrelated records and is not a targeted troubleshooting step.
Reference: Salesforce Help - Sharing Rules

B. Confirm whether Default Organization-Wide Sharing Settings provide access to the Account (Correct):
Contact visibility is typically controlled by the Organization-Wide Default (OWD) settings of the parent Account due to the standard master-detail or special relationship between Accounts and Contacts. If the Account’s OWD is set to Private, users without access to the Account (via ownership, role hierarchy, or sharing rules) cannot see associated Contacts. Checking the Account’s OWD settings is a critical troubleshooting step to determine if the issue stems from restricted Account access.
Steps: Go to Setup > Security > Sharing Settings and review the OWD for Accounts and Contacts.
Reference: Salesforce Help - Organization-Wide Defaults

C. Review the Contact record and ensure it is linked to an Account (Correct):
In Salesforce, Contacts are typically linked to Accounts via a Lookup or Master-Detail relationship. If a Contact is not associated with an Account (e.g., the Account field is blank), its visibility may be restricted, especially if the OWD for Contacts is Controlled by Parent or Private. Reviewing the Contact record to confirm it is linked to an Account is a key troubleshooting step, as missing or incorrect Account linkage could prevent other users from seeing the Contact.
Steps: Open the Contact record and check the Account Name field to ensure it references a valid Account.
Reference: Salesforce Help - Account and Contact Relationships

D. Verify the users with the issue have access to the Contact object (Correct):
Users must have at least Read access to the Contact object via their Profile or Permission Set to view Contact records. If the users experiencing the issue lack object-level access, they won’t see the Contact, regardless of record-level sharing settings. Checking Profile or Permission Set permissions for the Contact object is a fundamental troubleshooting step.
Steps: Go to Setup > Users > Profiles, select the user’s Profile, and verify that the Contact object has Read access.
Reference: Salesforce Help - Profiles and Permissions

E. Create a new Contact and have the users try again (Incorrect):
Creating a new Contact to test visibility does not directly troubleshoot the issue with the existing Contact record. It may help identify whether the problem is specific to the record, but it’s not a systematic approach to diagnosing the root cause (e.g., sharing settings, object access, or Account linkage). This option is more of a workaround than a troubleshooting step and is less efficient than the other correct options.
Reference: Salesforce Help - Troubleshooting Record Access

Recommended Troubleshooting Steps:
Check OWD Settings (B): Verify the OWD for Accounts and Contacts in Setup > Sharing Settings. Ensure the Account OWD is not Private or that Contacts are not set to Controlled by Parent, which could restrict access.
Verify Contact’s Account Link (C): Open the Contact record and confirm it is linked to a valid Account. If not, update the Account Name field or investigate why the linkage is missing.
Confirm Object Access (D): Check the users’ Profiles or Permission Sets to ensure they have Read access to the Contact object. Also, verify if they have access to the parent Account via sharing rules or role hierarchy.

Additional Notes:
If the Account’s OWD is Private, check if the users are in the same role hierarchy as the Account owner or if sharing rules grant them access.
If Contacts are set to Controlled by Parent, ensure the parent Account’s access settings allow visibility.
Use the Sharing Hierarchy (via the “Sharing” button on the Contact or Account record) to inspect why specific users cannot see the record.

References:
Salesforce Trailhead: Data Security
Salesforce Help: Troubleshooting Record Access

Explanation:

This requirement involves controlling field editability based on a record's stage (open vs. closed) and the user's role (sales rep vs. sales operations). The key is that the same field (e.g., Amount) needs to be editable in one context and read-only in another. This requires a combination of tools.

Why C is Correct: This is the standard and most effective solution.
Record Types: Create two record types for the Opportunity object: "Open Opportunity" and "Closed Opportunity."
Page Layouts: Assign different page layouts to each record type.
The "Open Opportunity" layout shows all editable fields for sales reps.
The "Closed Opportunity" layout makes most fields read-only and prominently displays the two "Post-Close" fields for the sales operations team to edit.
Field-Level Security (FLS): FLS is used to ensure that the sales operations team has Edit access to the "Post-Close" fields, while the sales reps might only have Read access (if that is a requirement). FLS controls the fundamental ability to see and edit a field at the object level.
Automation (Workflow/Process Builder/Flow): An automated process (not listed in the answers but implied as the trigger mechanism) is required to automatically change the Record Type from "Open" to "Closed" when the Opportunity stage is set to a closed stage. This is the crucial step that swaps the page layout, changing the field-level behavior for the entire record.

Why A is Incorrect: Field Sets are a developer feature used to group fields for programmatic purposes (e.g., in a Visualforce page or Lightning component). They are not a security or layout tool for declaratively controlling field editability for different user profiles. This option overcomplicates a straightforward layout and security requirement.

Why B is Incorrect: While page layouts can restrict editing by making fields read-only, this setting applies to all users viewing that layout. You cannot make a field read-only for one profile and editable for another on the same page layout. This is why you need different page layouts (assigned via record types) for the "open" and "closed" states. FLS on its own is not granular enough for this requirement.

Why D is Incorrect: Using Field-Level Security (FLS) to mark fields as read-only on the Sales profile would make those fields read-only at all times, even when the opportunity is open. This violates the requirement that sales reps can modify those fields until the opportunity is closed. FLS is a static control, not a dynamic one that changes based on the record's state.

Summary:
The solution dynamically changes the user's experience based on the record's data (its stage). This is achieved by:
Using Record Types to categorize records into "Open" and "Closed."
Using different Page Layouts for each record type to control field editability at the UI level.
Using Field-Level Security to ensure the sales operations team has the underlying permission to edit the specific post-close fields.
Using an Automation Tool to change the record type when the opportunity is closed.

Reference:
Salesforce Help - "Record Types" and "Control Field Access with Page Layouts and Record Types". The documentation explains how record types and page layouts work together to provide different user experiences for different states of the same record.

Explanation:

This scenario involves two automation goals:
Automatically create a renewal Opportunity when an Opportunity is marked Closed Won.
Notify an external contracts team about the closed deal.

🔹 Why Process Builder is the best fit:
It can detect field changes (e.g., Stage = Closed Won).
It can create new records, such as a renewal Opportunity.
It can invoke Apex, send email alerts, or even call outbound messages to notify external systems.
It supports multiple actions in a single process — perfect for this multi-step requirement.

❌ Why the other options don’t work:
A. Approval Process
Used for record approval workflows, not for automation based on field changes or record creation.
B. Validation Rule
Prevents users from saving records under certain conditions — it doesn’t automate actions.
D. Workflow Rule
Can send email alerts or outbound messages, but cannot create records (like a renewal Opportunity). Also being phased out in favor of Flow and Process Builder.

🔗 References:
Salesforce Help: Process Builder Overview
Trailhead: Automate Business Processes with Process Builder

Explanation:

A. Set Sharing Settings to Read Only on both Master-Detail relationship fields:
When a user is given edit access to a junction object record, they will inherit access from the master records. To allow a user to edit the junction record while only providing read access to the master records, you need to set the "Sharing Settings" option on the master-detail relationship field to "Read Only". This prevents a user who has edit permission on the junction object from also gaining edit access to the master records.
D. Create an owner-based sharing rule that gives Read action to the junction object:
With the junction object's OWD set to Private, only the record owner and users higher in the role hierarchy have access by default. To give a select group of users (not just the owner) the ability to edit the junction records, you must first give them at least Read access via a sharing rule. Once they have Read access, and their profile permissions grant Edit access, they can edit the junction records. This sharing rule can be based on the owner of the junction records.

Why other options are incorrect
B. Create owner-based sharing rules that give Read access to the master objects:
While users need at least Read access to the master objects (Seminars and Attendees) to interact with the junction object, creating sharing rules for the master objects is not sufficient to grant edit access specifically on the junction object. The question asks how to secure access to the junction object for editing, which requires a sharing rule on the junction object itself.
C. Sat lookup filters on both Junction object relationship field:
Lookup filters are used to restrict the records that can be selected in a lookup relationship. They do not control or grant record-level access for security purposes.

Explanation:

Cloud Kicks requires managers to approve opportunities exceeding $50,000 before they can be marked as Closed Won, and the approval process must be accessible via the Salesforce mobile app. In Salesforce, approval requests can be responded to in specific ways within the mobile app. Below is a concise analysis of each option:

A. Home Screen (Incorrect):
The Home Screen in the Salesforce mobile app displays key metrics, tasks, or quick actions but does not provide a direct interface for responding to approval requests. While it may show notifications or tasks related to approvals, managers cannot take action (approve/reject) directly from the Home Screen.
Reference: Salesforce Help - Salesforce Mobile App

B. In-App Notification (Correct):
In-App Notifications in the Salesforce mobile app alert users to pending approval requests. Managers can tap on an approval notification, which directs them to the approval request details, where they can approve or reject the request. This is a primary method for responding to approvals in the mobile app, providing a quick and direct way to act on notifications.
Reference: Salesforce Help - Respond to Approval Requests in the Salesforce Mobile App

C. Record Detail (Correct):
The Record Detail page for an Opportunity in the Salesforce mobile app displays the approval request if one is pending. Managers can navigate to the Opportunity record, view the approval section, and take action (approve/reject) directly from the record’s detail page. This is a standard method for handling approvals in the mobile app.
Reference: Salesforce Help - Approvals in Salesforce Mobile

D. Navigation Menu (Incorrect):
The Navigation Menu in the Salesforce mobile app allows users to access objects, apps, or other features but does not provide a direct interface for responding to approval requests. While managers can navigate to the Opportunity object or an Approvals tab (if configured), the actual approval action occurs on the Record Detail page or via In-App Notifications, not directly in the Navigation Menu.
Reference: Salesforce Help - Salesforce Mobile Navigation

Recommended Approach:
In-App Notification: Managers receive a push notification or in-app alert for pending approval requests. Tapping the notification takes them to the approval interface to approve or reject the Opportunity.
Record Detail: Managers can navigate to the Opportunity record in the mobile app, locate the approval request section, and take action directly on the record.

Additional Notes:
Ensure the approval process is configured in Setup > Approval Processes to trigger for Opportunities with an amount exceeding $50,000.
Verify that managers have the necessary permissions (via Profile or Permission Set) to approve/reject requests.
The Salesforce mobile app must be properly configured to display notifications and allow approval actions.

References:
Salesforce Help: Approvals in the Salesforce Mobile App
Salesforce Trailhead: Approval Processes

Explanation:

Why:
Validation rules are designed to verify data before save and block the save when the data doesn’t meet your standards—perfect for enforcing both required fields and format checks (e.g., ISBLANK(), REGEX()). You can also scope the rule to specific record types (e.g., RecordType.DeveloperName = "Enterprise"), so the requirement only applies where needed.

Why not the others
A. Required on page layout:
Only enforces entry when that specific page layout is used; it doesn’t consistently enforce requirements across all entry points (API/imports/automations). It also doesn’t validate format.

B. Formula field:
Formula fields are calculated and read-only; they can’t enforce input or block saves.

C. Workflow rule:
Workflow automates after a record is saved; it can’t stop a bad save. Use validation rules to prevent the save instead.

References:
Salesforce Help: Validation Rules (verify data before save, apply to new/updated records).
Salesforce Help: Make a custom field required (page-layout requirement is layout-specific).