Platform-App-Builder Practice Test Questions

Explanation:

Why this is correct:
ROI for marketing spend is tracked in Salesforce via Campaigns. Create a parent campaign for the advertising buy and child campaigns for each channel/ad/creative. Salesforce rolls up child metrics to the parent via Campaign Hierarchy “statistics” fields, and you can run the built-in Campaign ROI Analysis Report to calculate ROI using costs and influenced/won opportunity amounts. This works fine with a private sharing model; no need to change org-wide defaults—just share the specific Campaigns as required.

Why the others are wrong:
A. Account Hierarchies and Roll-Up Summary fields — Account roll-ups don’t measure marketing ROI; ROI is a Campaign concept with Campaign-to-Opportunity attribution. Salesforce
B. Opportunities pipeline report — Shows stage/amount forecasts, not campaign spend vs. return.
C. Change to a public security model — Unnecessary; Campaign ROI can be measured without altering OWDs.

Reference:
Salesforce docs on Campaign Hierarchies (roll-up stats) and the Campaign ROI Analysis Report.

Explanation:

In Salesforce, when creating new automation on an object, the recommended best practice is to consolidate record-triggered automation into one Flow per object (or per trigger event, such as before/after save). This approach, often called the "One Per Object" design pattern, minimizes the number of triggers firing on the object, improves performance by reducing context switches and governor limit consumption, simplifies debugging and maintenance, and ensures predictable order of execution using features like Flow Trigger Order. It builds on the legacy Process Builder model and aligns with modern Flow-only automation strategies.
This practice helps avoid issues like unintended record updates from multiple overlapping automations, excessive CPU time, or challenges in tracing logic across disparate tools. For complex orgs, use subflows or decision elements within the single Flow to handle branching logic, rather than creating multiple independent Flows.

Why not the other options?
A. One Workflow rule per object:
Workflow Rules are a legacy automation tool (retired in Winter '24) that only support field updates, tasks, emails, and outbound messages. They cannot handle complex logic like Flows and are not recommended for new automation. Consolidating to one Workflow Rule per object was never a primary best practice, as multiple could be used but often led to order-of-execution problems.
B. One invokable process per object:
Invocable processes (autolaunched Flows) are designed for reusable sub-processes called from other Flows or Apex, not for primary record-triggered automation on an object. Limiting to one per object isn't a standard practice and doesn't address core record-change scenarios.
C. One record change process per object:
This phrasing refers to legacy Process Builder terminology (a "record-change process" is a Process Builder process triggered by record changes). While the one-per-object pattern originated here for performance reasons, Process Builder is retired (end-of-life in 2025). New automation must use Flows, making this outdated.

References:
Salesforce Architects: Record-Triggered Automation
Salesforce Help: Best Practices for Designing Processes (Note: Applies to Flow design patterns post-Process Builder retirement)

Explanation:

Why B is Correct:
The requirement is to improve the process to create Opportunity records related to an Account. A Quick Action placed on the Account page layout is the perfect solution. This allows a user to be viewing an Account and instantly create a new, related Opportunity without navigating away. The key benefit is that this action can be pre-configured to:
Pre-populate fields from the Account: The action can automatically set the Opportunity's AccountId and map any other relevant fields from the Account (e.g., Account Number, Billing Address) to the new Opportunity record using pre-defined field values.
Require input from the user: The action can present a compact form where the user must fill in the required fields that cannot be pre-populated (e.g., Close Date, Stage, Amount).

Why A is Incorrect:
Process Builder is an automation tool, not a user interface tool. A Process triggered on Opportunity update fires after a record is saved. It cannot help with the initial creation process or provide a UI for user input during creation.
Why C is Incorrect:
A Quick Action on the Opportunity object itself would be useful for updating existing Opportunities, but it is not the most efficient way to create one from a specific Account. The user would first have to navigate to the Opportunities tab, click "New," and then manually find and select the Account. This adds extra steps compared to starting from the Account record.
Why D is Incorrect:
Like option A, this uses an automation tool (Process Builder) incorrectly. A Process triggered from an Account update would fire when the Account is edited, not when a new Opportunity is being created. It cannot interact with the user to gather required input for the new Opportunity.

Reference:
Salesforce Help Article: "Create Object-Specific Actions." Quick Actions are designed specifically to streamline common tasks, like creating related records, directly from the parent record's page, making them a cornerstone of efficient UI design for App Builders.

Explanation:

Universal Containers wants sales managers to sign off when a discount falls within a specific range (20–30%). This is a classic use case for conditional approval and UI customization. Here's how each correct feature supports the requirement:

🔹 D. Approval Process
Automates the sign-off workflow based on criteria (e.g., discount between 20% and 30%).
Ensures that deals meeting the condition are routed to managers for approval.
Can be triggered from the Opportunity record using a button or action.

🔹 B. Dynamic Actions
Allows you to conditionally display the “Submit for Approval” button directly on the Opportunity record page.
Ensures that the action is only visible when the discount falls within the specified range.
Enhances user experience by keeping the page clean and context-aware.

🔍 Why the other options don’t fit:
A. Validation Rule
Prevents actions but doesn’t enable approvals or UI customization. It’s more for enforcing data integrity.
C. Schema Builder
Used for visualizing and creating object relationships, not for UI or process automation.

🔗 References:
Approval Processes – Salesforce Help
Dynamic Actions – Salesforce Admin Guide

Explanation:

In Salesforce, for a master-detail relationship where Internships (master) has an organization-wide default (OWD) of Private, the detail object Applications automatically inherits its sharing settings from the master—its OWD is "Controlled by Parent." This means access to Application records is determined solely by access to the related Internship record. Recruiters cannot edit Applications unless they have at least Read access to the corresponding Internship (and the detail object's sharing rule minimum access allows edits).
To grant recruiters edit access to Applications without broadly exposing Internship records (e.g., without changing the Internships OWD or granting full access to all Internships), the app builder should create a criteria-based or owner-based sharing rule on the Applications object. This rule would target specific Application records (e.g., based on criteria like status or recruiter role) and share them with recruiters' roles, groups, or public groups with Read/Write access. Sharing rules on detail objects override the inherited parent sharing for targeted records, allowing granular control. This ensures recruiters can edit Applications as needed for the application process while maintaining the private security on Internships.

Why not the other options?
A. Set the organization-wide default on the Applications object to Read/Write: For detail objects in a master-detail relationship, the OWD cannot be set independently—it is fixed as "Controlled by Parent" and cannot be changed to Public Read/Write or any other value. Attempting this would not be possible in Setup, and it would undermine the private model on Internships by potentially exposing all Applications regardless of master access.
B. Add a sharing rule that grants the users Read/Write access to the Internship records: While sharing rules on the master (Internships) would grant access to both Internship records and their child Applications (enabling edits if the detail sharing minimum is set to Read Only or higher), this unnecessarily exposes sensitive Internship data to recruiters. The requirement focuses on editing Applications for the HR process, not full access to Internships, so this is overly permissive and not the most targeted solution.
C. Create a queue for the web applications and assign access to the users who will be editing the records: Queues allow multiple users to claim and work on records (e.g., for support cases or leads), but Applications is a custom object in a master-detail relationship, and queues are not supported for detail objects. Even if enabled, queues handle ownership for pending work but do not directly address sharing or edit access for recruiters on non-owned records; sharing rules are needed for that.

References:
Salesforce Help: Considerations for Standard and Custom Object Relationships (Details master-detail sharing inheritance and inability to set independent OWD on details).
Salesforce Help: Create Sharing Rules (Explains using sharing rules on detail objects to grant access beyond parent inheritance).
Trailhead: Data Security - Record Access (Covers how detail records inherit from master and use sharing rules for overrides).

Explanation:

A. Mark stage dependent fields as required on the Opportunity page layout: By using validation rules or conditional visibility with Dynamic Forms, an app builder can enforce that certain fields must be completed before an opportunity can progress to the next stage. This ensures data quality and completeness, which is essential for accurate reporting and forecasting. Making fields required on the layout itself (or conditionally through Dynamic Forms) directly improves the efficiency of the sales team by ensuring all necessary information is captured at the right time, rather than chasing down missing data later.
C. Add a Path component with fields and instructions aligning to stages on the Opportunity: The Path component in Lightning Experience provides a visual guide that helps users navigate the sales process. It can be configured to display key fields and offer "Guidance for Success" for each stage of the opportunity. This improves efficiency by making the sales process clear and easy to follow, and it boosts collaboration by providing a consistent, shared understanding of what needs to happen at each step.

Why other options are incorrect
B. Use two Tabs components to separate record information from activities: While using tabs can help organize a page layout, separating record information from activities is not necessarily the most efficient or collaborative solution. The standard Lightning record page already features an "Activity" tab, so creating an additional tab for this is redundant and doesn't directly address the requirement to improve efficiency and collaboration in a meaningful way.
D. Set up an approval process requiring manager consent at each stage of the Opportunity: An approval process is a complex automation tool designed for formal, documented approvals, not for standard stage progression. Requiring a formal approval at every single stage would introduce significant friction, slow down the sales cycle, and drastically reduce, rather than improve, efficiency. The Path component is the appropriate, lightweight tool for guiding users through the standard sales stages.

Explanation:

Why this is correct
Only Path is stage-aware: you can define Key Fields and Guidance for Success for each Opportunity stage, so reps see exactly which fields to complete as they move through the process. Page layouts, record types, and Process Builder aren’t triggered by stage changes, so they can’t vary required fields per stage in the way the question asks.

Why the others are not ideal
A. Page layout required fields based on the current stage — Page layouts can’t change dynamically by Stage. Required fields on a layout apply at all stages.
B. Process Builder to prompt the user — Process Builder can’t present prompts/UI. (You’d need a Screen Flow, which isn’t an option here.)
C. Record types and page layouts for each stage — Record type doesn’t change automatically when Stage changes, and managing a record type per stage is brittle and not how Salesforce is designed for stage-by-stage guidance.

Explanation:

When processing field updates in Salesforce Workflow Rules and Approval Processes, certain functionalities are bypassed or ignored to ensure the automation executes as intended. The three functionalities ignored are:

B. Field-Level Security (FLS):
Field updates in Workflow Rules and Approval Processes ignore Field-Level Security settings. This means that even if a field is set to read-only or hidden for a user's profile, the field update will still execute and modify the field value. This ensures that automated updates are not blocked by user-level permissions, allowing system-driven changes to occur reliably.
C. Validation Rules:
Validation Rules, which normally prevent invalid data entry based on defined criteria, are ignored during field updates triggered by Workflow Rules and Approval Processes. This allows the automation to update fields without being blocked by validation logic that might otherwise apply to manual edits, ensuring the process completes as designed.
E. Decimal places and character limits:
Field updates in Workflow Rules and Approval Processes do not enforce decimal place precision or character length limits defined in the field’s configuration. For example, if a field is set to allow only two decimal places, a workflow field update might set a value with more decimal places, bypassing the field’s defined constraints.

Why not the other options?
A. Multiple currencies:
Multiple currency settings are not ignored during field updates. Workflow Rules and Approval Processes respect the organization’s currency settings, and field updates on currency fields are processed in the record’s currency or converted appropriately if multiple currencies are enabled. This makes it an incorrect choice.
D. Record type picklist value assignments:
Record type picklist value assignments are not ignored. Field updates respect the picklist values available for the record type of the record being updated. If a field update attempts to set a picklist value not available for the record’s record type, it will fail or select a valid value, so this is not bypassed.

References:
Salesforce Help: Considerations for Field Updates (Confirms that field updates ignore Field-Level Security, validation rules, and field constraints like decimal places and character limits).
Salesforce Trailhead: Automate Business Processes with Workflow Rules (Explains how field updates bypass certain restrictions).
Salesforce Help: Approval Process Considerations (Notes similar behavior for approval process field updates).

Explanation:

Why D is Correct:
To create reports that analyze data based on the presence or absence of a related record (i.e., "with" or "without" reports), you must first define the relationship between the objects in the reporting framework. A standard report type will not include the necessary relationships from your new custom object. A Custom Report Type allows you to explicitly define the primary object (your new custom object) and its relationship to other objects (the two different objects it looks up to). Once this report type is created, it becomes available in the report builder, enabling you to easily add filters like "with [Related Object]" or "without [Related Object]".

Why A is Incorrect:
A Row-Level Formula is used to calculate a value for each row in a report (e.g., calculating a custom ratio). It is a filter and calculation tool used within a report, but it cannot establish the object relationships needed to make "with/without" reporting possible in the first place.

Why B is Incorrect:
A Report Bucket Field is a powerful feature for grouping report values into custom categories (e.g., grouping Opportunity Amount into ranges like "Small," "Medium," "Large"). Like a formula, it is a feature used to analyze data within an existing report and does not define the underlying data structure available for reporting.

Why C is Incorrect:
Report Filters are used to narrow down the records displayed in a report after you have selected a report type. The "with" and "without" filters will only appear as options if the relationship between the objects has been defined in the report type. Without the correct Custom Report Type, these specific filters will not be available.

Reference:
Salesforce Help Article: "Create Custom Report Types." The primary purpose of a custom report type is to "define the set of records and fields available to reports based on the report type" by linking objects together via their relationships. This is a foundational concept for complex reporting in Salesforce.

Explanation:

The Lightning Object Creator is specifically designed for this exact use case: turning a spreadsheet into a custom object in Salesforce, including:

Automatically creating the object and its fields based on spreadsheet columns.
Allowing the data to be imported simultaneously during object creation.
Providing a guided, user-friendly interface ideal for boosting adoption among new users.

This tool is perfect for organizations like Cloud Kicks that want to move away from spreadsheets and encourage Salesforce usage without requiring deep technical expertise.

🔍 Why the other options don’t fit:
A. Import Wizard
Can import data, but does not create objects or fields.
C. Data Loader
Powerful for bulk data import/export, but requires the object and fields to already exist.
D. Schema Builder
Used for visualizing and manually creating objects/fields, but does not import data or work directly with spreadsheets.

🔗 Reference:
Lightning Object Creator Overview – Salesforce Help
Create Custom Objects from Spreadsheets – Trailhead