Free Platform-App-Builder Practice Test Questions 2026

Explanation:

During an active approval process, a record lock is typically applied to prevent changes that could undermine the integrity of the approval. The specific behavior is controlled by the "Lock the record during the approval process" setting on the approval process definition.

Option A is correct:
If the approval process is configured to lock the record (which is a common and recommended practice), any user, including the submitter, who tries to edit the record will receive a notification that the record is locked. They will be unable to make any edits until the record is recalled, rejected, or approved.

Option B is incorrect:
The record lock applies to the entire record, not just specific fields. If the record is locked, no edits are permitted to any field.

Option C is incorrect:
While the manager may be assigned as an approver, ownership of the record does not automatically change upon submission. Ownership only changes if a field update is specifically configured in the approval process to reassign the record.

Option D is incorrect:
This is not how record locking works. The lock is on the entire record. The user would not be able to edit the name or the description.

Key Consideration:
An app builder can configure the approval process to not lock the record, which would allow certain edits. However, the default and most secure behavior is to lock it. Since the question does not specify otherwise, we assume the standard, locked behavior. The most accurate and general answer is that the user will be prevented from editing by a record lock notification.

Reference:
Salesforce Help: "Lock Records During Approval" - This article explains the record locking behavior: "While a record is locked, only users with the “Modify All” object-level permission can edit the record. Other users can’t edit the record until it’s unlocked... When a user who doesn’t have “Modify All” permission tries to edit a locked record, a message appears saying that the record is locked."

Explanation:

When a master-detail relationship is created between two objects in Salesforce:
The child object (Star__c) is tightly bound to the parent object (Galaxy__c).
Salesforce automatically generates a standard report type in the format: “Galaxy__c with Star__c”
This report type allows users to build reports that show Galaxy__c records along with their related Star__c records, perfect for analyzing parent-child data in one view.

🔍 Why the Other Options Don’t Work
A. Incorrect format — the report type is named after the parent WITH child, not the other way around.
B. No need to manually create a custom report type — Salesforce handles this automatically for master-detail relationships.
D. Same issue — a custom report type is not required in this scenario.

📘 Reference
Salesforce confirms this behavior in their documentation on Criteria to Generate a Standard Report Type

Explanation:

Since the organization-wide default (OWD) for opportunities is Private, record access must be granted to users who don't own the records. The sales operations team needs both read and write access to all opportunities, so these two solutions are the best approach:
A. Create a criteria-based sharing rule to all opportunities with the sales operations public group: Sharing rules are used to automatically grant access to groups of users beyond the OWD. Since the sales operations team needs access to all opportunities, a criteria-based sharing rule can be set up for Opportunity.RecordType equals (the record type of all opportunities). This rule would grant "Read/Write" access to a Public Group containing all the members of the sales operations team.
C. Add a permission set with 'View All' and 'Modify All' opportunity permissions enabled: The "View All" and "Modify All" object permissions ignore sharing rules and settings, giving users access to all records for a specific object, regardless of the sharing model. This is an efficient way to grant broad access to a specific team.

Why other options are incorrect
B. Add a manual share for all opportunities with each user on the sales operations team: This is not a scalable solution. With a large number of opportunities, manually sharing each one with every team member would be extremely time-consuming and difficult to maintain. Sharing rules automate this process.
D. Create a criteria-based sharing rule to share all opportunities with the sales operations private group: Sharing rules are used to grant access to public groups, roles, and territories, not private groups. Private groups are typically used for more manual, ad-hoc sharing.

Explanation:

Why:
In Salesforce approvals, a manager can designate a Delegated Approver on their user record. If the approval step is configured to allow it (“The approver’s delegate may also approve this request”), the delegate can approve while the manager is away—keeping the leaderboard current at quarter-end.

Why not the others
A. Forwarding the email doesn’t grant approval rights in Salesforce. The recipient must be the approver or a configured delegate.
C. Having the manager log in to reassign isn’t practical when they’re on vacation; delegated approver is the intended mechanism.
D. You don’t use Process Builder to assign a delegated approver; it’s set on the manager’s User record (Delegated Approver field and preferences).

Tip:
Confirm each approval step has “approver’s delegate may also approve” enabled so the delegate can act.

Explanation:

DreamHouse Realty (DHR) is planning to migrate Cloud Kicks' Salesforce org from Salesforce Classic to Lightning Experience and is looking for prebuilt resources to assist with the migration and overall adoption. Let’s analyze each option to determine the best source for these resources:

Option A: Import Wizard
This is incorrect. The Data Import Wizard is a tool for importing data into Salesforce objects (e.g., leads, contacts, or custom objects) from CSV files. It is not designed to provide prebuilt resources for migrating to Lightning Experience or aiding user adoption.
Option B: Lightning Object Creator
This is incorrect. The Lightning Object Creator is a tool that allows users to create custom objects from spreadsheets by automatically generating fields and layouts. While useful for creating new objects, it does not provide prebuilt resources specifically for migrating to Lightning Experience or supporting adoption.
Option C: AppExchange
This is correct. The Salesforce AppExchange is a marketplace offering a wide range of prebuilt apps, components, and solutions, many of which are designed to facilitate the transition from Salesforce Classic to Lightning Experience. For example, AppExchange provides tools like the Lightning Experience Transition Assistant, adoption kits, training modules, and third-party apps that help with migration planning, user training, and enhancing Lightning adoption. These resources can include prebuilt reports, dashboards, Lightning components, and guided adoption paths tailored to Lightning Experience.
Option D: Flow Builder
This is incorrect. Flow Builder is a Salesforce tool for creating automated processes and guided user experiences (e.g., screen flows or record-triggered flows). While it can be used to build custom solutions to enhance the Lightning Experience, it does not provide prebuilt resources specifically for migrating to or adopting Lightning Experience.

Additional Notes:
The Lightning Experience Transition Assistant (available in Setup within Salesforce) is a key internal tool for guiding the migration process, but since the question specifically asks about prebuilt resources, AppExchange is the best answer because it offers a broader range of external tools, apps, and adoption resources.
AppExchange solutions may include free or paid apps, such as Lightning adoption tools, training content, or prebuilt Lightning components that streamline the user experience and support the transition.
For adoption, AppExchange also offers resources like Trailhead-based adoption kits or third-party training apps that help users learn Lightning Experience features.

References:
Salesforce Documentation: AppExchange Overview
Describes the AppExchange as a source for apps and solutions to enhance Salesforce functionality, including Lightning adoption tools.
Salesforce Help: Transition to Lightning Experience
Mentions AppExchange as a resource for finding tools and components to support the Lightning Experience migration.
Salesforce AppExchange: Lightning Experience Apps Lists apps and solutions specifically tagged for Lightning Experience support.

Explanation:

The requirement specifies that the field must support "detailed descriptions that can include pictures and links." This functionality is the specific purpose of the Rich Text Area field type.

Option B (Rich Text Area) is correct: This field type provides a toolbar for formatting text (bold, italics, etc.), creating bulleted lists, inserting hyperlinks, and embedding images. It is the only standard field type designed to handle rich, formatted content with images directly within a record's field.
Option A (Long Text Area) is incorrect: While this field type is excellent for long, detailed descriptions, it only supports plain text. It does not support any text formatting, hyperlinks, or images.
Option C (Multi-Select Picklist) is incorrect: This field type is used for allowing users to select multiple predefined values from a list. It cannot be used for free-form text entry, let alone formatted text with images.
Option D (URL) is incorrect: This field type is designed to store a single web address (URL). It cannot store descriptive text, multiple links, or images.

Reference:
Salesforce Help: "Rich Text Area Fields" - The documentation explicitly states: "Use rich text area fields to add formatted text, images, and links."

Explanation:
To ensure sales reps input contacts into Salesforce rather than their personal devices:

C. Enable offline create, edit, and delete in Salesforce for Android and iOS.
This feature allows sales reps to enter contact information directly into the Salesforce Mobile App even when they are offline, which syncs back to Salesforce once connectivity is restored.

Steps to enable offline capabilities:
Navigate to Setup Mobile Administration Salesforce Mobile App Offline Settings.
Configure offline settings to allow for creating, editing, and deleting records.
Ensure that the Contact object is available for offline access.
This functionality encourages reps to use Salesforce directly by mitigating connectivity constraints.

For implementation details, refer to Salesforce Mobile App Offline.

Explanation:

Why: Field-Level Security (FLS) is the only way to truly secure a field in Salesforce (UI, reports, search, and API). Make the Comment field visible only to HR profiles/permission sets; hide it for everyone else. Page layout changes alone don’t secure data.

Why not the others
B/C: Sharing rules (or “Apex sharing”) work at the record level—there’s no such thing as sharing a single field.
D: Page layouts only control what’s shown on the page; users could still access the field via reports/API unless FLS hides it.

Explanation:

The requirement is to automate the deletion of rejected quotes associated with an opportunity at Universal Containers. The automation tool must be capable of handling record deletion based on a condition (e.g., Quote status = "Rejected"). Let’s analyze each option:

Option A: Approval process
This is incorrect. An approval process is designed to manage record approval workflows, such as submitting records for approval, locking records, and updating fields based on approval outcomes. It cannot directly delete records like rejected quotes.

Option B: Validation rule
This is incorrect. Validation rules are used to enforce data quality by preventing users from saving records that don’t meet specific criteria (e.g., requiring certain fields or formats). They cannot perform actions like deleting records.

Option C: Workflow rule
This is incorrect. Workflow rules (now retired in favor of Salesforce Flow for new automation) can trigger actions like field updates, email alerts, tasks, or outbound messages when certain conditions are met. However, they cannot directly delete records, as deletion is not a supported action in workflow rules.

Option D: Flow
This is correct. Salesforce Flow, specifically a Record-Triggered Flow, is the appropriate tool for this scenario. A Flow can be configured to trigger when a Quote record is updated (e.g., when its status changes to "Rejected") and include a Delete Record element to remove the rejected Quote. Flows are powerful, flexible, and capable of handling complex automation tasks, including record deletion, making them ideal for this use case.

Implementation Details:
Create a Record-Triggered Flow in Flow Builder, set to trigger on the Quote object when a record is updated.
Add a condition to check if the Quote’s status field (e.g., Status = 'Rejected') is true.
Use a Delete Record element in the Flow to delete the Quote record that meets the condition.
Test the Flow in a sandbox to ensure it correctly deletes only rejected Quotes.
Activate the Flow and monitor its performance in production.

Additional Notes:
Ensure proper permissions are in place, as deleting records requires the user or the Flow (running in system context) to have Delete access to the Quote object.
Consider adding a filter to check if the Quote is associated with an Opportunity (if needed) to ensure the Flow only targets relevant records.
If there are multiple Quotes per Opportunity, the Flow will delete each rejected Quote independently, preserving other Quotes (e.g., those with "Approved" or "Draft" status).

References:
Salesforce Documentation: Record-Triggered Flows
Explains how to use Record-Triggered Flows to automate actions like record deletion based on criteria.
Salesforce Help: Delete Records in a Flow
Details the use of the Delete Record element in Flow to remove records programmatically.
Salesforce Documentation: Automate Business Processes with Flow
Highlights Flow as the recommended tool for complex automation, replacing older tools like Workflow Rules.

Explanation:

Why: Approval processes don’t run “on delete.” The standard pattern is: reps request deletion (e.g., set a flag or click a quick action) → the record is submitted for approval → on final approval, kick off a Flow that deletes the Opportunity. You can trigger the Flow either directly from the approval’s final action (Flow) or indirectly via a final approval field update that a record-triggered Flow listens for, then uses Delete Records.

Why not the others
A. Process Builder with Submit for Approval: Can auto-submit, but it doesn’t handle the deletion itself (and PB doesn’t fire on delete).
C. Approval Process with Time-Dependent Workflow: Time-based workflow can’t delete records; not relevant to approval-gated deletion.
D. Two-step Approval Process: More steps ≠ deletion control; still needs automation to actually delete after approval.

Exam tip:
If you prefer the indirect route, use a Final Approval Action → Field Update (e.g., Deletion_Approved = true), then a record-triggered Flow deletes the Opportunity.

Explanation:

To capture latitude and longitude coordinates for remote construction sites, the app builder should use the Geolocation field type. This is a compound field in Salesforce that stores:
Latitude (−90 to +90 degrees)
Longitude (−180 to +180 degrees)
It’s specifically designed for mapping, distance calculations, and location-based logic. Perfect for use cases like delivery logistics, field service routing, or territory planning.

❌ Why the Other Options Don’t Work
A. Number: You’d need two separate fields and lose the ability to use built-in geolocation features like distance calculations.
C. Text: Not structured for spatial data; no validation or mapping support.
D. External Lookup: Used to link records across external objects, not for storing coordinate data.

📘 Reference
Salesforce’s official documentation confirms that Geolocation fields are ideal for storing and working with location coordinates.

Explanation:

When you create a custom report type, Salesforce creates a specific layout for that report type. This layout determines which fields are available to users when they build a report using that custom report type.
Here's why this is the correct troubleshooting step:
A new field added to an object after the custom report type was created will not be automatically included in the custom report type's field layout.
Even though the field exists on the Applicant object, the custom report type (Position with or without Applicants) needs to be manually updated to include the new field in its layout for it to appear in the report builder.

Why the other options are incorrect
A. Adjust the field level security to include in the report type: Field-level security (FLS) determines a user's access to a field, not whether the field is available in the report type itself. If the field was visible in the report type's layout but the user couldn't see its data, FLS would be the issue.
B. Check Allow Reports for the position and applicant objects: The "Allow Reports" setting must be enabled on custom objects for them to be used in reports at all. Since the report already exists, this setting must already be enabled, so it's not the reason for the missing field.
D. Update the profile with the Manage Public Reports permission: The "Manage Public Reports" permission allows users to create, edit, and delete reports in public folders. It has no impact on which fields are available in a report type.