Platform-App-Builder Practice Test Questions

Explanation:

Why:
Create an Update a Record quick action on the Account object (include the Account fields the user should edit). Then add a Related Record component to the Opportunity Lightning record page, point it at the AccountId lookup, and select that update action. This lets users edit the parent Account directly from the Opportunity page.

Why not the others:
B. Details component only edits the current record (Opportunity), not the related Account.
C. Formula fields are read-only—no editing.
D. Process/flow updates are automation, not a UI for the user to directly edit the Account.

Explanation:

Universal Containers (UC) needs a custom component built within a tight 4-week timeline, but their developers are backlogged for months and require additional enablement. An AppExchange solution is the most suitable option to meet this time-sensitive requirement, as it allows UC to leverage pre-built, third-party components or applications that can be quickly installed and configured, bypassing the need for extensive custom development.

A. Use an AppExchange solution (Correct):
The AppExchange is Salesforce’s marketplace for pre-built apps, components, and solutions created by Salesforce partners or ISVs (Independent Software Vendors). These solutions can often be installed and configured quickly, meeting UC’s 4-week timeline without requiring significant developer effort. AppExchange solutions can range from free to paid and often include components that address common business needs, reducing the need for custom coding and enabling faster deployment.
This option is ideal given the developer backlog and the need for additional enablement, as many AppExchange solutions come with documentation, support, and configuration options that non-developers (like app builders) can utilize.
Reference: Salesforce Help - AppExchange Overview

Why not the other options?
B. Build a screen flow page (Incorrect):
While Screen Flows are powerful for creating guided user experiences, building a custom component using flows still requires significant design and configuration effort. Given the developer backlog and the need for additional enablement, creating a flow from scratch within 4 weeks may not be feasible, especially if the component is complex.
Reference: Salesforce Help - Screen Flows

C. Build a Lightning record page (Incorrect):
Creating a Lightning Record Page involves customizing the user interface for a specific object using the Lightning App Builder. While this is within an app builder’s skill set, it does not address the creation of a custom component (e.g., custom logic, functionality, or reusable code). Building a record page from scratch would also require developer input for any custom components, which is not viable given the backlog and timeline.
Reference: Salesforce Help - Lightning Record Pages

D. Use a Boit solution (Incorrect):
The term “Boit solution” appears to be a typo or misinterpretation in the context of Salesforce, likely intended to mean “Bolt solution” (Salesforce Bolt solutions are pre-built industry-specific templates). However, even if corrected to “Bolt solution,” this option is not ideal. Bolt solutions are typically industry-specific and may not address UC’s specific custom component needs. Additionally, Bolt solutions are less common and not as broadly applicable as AppExchange solutions for general custom component requirements.
Reference: Salesforce Help - Salesforce Industry Solutions

Recommended Approach:
Visit the AppExchange (accessible via Salesforce or at appexchange.salesforce.com).
Search for solutions or components that match UC’s requirements for the custom component. Evaluate options based on functionality, reviews, cost (free vs. paid), and compatibility with UC’s Salesforce org.
Install the solution in a sandbox for testing, then configure it to meet specific needs within the 4-week timeline.
Work with the provider’s documentation or support team to ensure proper setup without requiring extensive developer involvement.

Additional Notes:
AppExchange solutions can include managed packages, unmanaged packages, Lightning components, or flows, many of which are designed to be plug-and-play or easily configurable by app builders, aligning with UC’s resource constraints.
If no AppExchange solution fully meets the requirements, a partially suitable solution can often be customized more quickly than building from scratch, still addressing the time-sensitive need.
The app builder should verify licensing costs and security compliance (e.g., passing Salesforce’s security review) when selecting an AppExchange solution.

Reference:
Salesforce Trailhead: Explore AppExchange
Salesforce Help: Install a Package from AppExchange

Explanation:

Why these work
A. Workflow rule + Outbound Message:
A classic, point-and-click way to notify an external service when an Opportunity becomes Won. Outbound Messages send a SOAP message to a configured endpoint and Salesforce automatically retries on failure.

C. Process + Apex code:
A Process (Process Builder) can invoke Invocable Apex, and Apex can make HTTP(S) callouts to external web services—great if you need REST/JSON, custom headers, or more control.

Why not the others
B. Flow + Outbound Message:
Technically possible today—Outbound Message is now a core action in Flow Builder—but the question asks for two, and the exam’s expected pair here is A & C. If you see this on a newer exam variant, note that Flow + OM also satisfies the requirement.
D. Process + Outbound Message:
Not supported—Outbound Messages can be associated with flows, workflow rules, approval processes, or entitlement processes, but not Process Builder.

References
Salesforce Help: Outbound Message Actions (what they are, where they’re supported).
Salesforce Help: Considerations for Outbound Messages (delivery/retries).
Salesforce Help: Call Apex Code from a Process (Apex action in Process Builder).
Salesforce Docs: Apex Callouts (invoke external web/HTTP services).
Salesforce Release Notes: Outbound Message as a Flow action (FYI for modern orgs).

Explanation:

Automating permission set assignment for new users is a common requirement. The key is to use tools that can not only detect the creation of a User record but also perform the specific action of assigning a permission set.

Why B is Correct:
A record-triggered flow can be built on the User object. This flow can be configured to run when a user record is created. Within the flow, you can use the Assign Permission Sets action (a standard flow action) to assign the specific permission set to the new user. This is a fully declarative and modern solution.

Why C is Correct:
"Lightning Process" refers to Process Builder. A Process Builder process can be created on the User object, triggered when a user is created. The immediate action of this process can be to launch a flow. The flow launched would be the one described in option B, containing the "Assign Permission Sets" action. This is also a valid, though slightly more indirect, declarative solution.

Why A is Incorrect:
An approval process is designed to manage a multi-step review and approval for records. It is not an automation tool for directly performing actions like assigning a permission set. This is the wrong tool for the job.

Why D is Incorrect:
A workflow rule on the User object can detect when a user is created. However, the standard out-of-the-box actions for a workflow rule are limited to email alerts, field updates, and outbound messages. Workflow rules cannot assign permission sets. This capability was introduced in the more modern automation tools like Flow and Process Builder.

Reference:
Salesforce Help - "Assign Permission Sets in a Flow". The documentation confirms that the AssignPermissionSet action is available in Flow, which is the engine behind both the direct Flow (B) and the Process Builder-triggered Flow (C) solutions.

Explanation:

DreamHouse Realty wants each team member to begin small projects in their own sandbox before moving into shared environments like partial or full sandboxes. The key requirements here are:
Low cost
Individual use
Quick setup
Basic development and testing
🔹 Developer Sandbox is ideal for this:
It’s lightweight and cost-effective
Provides a copy of metadata only (no data)
Perfect for unit testing, configuration, and development
Refreshes quickly and can be spun up for each team member

❌ Why the other options don’t work:
A. Full sandbox
Too resource-intensive and expensive for individual use; meant for performance testing and staging
C. Developer pro sandbox
Similar to Developer sandbox but with more storage — useful for larger dev tasks, but not necessary for small projects
D. Partial sandbox
Includes sample data and is better suited for integration or UAT testing, not individual dev work

🔗 References:
Salesforce Help: Sandbox Types and Considerations
Trailhead: Application Lifecycle and Sandbox Strategy

Explanation:

A validation rule on the Contact object is the correct solution for this conditional requirement. The validation rule can use a cross-object formula to check the value of the Customer Status field on the parent Account record.
The formula would look something like ISPICKVAL(Account.Customer_Status__c, 'High Priority') && ISBLANK(Region__c).
This formula will return TRUE (and prevent the record from saving) if both conditions are met: the associated Account is 'High Priority' AND the Contact's Region field is blank.

Why other options are incorrect
A. Make the Region field required on Contact:
This would make the field required for all Contact records, regardless of the Account's priority, which does not meet the specific condition requested.
C. Create 4 validation rule on Account:
The validation needs to happen on the Contact record, as that is where the required field (Region) is located. A validation rule on the Account object cannot prevent a Contact from being saved.
D. Make the Customer Status field required or Account:
This would ensure the Customer Status field is filled out on the Account, but it would not enforce the conditional requirement for the Region field on the Contact.

Explanation:

Why these work
A. Big objects: Built for archiving massive/historical datasets without consuming your standard data storage. You can query them with SOQL/Async SOQL and they support certain field types including Lookup (from the big object to standard/custom objects). Standard reporting isn’t built directly on big objects; the recommended pattern is to use Async SOQL to extract a working subset into a (custom) reporting object or analytics dataset for dashboards, while keeping the archive in the big object.
D. External objects (Salesforce Connect): Keep archived data outside Salesforce (so it doesn’t count toward org storage) but still surface it in Salesforce as External Objects. These support reports (with limits), SOQL queries, and lookup-style relationships (External Lookup/Indirect Lookup) so users can relate archived records to Salesforce data and run reports on them.

Why not the others
B. Custom objects: Data would still live in Salesforce, so this doesn’t alleviate storage limits.
C. Related objects: Not an archiving mechanism—just a generic term for relationships.

References
Big Objects: Implementation guide & capabilities; querying & reporting guidance.
External Objects / Salesforce Connect: Reporting support; relationships; behavior.

Explanation:

The TODAY() function returns the current date, ideal for calculating whole days elapsed since a marketing communication was sent (e.g., TODAY() - Last_Communication_Sent__c). It ensures a whole number result, meeting the requirement for whole units.

A. DATETIMEVALUE(): Converts text to DateTime, not needed for current date.
C. DATEVALUE(): Converts DateTime/text to Date, unnecessary since TODAY() is simpler.
D. NOW(): Returns current date and time, producing decimal days, not whole units.

Reference:
Salesforce Help - TODAY()

Explanation:

Deploying a Lightning record page (often referred to as a "detail page layout" in the context of Lightning Experience) requires deploying all its dependent components to ensure it works correctly in the target org.

Why A is Correct:
The Detail page layout (officially called a Lightning Page) is the primary component you intend to deploy. This is the core item that must be included in the Change Set.

Why B is Correct:
If your page layout contains any custom fields, those fields must also be deployed. If the custom fields do not exist in the production org, the page layout will fail to load or will show errors for those missing fields. The deployment of the page layout will likely fail during validation if its dependent fields are missing.

Why C is Correct:
If you have added any custom actions (like an update record action) to the page's publisher layout, those actions must be deployed. The page layout references these actions. If they are missing in production, those specific components will not appear or function on the page.

Why D is Incorrect:
Lightning App Builder is the tool used to create and edit Lightning Pages. It is not a deployable component itself; it is a feature of the Salesforce platform. You deploy the output of the tool (the Lightning Page), not the tool.

Why E is Incorrect:
While profile settings control who can see the page layout, the System Administrator profile itself is not a component you include in a Change Set to make the page layout deploy or render correctly. Profile visibility for the page is handled by the page's assignment (which is part of the page deployment) or by permission sets. You do not deploy entire profiles for this purpose.

Reference:
Salesforce Help - "Change Sets Overview" and "Deploy Lightning Page Resources". The key principle is that when deploying any component, you must also deploy all its dependencies—the other metadata components it relies on to function. For a Lightning Page, this includes the fields, actions, and any other custom components placed on it.

Explanation:

Universal Containers currently has Accounts set with Organization-Wide Defaults (OWD) as Public Read Only, meaning all users can read all Accounts, but only owners can edit them. The requirement is to restrict VIP Accounts so that only their owners have read access (and, by extension, edit access, as owners already have edit rights). This involves modifying access controls to limit visibility for specific Accounts. Below is a concise analysis:

A. Implement a sharing rule (Correct):
A criteria-based sharing rule can be used to grant read access to VIP Accounts only to their owners. Since the OWD is Public Read Only, a sharing rule can override this for VIP Accounts (identified by a field, e.g., VIP_Account__c = true) to ensure only owners have access. This requires first setting the OWD to Private (see option D) to restrict general access, then using the sharing rule to reinforce owner-only access.
Steps: Create a sharing rule for Accounts where VIP_Account__c = true, sharing with the owner (or a public group containing only the owner, if needed).
Reference: Salesforce Help - Sharing Rules

B. Configure a permission set (Incorrect):
Permission Sets control object-level, field-level, or app permissions, not record-level access. They cannot restrict read access to specific records like VIP Accounts for non-owners. Permission Sets are better suited for granting additional access, not limiting it based on record criteria.
Reference: Salesforce Help - Permission Sets

C. Set up an Account Team (Incorrect):
Account Teams allow specific users (e.g., team members) to be granted access to Accounts, but they are designed to expand access, not restrict it to only the owner. Setting up an Account Team would not prevent other users from reading VIP Accounts if the OWD is Public Read Only.
Reference: Salesforce Help - Account Teams

D. Change organization-wide defaults (Correct):
To ensure only Account owners have read access to VIP Accounts, the OWD for Accounts must be changed to Private. This restricts all users except owners (and those with higher hierarchy access or sharing rules) from reading any Accounts. Then, for non-VIP Accounts, a sharing rule can restore Public Read Only access, while VIP Accounts remain restricted to owners. Steps: Set Account OWD to Private in Setup > Security > Sharing Settings, then create a sharing rule for non-VIP Accounts (e.g., VIP_Account__c = false) to grant read access to all users.
Reference: Salesforce Help - Organization-Wide Defaults

Recommended Approach:
Change the OWD for Accounts to Private to restrict read access to owners only. Create a criteria-based sharing rule for non-VIP Accounts (e.g., VIP_Account__c = false) to grant read access to all users, restoring the original Public Read Only behavior for non-VIP Accounts. Optionally, create a sharing rule for VIP Accounts to explicitly reinforce owner-only access, though the Private OWD may suffice if no additional sharing is needed.

Notes:
Assumes a custom field (e.g., VIP_Account__c) exists to identify VIP Accounts.
If role hierarchy grants access to managers, ensure VIP Accounts are not inadvertently shared; adjust hierarchy or use manual sharing if needed.
This approach maintains edit access for owners while restricting read access for VIP Accounts.

References:
Salesforce Trailhead: Data Security
Salesforce Help: Sharing Rules