Free Platform-App-Builder Practice Test Questions 2026

Explanation:

The two correct answers are C and D.

C. An object can have 25 roll-up summaries.
This is a key Salesforce platform limit. An object, such as the Account object in this scenario, can have a maximum of 25 roll-up summary fields. The proposal mentions summarizing 15 fields from three separate objects. While the total number of fields to summarize (15 x 3 = 45) might seem to exceed this limit, the question is about summarizing "15 fields... on the Account object" from each of the three objects. The more critical point is that even if the sales reps only need a few key metrics, the total number of roll-up summary fields on the parent object (Account) cannot exceed 25. This is a hard limit and a critical consideration for the proposal.

D. Roll-up summaries are limited to master-detail relationships.
This is a fundamental rule of Salesforce. A roll-up summary field can only be created on the master object in a master-detail relationship. In the proposal, one of the three custom objects has a master-detail relationship with the Account. This means you can create roll-up summary fields for that single object. However, the other two objects have relationships that are not master-detail (likely lookups), which means you cannot create roll-up summary fields for them directly. This is a significant consideration that invalidates a large part of the proposal's original design, as it stands. To achieve the summary for the other two objects, alternative solutions would be needed, such as Apex triggers, flows, or third-party apps.

Why the Other Options Are Incorrect?

A. Roll-up summaries allow MAX, MIN, SUM, COUNT, and AVG.
This option is incorrect because roll-up summaries do not support the AVG (average) function out-of-the-box. The supported functions are COUNT, SUM, MIN, and MAX. While you can achieve an average by creating two roll-up summary fields (one for SUM and one for COUNT) and then a formula field to divide them, AVG is not a direct, single function available for roll-up summary fields.

B. An object can have 20 object references.
This statement is not a standard Salesforce platform limit in the context of this question. The number of roll-up summary fields is limited to 25. The number of relationships (lookups, master-detail) a single object can be on the detail side of is a different topic and generally not a primary consideration for the number of roll-up summaries you can create. There are various limits related to relationships and fields on an object, but "20 object references" is not an accurate, standard limit relevant to this scenario.

References:
Salesforce Help Documentation: "Roll-Up Summary Field Overview" - This documentation clearly states that roll-up summary fields are available only for master-detail relationships and lists the supported functions (SUM, COUNT, MIN, MAX).
Salesforce Limits: You can find the specific limits for various Salesforce features by searching for "Salesforce Limits" or "Roll-Up Summary Field Limits." This will confirm the limit of 25 roll-up summary fields per object.

Explanation:

To prevent users in the Shipping department from deleting records on the custom object Delivery__c, the app builder should focus on object-level security — specifically the Delete permission.

✅ A. Remove the Delete permission from the Shipper profile
Profiles control baseline access to objects.
Removing the Delete permission from the Delivery__c object in the Shipper profile ensures users cannot delete records, regardless of page layout or sharing settings.

✅ D. Use a permission set to remove the Delete permission
If the Shipper users have broader access via other profiles or need flexible control, you can use a permission set to fine-tune access.
Assign a permission set that excludes Delete access to Delivery__c, overriding broader permissions.
These two options directly control whether a user can delete records — the most reliable and scalable approach.

❌ Why the other options don’t work:
B. Change OWD to Private
Controls record visibility, not delete access. Users with delete permission can still delete records they own or that are shared.
C. Remove delete button from page layout
Cosmetic only — users can still delete records via other interfaces (e.g., list views, reports, API) if they have delete permission.

🔗 Reference:
Salesforce Help: Object Permissions
Trailhead: Control Access to Records

Explanation:

Correct Answer: D. Checkbox

Why Checkbox is Correct?
A Checkbox field is the best choice because it allows users to indicate a simple yes/no or true/false condition—in this case, whether a contract was sent for an Opportunity. For example, a sales rep can check a box labeled “Contract Sent” to confirm the contract was sent before marking the Opportunity as “Closed Won.” This field type is straightforward and perfect for tracking a binary status (sent or not sent).
For reporting, a Checkbox field makes it easy to count Opportunities with the box checked (contract sent) versus unchecked (contract missing). For instance, a report can show “50 Opportunities with Contract Sent = True” and “20 with Contract Sent = False.” An App Builder can also use validation rules to ensure the “Contract Sent” checkbox is checked before allowing the Opportunity to be marked “Closed Won,” meeting UC’s requirement.

Why the Other Options Are Incorrect?

A. Text: A Text field allows users to enter free-form text, like “Contract sent on 8/25/2025.” While this could store information about the contract, it’s not ideal for reporting because the data isn’t standardized. For example, one rep might write “Sent,” another “Yes,” or “Contract mailed,” making it hard to compare and report consistently. A Checkbox is simpler and ensures uniform data for reporting.

B. Text Area: A Text Area field is for longer text entries, like notes or descriptions (e.g., “Details about the contract sent to the client”). Like the Text field, it’s not standardized, so reporting on whether a contract was sent would be difficult. For example, sorting through varied notes to determine “sent” versus “not sent” is inefficient compared to a Checkbox’s clear true/false value.

C. Picklist: A Picklist field offers a dropdown menu with predefined options, like “Sent,” “Not Sent,” or “Pending.” While a Picklist could work, it’s more complex than needed for a simple yes/no requirement. For example, a Picklist with just “Yes” and “No” duplicates the functionality of a Checkbox but requires more clicks to configure and use. A Checkbox is the simpler, more direct choice for this binary scenario.

Summary:
The Checkbox field (Option D) is the best fit because it provides a simple, standardized way to track whether a contract was sent (true/false) and supports easy reporting on Opportunities with sent versus missing contracts. Text and Text Area fields lack standardization, making reporting harder, and a Picklist is unnecessarily complex for a yes/no question.

Reference:
Salesforce Help: Custom Field Types
This documentation describes field types, including Checkbox, and their use cases, such as tracking binary conditions.

Explanation:

Access to a junction object record is controlled by a user's access to the parent records in the master-detail relationships. For a user to be able to view a junction object record, they must have at least "Read" access to both of the associated parent records.
In this scenario:
Case is the first master object.
Issue__c is the second master object.
Case_Issue__c is the junction (detail) object.
Therefore, to view a Case_Issue__c record, the auditing user needs "Read" access to both the Case record and the Issue__c record that the junction object is linking. Granting read access to the parent records is the fundamental rule for providing access to the detail records in a master-detail relationship.

Why other options are incorrect
A. Read-Only access or issue_c and_issue_c:
This option is incomplete and doesn't specify the Case object, which is required.
B. Read-Only access of Case issue =:
This option only refers to the junction object itself, not the parent objects. Access to the junction object is inherited from the parent objects, so simply granting access to the junction object is not enough.
C. Read Only access on Case and case_issue__o:
This option correctly identifies the Case object but only references the junction object itself and not the other parent, Issue__c.

Explanation:

Why these are correct:

A. My Domain must be deployed
In Salesforce, you cannot use custom Lightning components (like ones from AppExchange or custom-built) in the Lightning App Builder until My Domain is enabled and deployed.
This is because Lightning Components rely on namespace isolation, which My Domain provides.
Without My Domain, the component simply won’t appear in the Lightning App Builder.

D. The component is tagged for record pages instead of home pages
When developing Lightning components, the developer sets targets in the component’s .xml configuration file (e.g., lightning__RecordPage, lightning__HomePage, lightning__AppPage).
If the component is only tagged for Record Pages but not for Home Pages, it won’t show up when you try to add it to the Home page.
This is a common real-world issue with downloaded components.

Why the others are incorrect:

B. A custom tab must be created ❌
Creating a custom tab has nothing to do with placing a component on a Home Page.
Tabs are for navigation, not for component visibility in the Lightning App Builder.

C. The component requires a developer permission ❌
There is no such thing as a special “developer permission” required just to place a component on a page.
The visibility is controlled by My Domain + component targets, not permissions like “Author Apex” or “Modify All Data.”

📖 Reference:
Salesforce Docs: Enable My Domain
Salesforce Dev Guide: Configure Lightning Component for Lightning Pages

Explanation:

Process Builder is the best tool for this scenario because it can handle complex automation tasks, including updating a field and sending an outbound message with a time delay. In this case, when a lift is sold, Process Builder can:

→ Update the “To Be Installed” checkbox field to “True” on the Lift object.
→ Schedule an action to send an outbound message to the external system the next day.

For example, if a lift is marked as sold on August 26, 2025, Process Builder can automatically check the “To Be Installed” box and schedule an outbound message to notify the external system on August 27, 2025. Process Builder supports time-based actions, which are perfect for the “next day” requirement, and it can trigger outbound messages, which are used to communicate with external systems.

Process Builder is flexible, user-friendly for App Builders, and designed to handle multi-step automation like this, making it the ideal choice.

Why the Other Options Are Incorrect?

A. Approval Process: An Approval Process is used to route records for approval, such as when a manager needs to approve a discount on a deal. For example, if a lift sale required manager approval, this would be appropriate. However, this scenario doesn’t involve approvals—it’s about automatically updating a field and sending a message. Approval Processes can’t handle field updates or time-based outbound messages, so this option doesn’t fit.

B. Workflow: Workflow Rules are a legacy automation tool in Salesforce that can perform actions like field updates or sending outbound messages when a record meets certain criteria. For example, a Workflow could check the “To Be Installed” box when a lift is sold. However, Workflow Rules don’t support time-based actions, so they can’t delay the outbound message until the next day. This limitation makes Workflow unsuitable for the full requirement.

C. Flow: Flows are powerful for creating complex automation or guided user experiences, like a screen flow to collect data or an autolaunched flow to update records. For instance, a Flow could update the checkbox and send an outbound message. However, scheduling a time-based action (like waiting until the next day) requires additional setup, such as combining Flow with a scheduled job, which is more complex than using Process Builder’s built-in time-based actions. Process Builder is simpler for this specific task.

Summary: Process Builder (Option D) is the best choice because it can update the “To Be Installed” checkbox and schedule an outbound message for the next day in a single, easy-to-configure process. Approval Process is for approvals, not automation; Workflow can’t handle time-based actions; and Flow is unnecessarily complex for this scenario.

Reference:
Salesforce Help: Automate Processes with Process Builder
This documentation explains how Process Builder can handle field updates, outbound messages, and time-based actions.

Explanation:

To meet the requirements, the App Builder needs a relationship field that connects the gift card object to the Account object and enforces strict data integrity. The key phrase here is "permanently ensure the gift cards are unable to be moved across any other Account once it is created." A master-detail relationship is the only standard Salesforce relationship type that enforces this behavior.

A master-detail relationship creates a tight link between two objects. The child record (gift card) cannot exist without a parent record (Account). If the parent record is deleted, all associated child records are also deleted. Most importantly, a master-detail relationship field is not reparentable by default. This means that once a gift card is created and related to a specific Account, it cannot be reassigned or "moved" to a different Account. This directly satisfies the requirement.

Furthermore, a master-detail relationship is a prerequisite for creating roll-up summary fields, which are necessary to track the total number of gift cards opened and issued on the Account. This aligns perfectly with the other part of the request.

Why the Other Options are Incorrect?

B. Roll-up summary: A roll-up summary field is a type of field used to aggregate data from child records onto a parent record (e.g., counting the number of gift cards). However, it is a result of a master-detail relationship, not the relationship field itself. You must first create the master-detail relationship before you can create a roll-up summary field.

C. Formula: A formula field is used to perform calculations or display information based on other fields. It does not create a relationship between two objects, nor does it enforce any data integrity rules like preventing a record from being reassigned.

D. Lookup relationship: A lookup relationship is a loose link between two objects. It does not enforce a strict dependency, meaning a child record can exist without a parent. Crucially, a lookup relationship field is reparentable by default, which means a user could easily change the associated Account on a gift card record, directly violating the stated requirement to permanently lock the relationship.

References:
Salesforce Help Documentation: "Relationships Between Objects"
Salesforce Trailhead: "Data Modeling" module, specifically the units on "Relationship Fields."

Explanation:

Correct Answer:
D. Update the change set and re-deploy ✅

Why this is correct:
Once a change set is deployed, you can go back to the source org (Developer Sandbox), open the same outbound change set, and add/remove/update components.
After saving, you can upload it again to the target org (Developer Pro Sandbox) and then re-deploy.
This is the proper way to move updated components after initial deployment.

Why not the others:

A. Refresh the test sandbox and re-deploy the change set ❌
Refreshing a sandbox wipes it clean and resyncs it with production — you’d lose your testing work.
Not required just to update and redeploy a change set.

B. Clone the change set and re-deploy ❌
Cloning creates a new copy, but that’s unnecessary. You can simply update the existing one.
Cloning is more useful if you want a different version for another environment, not when you’re updating an existing deployment path.

C. Rename the change set, add the changes, and re-deploy ❌
Renaming does nothing functionally.
Deployment depends on the contents of the change set, not its name.

📖 Reference:
Salesforce Help: Upload Outbound Change Sets
Trailhead: Change Set Development Model

Explanation:

This scenario presents a classic data integration challenge: ensuring idempotency (the ability to apply the same operation multiple times without creating duplicates) during regular data loads from an external system. Let's evaluate the tools and strategies.

Why B is Correct: This is the definitive best practice for this use case.
Create a unique External ID field: The app builder should create a field on the Delivery__c object (e.g., Shipping_App_ID__c) and mark it as an External ID. This field will hold the unique identifier from the records in the external shipping application. This tells Salesforce that this field can be used as a key for matching records during data operations.

Use Data Loader: The Data Loader (or another API-based tool like the upsert command) can use this External ID field to perform an upsert operation. Upsert is a combination of "update" and "insert".

How it works: The file from the shipping application will include its own unique identifier for each delivery record in a column that maps to the External ID field.
If a record in Salesforce already has a matching value in the External ID field, that existing record will be updated with the new information from the file.
If no matching record is found, a new Delivery__c record will be created.
This method is robust, automated, and designed for the exact purpose of synchronizing data between systems.

Why A is Incorrect: The Import Wizard is a useful point-and-click tool for one-time or occasional data imports, typically limited to ~50,000 records. It is not the right tool for a process that needs to run "on a regular basis." Furthermore, while it can match on a standard field (like a tracking number), it lacks the robustness of using a designated External ID field made for this purpose. Automating repeated use of the Import Wizard is impractical and error-prone.

Why C is Incorrect: This option is fundamentally flawed. The Salesforce ID (a system-generated, 18-character unique identifier) exists only within Salesforce. The external shipping application would have no knowledge of Salesforce IDs for the records it owns. Therefore, it is impossible to "match on the Salesforce ID" when the source data is coming from an external system. The external system has its own unique keys.

Why D is Incorrect: Duplicate and Matching Rules are excellent declarative tools for preventing users from manually creating duplicate records in the Salesforce UI (e.g., when a sales rep is creating a new Contact). However, they are not designed or recommended for governing bulk data loads via the API, like those performed by Data Loader. These rules can be bypassed in API operations unless explicitly enforced, and using them for this purpose would be less efficient and reliable than the standard upsert pattern using an External ID.

Key Takeaway:
For recurring data integration tasks from an external system, the established pattern is:
Define an External ID field on the Salesforce object to store the external system's primary key.
Use an API tool (like Data Loader) to perform an upsert operation using that External ID as the match key.
This ensures seamless synchronization, updating existing records and creating new ones as needed, without duplicates.

Reference:
Salesforce Help: What is an External ID?
Salesforce Help: Upsert Records (Explains the upsert operation in Data Loader)

Explanation:

Correct Answer:
C. The Partial sandbox is at capacity. ✅

Why this is correct:
A Partial Copy Sandbox includes data defined in the sandbox template, but it’s limited by the 5 GB of data storage or 10,000 records per selected object (whichever is less).
Since Shipping__c has 2 million rows in production, it far exceeds the 10,000 record cap for a Partial Sandbox.
Result: Only up to 10,000 rows could be copied — and if the sandbox template wasn’t set up to include Shipping, or if the object was too large, you could end up with no records at all.

Why not the others:

A. The sandbox was refreshed too early ❌
Timing of the refresh doesn’t affect whether the data is included — only the template and sandbox limits do.

B. The selected objects in the sandbox template ❌ (tricky!)
If Shipping wasn’t selected in the template, yes, it would have no data.
BUT the question says there are 2 million rows in production — this hints that it was selected, but the data volume exceeded the Partial Sandbox limit.
On the exam, “at capacity” is the better answer because that’s what explains the missing data in large-volume objects.

D. The sandbox is still populating data ❌
Once a Partial Sandbox is refreshed, the data is copied during the refresh.
You don’t have a “delayed population” issue like with some asynchronous processes.

📖 Reference:
Salesforce Help: Sandbox Types
Salesforce Help: Partial Copy Sandbox

Explanation:

Why Criteria-Based Sharing Rules Are Correct?
Criteria-based sharing rules are the best tool for this scenario because they allow you to share records based on specific field values. In this case, AW Computing wants to share Opportunities with the Type field set to “Service Agreement” with all users in the Service Manager role. A criteria-based sharing rule can be set up to check if the Opportunity Type equals “Service Agreement” and then grant read access (or more, if needed) to users in the Service Manager role.

For example, imagine an Opportunity record with Type = “Service Agreement.” The criteria-based sharing rule would automatically share this record with all Service Managers, allowing them to view it, even though the Opportunity object uses a private sharing model. This solution is declarative (no coding required), automated, and perfectly matches the requirement to share based on a field value (Type).

Why the Other Options Are Incorrect?

A. Owner-based sharing rules: Owner-based sharing rules grant access based on who owns the record, not based on the record’s field values. For example, you could use an owner-based sharing rule to share all Opportunities owned by users in the “Sales Team” role with the “Service Manager” role. However, this scenario requires sharing based on the Opportunity Type (“Service Agreement”), not the owner, so owner-based sharing rules don’t meet the requirement.

C. Apex sharing rules: Apex sharing rules involve writing custom code (Apex) to programmatically share records. For instance, you could write Apex to share Opportunities with Type = “Service Agreement” with Service Managers. However, this is unnecessarily complex because criteria-based sharing rules can achieve the same result declaratively, without coding. Apex sharing is typically used for complex sharing logic that can’t be handled by standard sharing rules, which isn’t the case here.

D. Manual sharing: Manual sharing allows users to manually share individual records with other users or roles. For example, an Opportunity owner could manually share a “Service Agreement” Opportunity with Service Managers. However, this is not automated and requires users to take action for each record, which is inefficient and doesn’t meet the requirement for automatic sharing when the Opportunity Type is “Service Agreement.”

Summary:
Criteria-based sharing rules (Option B) are the best choice because they automatically share Opportunities with Type = “Service Agreement” with users in the Service Manager role, based on a field value, in a private sharing model. Owner-based sharing rules focus on the owner, not field criteria; Apex sharing rules are overly complex for this task; and manual sharing isn’t automated, making it impractical.

Reference:
Salesforce Help: Criteria-Based Sharing Rules
This documentation explains how criteria-based sharing rules work, including how to share records based on field values like Opportunity Type.

Explanation:

To track the number of times a case has been reopened, you need a solution that can detect when a case's status changes to "reopened" and increment a counter field (e.g., a custom number field like Times_Reopened__c). Let’s evaluate the options:

A. Scheduled Triggered Flow:
This is the most suitable solution for modern Salesforce development. A Record-Triggered Flow (not specifically "Scheduled Triggered Flow," but likely a typo in the question for a record-triggered flow) can be configured to run when a Case record is updated, check if the status changes to "reopened," and increment a custom field. Salesforce recommends using Flows for declarative automation over Process Builder, as Flows are more powerful, flexible, and actively supported. You can create a flow that triggers on Case updates, checks the status field, and updates the counter field accordingly.
B. Screw Flow:
This is not a valid Salesforce term or tool. It seems to be a distractor or typo in the question.
C. Process Builder:
While Process Builder could technically handle this by triggering on Case updates and updating a counter field, it is an older tool that Salesforce is phasing out in favor of Flows. Process Builder is less efficient and harder to maintain for complex logic compared to Flows. As of 2025, Salesforce strongly recommends using Flows for new automation.
D. Apex Trigger:
An Apex Trigger could achieve this by writing custom code to detect status changes and update the counter. However, Salesforce encourages using declarative tools like Flows for such tasks unless complex logic requiring Apex is needed. Since this requirement can be handled declaratively, Apex is overkill and not the best choice.

Why Scheduled Triggered Flow?
The question specifies "Scheduled Triggered Flow," but in Salesforce, the appropriate tool is likely a Record-Triggered Flow that runs when a Case record is updated. A scheduled flow would run on a schedule (e.g., daily), which isn’t ideal for real-time tracking of case reopen events. Assuming the intent is a record-triggered flow, it’s the best choice because:
It’s declarative, requiring no coding.
It can evaluate the Case status change and update a field using simple logic.
It aligns with Salesforce’s modern automation strategy (replacing Process Builder).

Implementation Steps (High-Level):
Create a custom number field on the Case object (e.g., Times_Reopened__c).
Build a Record-Triggered Flow on the Case object, set to trigger on update.
Add a condition to check if the Case Status is changed to "reopened" (e.g., Status = 'Reopened' and PRIORVALUE(Status) != 'Reopened').
Use an Update Records element to increment Times_Reopened__c by 1.
Save and activate the flow.

References:
Salesforce Trailhead: Automate Your Business Processes with Flow Builder
Salesforce Help: Record-Triggered Flows
Salesforce Blog: Process Builder to Flow Migration