Free Platform-App-Builder Practice Test Questions 2026

Explanation:

The requirement is to perform an action on a parent record when a child record is deleted. This is a specific trigger event that is not fully supported by most declarative automation tools.

Option C (Apex code) is correct: An Apex trigger can be written with the after delete event. This trigger would have access to the child records that were just deleted. From there, the code could gather the IDs of the affected parent records and perform a update operation on them. This is the only reliable way to handle actions based on a delete operation for a lookup relationship.

Option A (Screen flow) is incorrect: A screen flow is user-triggered and requires a UI. It cannot be automatically triggered in the background when a record is deleted.

Option B (Process Builder) is incorrect: Process Builder can only be triggered on create and edit events. It has no ability to trigger on a delete event. Therefore, it cannot detect when a child record is deleted.

Option D (Workflow rule) is incorrect: Like Process Builder, workflow rules can only be triggered on create or edit events. They cannot be triggered by a record deletion.

Key Consideration:
While declarative tools like Flow are powerful, a record-triggered flow can only be invoked on delete events for the object it is on—and its actions are limited to the deleted records themselves. It cannot perform DML operations (like updating a parent record) after the child record is deleted due to order of execution constraints. Therefore, Apex is the necessary tool for this specific requirement.

Reference:
Salesforce Help: "Trigger Order of Execution" - Explains that after a record is deleted, no further DML operations are allowed on that record, but operations on other records (like the parent) are possible in an after delete Apex trigger.
Apex Triggers: Are the programmatic method to handle delete events and perform subsequent actions on related records.

Explanation:

To prompt users with additional questions in a popup window during an approval submission, the app builder should use a custom button that launches a Flow. This approach allows for:

🪟 Popup-like experience using a Screen Flow embedded in a modal.
📝 User input collection for additional fields before the approval is submitted.
🔄 Field updates and approval submission logic all in one seamless interaction.

This is the most declarative and user-friendly way to guide reps through a structured data entry process before triggering approval.

🔧 How It Works
Create a Screen Flow:
Ask additional questions (e.g., justification, risk level, expected revenue).
Update the Account record with those responses.
Optionally submit the record for approval using Flow actions.
Create a Custom Button or Action:
Place it on the Account record page.
Configure it to launch the Flow in a modal.
Replace the standard “Submit for Approval” with this guided button.

❌ Why the Other Options Don’t Work
A. Process Builder and Flow: Process Builder is deprecated and doesn’t support user interaction or popups.
B. Lightning Component and Process Builder: Overly complex for this use case; requires custom development.
C. Custom Picklist and Process Builder: Doesn’t provide a popup or collect multiple inputs.

📘 Reference
Salesforce recommends using Screen Flows with custom buttons to collect user input before approval submission.

Explanation:

The requirement is to create a formula field that selects the contact’s preferred name for email communications, using the custom Nickname__c text field if it’s filled in, or the standard FirstName field if Nickname__c is blank. Let’s analyze the options:

Option A: IF(NOT(ISBLANK(Nickname__c)), Nickname__c, FirstName)
Correct. This formula uses:
ISBLANK(Nickname__c) to check if Nickname__c is empty.

NOT(ISBLANK(Nickname__c)) to evaluate to true if Nickname__c has a value.
IF to return Nickname__c if it’s not blank, otherwise FirstName.
This correctly handles the logic: use Nickname__c when populated, else fall back to FirstName.

Option B: IF(TEXT(Nickname__c), Nickname__c, FirstName)
Incorrect. The TEXT function converts a value to text, but it’s not a logical test for checking if a field is blank. Using TEXT(Nickname__c) in the IF condition causes a syntax error, as it doesn’t return a Boolean (true/false) value required for the IF function.

Option C: IF(ISNULL(Nickname__c), Nickname__c, FirstName)
Incorrect. This formula has multiple issues:
ISNULL is deprecated in favor of ISBLANK for text fields, as ISBLANK handles both null and empty string values.
The logic is reversed: ISNULL(Nickname__c) returns Nickname__c when blank (null), and FirstName when not blank, which is the opposite of the requirement.
Syntax errors in the formula (Nteknarne _..c, Nicknamec, Firstftame) make it invalid.

Option D: IF(NOT(BLANKVALUE(Nickname__c)), Nickname__c, FirstName)
Incorrect. The BLANKVALUE function requires two arguments: a field to check and a substitute value if blank. Using NOT(BLANKVALUE(Nickname__c)) is syntactically incorrect and causes an error, as BLANKVALUE isn’t designed for direct Boolean evaluation in this way.

Implementation Notes:
Create a formula field (e.g., Preferred_Name__c) on the Contact object with a Text return type.
Use the formula: IF(NOT(ISBLANK(Nickname__c)), Nickname__c, FirstName).
Add the field to the email template to display the preferred name.
Test with Contacts having both populated and blank Nickname__c values to ensure correct output.

References:
Salesforce Documentation: Formula Functions - ISBLANK
Explains ISBLANK for checking empty text fields.
Salesforce Help: IF Function
Details the IF function for conditional logic in formulas.

Explanation:

The core problem is reducing the manual effort of transcribing data from business cards while maintaining data quality. The best solution leverages automation and external services to enrich and validate data with minimal user input.

Option A is correct: Data enrichment products on the AppExchange (such as tools that integrate with Salesforce) can automatically parse business card information (e.g., via OCR or email integration), populate standard and custom fields, and append additional accurate data (like company details, verified phone numbers, and email addresses) from external databases. This directly reduces manual entry time for sales reps and improves data quality and completeness.

Option B is incorrect: Posting on Chatter does not automate data entry; it merely reminds users of a manual task. This adds to the sales team's workload rather than reducing it and does not guarantee data quality.

Option C is incorrect: While a Flow-based data entry wizard could improve the user experience, it still requires manual input from the sales rep to type in the information from the business card. It automates the process of creating the record but not the data entry itself. The goal is to eliminate manual transcription, not just streamline it.

Option D is incorrect: Workflow rules and formula fields can auto-populate fields based on other data within Salesforce, but they cannot capture or interpret data from an external source like a business card. They are reactive tools for internal data manipulation, not proactive tools for automating initial data entry from external sources.

Key Concept:
The most effective way to reduce manual data entry from external sources is to integrate with third-party services designed for that purpose. The AppExchange is the primary marketplace for such solutions.

Reference:
Salesforce AppExchange: Data Quality & Enrichment - Lists products that automate data entry and enrichment.

Explanation:

The recommended solution to grant the customer service agent access to the field is creating a permission set that allows read-only access to the field via Field Level Security and assigning it to the agent. A permission set is a collection of settings and permissions that give users access to various tools and functions. Field Level Security (FLS) is a setting that controls the access level of fields for different profiles or permission sets. The app builder can create a permission set that grants read-only access to the custom field on the account object via FLS and assign it to the agent.

Option B is incorrect because creating a new profile to allow for read-only access to the field via FLS and assigning it to the agent is not recommended, as profiles are used to define the baseline permissions and settings for a group of users, and creating multiple profiles for individual users can be hard to maintain.

Option C is incorrect because updating the Customer Service Profile already assigned to the agent to allow for read-only access to the field via FLS is not recommended, as this will affect all users who have the same profile, which may violate the security policy.

Option D is incorrect because updating the custom field’s FLS in setup to allow the agent read-only access to the field is not possible, as FLS can only be set at the profile or permission set level, not at the user level.

Explanation:

Why: Roll-up summaries are created on the parent object where you want the KPI to appear. To show “# Open Opportunities” and “# Won Opportunities” for each Account, create two Roll-Up Summary fields on the Account that count related Opportunities with appropriate filters (e.g., Stage = Closed Won vs. IsClosed = FALSE).

Not A/D: Lightning App Builder and the Opportunity object aren’t where you create roll-ups.
Not C: Lightning Object Creator is for creating objects from spreadsheets, not roll-ups.

Explanation:

Salesforce Lightning App Builder offers a variety of standard components that admins can drag and drop onto pages to enhance user experience—without writing any code. Among the options listed, these three are valid standard components:

✅ B. Rich Text
Allows you to display formatted text, links, and images.
Great for adding instructions, banners, or contextual help on record pages.

✅ D. Report Details
Displays embedded reports directly on the page.
Useful for showing KPIs, dashboards, or related metrics.

✅ E. Recent Items
Shows a list of recently accessed records.
Helps users quickly navigate to frequently used data.

❌ Why the Other Options Don’t Work
A. Plain Text: Not a standalone standard component. You’d use Rich Text for formatted or plain messaging.
C. Filter List: Not a standard component in Lightning App Builder. You can filter data in List View or Related List components, but “Filter List” isn’t a named component.

📘 Reference
Salesforce’s official documentation lists these and other standard components in the Lightning Page Components Guide.

Explanation:

The requirement is for sales reps to see who has access to a specific Account record and how they gained that access (e.g., through ownership, a role, a sharing rule, a team, etc.). This is precisely the function of the standard Sharing button.

Option C (Sharing) is correct: Clicking the "Sharing" button on an Account record page displays the Sharing Hierarchy for that record. This page shows a list of all users and groups with access to the record, along with the reason for their access (e.g., "Owner," "Account Team," "Sharing Rule," "Role in Hierarchy," etc.). This directly meets the reps' need to see who can view the record and how.

Option A (Sharing Hierarchy) is incorrect: While this sounds similar, "Sharing Hierarchy" is not a standard button available for the page layout. The correct button name is simply "Sharing".

Option B (New Task) is incorrect: This button is used to create a new task related to the account. It has no functionality related to viewing record access or sharing settings.

Option D (Fait) is incorrect: This appears to be a misspelling or non-existent button. It is not a standard Salesforce button and has no relevance to sharing.

How to Implement:
The app builder needs to ensure the Sharing button is added to the Account Lightning Page Layout via Lightning App Builder. It is found in the standard "Buttons" section when customizing the page.

Reference:
Salesforce Help: "View the Sharing Settings for a Single Record" - Explains that the "Sharing" button provides a detailed view of who has access to a record and why.

Explanation:

Report Types have a deployment status that controls their visibility to users. This status must be set correctly for users to access the report type.

Option D is correct:
When a report type is in "In Development" status, it is only visible to users with the “Customize Application” permission (typically administrators and developers). Regular users, even if they own the records, will not see it in the list of available report types. To make it available to all users, the app builder must change the status to "Deployed".

Option A is incorrect:
While users do need access to the underlying objects to run reports, this would not prevent them from seeing the report type in the list. If they lacked object access, they would see the report type but get an error or no data when trying to run it.

Option B is incorrect:
"Deployed" is the correct status for making a report type available to all users. If the report type were already deployed, users would be able to see and select it (assuming they have the correct object permissions).

Option C is incorrect:
The "Create and Customize Reports" permission controls whether a user can create new reports at all. If this were disabled, the user wouldn't be able to create any new reports of any type, not just this specific one. The issue described is that users cannot select the new report type, implying they can otherwise create reports.

How to Resolve:
The app builder must:
Go to Setup -> Report Types.
Select the custom report type.
Change the Status from "In Development" to "Deployed".

Reference:
Salesforce Help: "Create a Custom Report Type" - Specifically, the step on setting the deployment status: "To make the report type available to all users, change the status to Deployed. While the status is In Development, the report type is available only to administrators."

Explanation:

The issue is that a user cannot use inline editing on a list view despite having appropriate permissions. Inline editing in Salesforce list views allows users to edit fields directly in the list, but certain conditions can disable this functionality. Let’s analyze the options:
Option A: If the list view restricts sharing for the user
Incorrect. Sharing settings determine whether a user can view or edit records, but they do not directly affect inline editing functionality in list views. If the user has edit permissions (as verified), sharing restrictions would prevent access to the records entirely, not just inline editing.
Option B: If the list view selected is the recently viewed list view
Correct. The Recently Viewed list view in Salesforce does not support inline editing. This list view is dynamically generated based on recently accessed records and does not allow modifications via inline editing, even if the user has appropriate permissions.
Option C: If the list view contains a chart created by the user
Incorrect. A chart associated with a list view (e.g., for analytics) does not impact inline editing functionality. Charts are visual representations of data and do not affect the ability to edit fields directly in the list view table.
Option D: If the list view contains more than one record type
Correct. Inline editing in list views is disabled if the list view includes records of multiple record types. Salesforce restricts inline editing in this case because fields available for editing may vary by record type, leading to inconsistent behavior.

Additional Notes:
Other conditions that could disable inline editing (not listed in options) include:
The list view filter includes a locked field (e.g., a formula field or read-only field).
The object’s page layout or field-level security prevents editing specific fields.
Inline editing is disabled for the object in the org’s settings (rare, but possible).
To resolve, ensure the user selects a list view other than “Recently Viewed” and filters the list view to a single record type.

References:
Salesforce Documentation: Inline Editing in List Views
Notes that inline editing is not supported for the Recently Viewed list view and lists with multiple record types.

Explanation:

Component visibility filters allow you to control the display of individual Lightning components on a Lightning record page based on specific criteria, such as the user's profile, permission set, or other user attributes. This is the most direct and appropriate solution for hiding a component from a specific profile (Marketing) to save space on the page.

Why not A (Detail page layouts)?
Page Layouts control the organization of fields, related lists, and custom links on a record's detail view. They do not control the visibility of individual components on a Lightning record page. Page Layouts and Lightning Pages are separate concepts.

Why not C (Field-level security)?
Field-Level Security (FLS) controls a user's ability to see and edit a specific field. It has no bearing on the visibility of an entire Lightning component, which may or may not contain fields.

Why not D (AppExchange)?
AppExchange is Salesforce's marketplace for installing pre-built applications and components. It is not a tool for configuring page-level component visibility within an org.

Reference:
This falls under the exam section "User Interface." A key objective is to demonstrate the ability to customize the Lightning Experience UI, which includes using Lightning App Builder features like component visibility rules to tailor the user experience for different audiences.

Explanation:

To meet the visibility requirements for each team, we need to apply least privilege access and selective sharing:

🔒 Organization-Wide Default (OWD):
Set to Private for Accounts → ensures users only see records they own unless explicitly shared.
👥 Field Sales Team:
They should only see accounts they own → OWD Private already enforces this.
🌍 Regional Marketing Teams:
North American and European teams should see accounts in their respective regions → ✅ Use criteria-based sharing rules based on a custom field like Region__c = 'North America' or 'Europe' to share with respective public groups or roles.
🏢 Inside Sales Team:
Needs access to all accounts → ✅ Assign a profile with the "View All" permission on the Account object. This grants read access to all records of that object, regardless of ownership or sharing rules.

🔗 References:
Salesforce Sharing Rules Guide — explains how to use criteria-based sharing for regional access.
Permission Set and Profile Settings — details how "View All" works for object-level access.