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

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.

Explanation:

Why: A single after-save, record-triggered Flow can:
Detect a “new client won” condition (e.g., Opportunity Stage = Closed Won and Type = New Customer).
Send an email to Finance (Send Email action or Email Alert).
Create a Task for the Sales Manager, with a Decision element to skip the task when the client is top-tier.

Why not the others:
B. Screen flow: requires user interaction; this needs to run automatically.
C. Apex: unnecessary—Flow covers this without code.
D. Approval process: not an approval scenario; just notifications and conditional task creation.

Explanation:

To provide Salesforce mobile app users with access to a contact’s Twitter profile, the app builder should leverage the Twitter component available in Lightning Experience, which can be added to a Contact Lightning page. This component displays a contact’s Twitter profile based on a field (e.g., a Twitter handle stored in a custom field). Here’s why:

Option A: Add a formula field to the Contact page layout.
Incorrect. A formula field could generate a Twitter profile URL (e.g., HYPERLINK("https://twitter.com/" & Twitter_Handle__c, "View Twitter")), but it only creates a clickable link. It doesn’t provide the rich Twitter profile integration (e.g., tweets, followers) available through the Twitter Lightning component, which is more user-friendly for mobile access.

Option B: Add an AppExchange Lightning Component to the mobile app.
Incorrect. While AppExchange may offer Twitter-related components, Salesforce provides a standard Twitter Lightning component for displaying Twitter profiles. Using a native component avoids the need for third-party solutions, which may require additional configuration, cost, or maintenance.

Option C: Add the Twitter component to mobile view Lightning pages.
Correct. The standard Twitter Lightning component can be added to a Contact Lightning record page via the Lightning App Builder. This component integrates with a Twitter handle field (e.g., Twitter_Handle__c) to display the contact’s Twitter profile, including recent tweets and profile details, optimized for both desktop and mobile views in the Salesforce mobile app.

Option D: Add a Twitter Quick Action to the mobile navigation.
Incorrect. Quick Actions are used for creating or updating records, logging calls, or performing specific tasks, not for displaying external content like a Twitter profile. There’s no standard Quick Action for viewing Twitter profiles, and custom actions would be less seamless than the Twitter component.

Implementation Steps:
Ensure a custom field (e.g., Twitter_Handle__c) exists on the Contact object to store the Twitter handle.
In Setup, go to Lightning App Builder and edit the Contact Lightning record page.
Drag the Twitter component (under Standard Components) onto the page layout.
Configure the component to map to the Twitter handle field (e.g., Twitter_Handle__c).
Save and activate the page, ensuring it’s assigned to the mobile app (default Lightning pages apply to both desktop and mobile unless customized separately).
Verify the Twitter profile displays correctly in the Salesforce mobile app.

References:
Salesforce Documentation: Add the Twitter Component to Lightning Pages
Salesforce Help: Customize Lightning Record Pages for Mobile

Explanation:

Why: The requirement is that a Lead must have a sales owner (a User) before it can be added as a Campaign Member. In formulas, the polymorphic Owner field can be checked via Owner:User (populated when owned by a User) or Owner:Queue (populated when owned by a Queue).
If the Lead is still in the qualification queue, Lead.Owner:User.Id is blank.
ISNEW() ensures the rule fires only when creating the Campaign Member (so you don’t block later edits).

Why the others are wrong
A. ISBLANK(Lead.Owner.Id) — the Owner is never blank (it’s either a User or a Queue).
B. NOT(ISNEW() && ISBLANK(Lead.Owner:Queue.Id)) — this would fire on any edit (since ISNEW() is false → expression becomes NOT(FALSE)), blocking updates unnecessarily.
D. NOT(ISBLANK(Lead.Owner:Queue.Id)) — fires whenever the Lead is owned by a queue, including on edits; too broad and would prevent updates.