Free Practice Questions for Salesforce Platform-App-Builder Exam

An indirect lookup relationship is used when an external object must relate to a standard or custom Salesforce object and the external data does not contain Salesforce record IDs. Salesforce requires the parent Salesforce object to contain a custom field marked External ID and Unique . Values from the external object ' s indirect lookup field are matched against this external ID field to establish the relationship. Salesforce specifically states that indirect lookups link a child external object to a parent standard or custom object using a custom unique External ID field. TEXT(Id) does not create such a relationship key, and CASESAFEID() merely converts Salesforce IDs to their 18-character representation. A normal Salesforce Record ID is used for standard lookup relationships, not indirect lookups.

================

The correct answer is C. Internal profiles.

When a new custom field is created using Schema Builder, Salesforce sets field-level security by default as visible and editable for internal profiles. This does not mean every possible profile, such as external/community profiles, automatically gets access. Salesforce Help specifically notes this default behavior for fields created in Schema Builder.

===========

The correct answer is A. Partial Copy.

A sandbox template is used to define which object data is copied into a sandbox. Salesforce documentation states that sandbox templates control what data is copied into Full or Partial Copy sandboxes. Since the question says the app builder created a sandbox template for Accounts, Projects, and Project Milestones, the correct testing environment is Partial Copy because it includes metadata plus a selected sample of production data defined by the sandbox template. Developer, Developer Pro, and Scratch Orgs do not use sandbox templates for selected production data in this way.

===========

The correct answer is C. Two Master-detail relationships on a new custom object.

This is a many-to-many relationship: one Contact can be related to many Solar Projects, and one Solar Project can be related to many Contacts. Salesforce’s standard declarative design for many-to-many relationships is a junction object. A junction object is a custom object with two master-detail relationships connecting the two related objects.

A is incorrect because the two master-detail relationships belong on the new junction object, not directly on Contact and Solar Project.

B can technically relate records, but it is not the standard Salesforce many-to-many model tested here.

D does not correctly create a scalable many-to-many model.

===========

The requirement specifies that a new vendor must accept terms on Agreements before an Opportunity can be closed. Salesforce Approval Processes are the declarative solution for enforcing such business rules. An approval process can:

Require users (vendors) to accept or approve records (Agreements).

Prevent Opportunities from moving to a closed stage until approval is completed.

Send email notifications automatically to approvers.

Salesforce documentation confirms that approval processes are used to enforce conditions on record lifecycle and ensure required steps are completed before record status changes. (Salesforce Help)

A. Email Alert cannot enforce record progression.

B. Dynamic Action only controls field-level UI visibility, not enforcement.

D. Validation Rule could prevent saving a record, but it cannot require explicit approval from a specific user group.

===========

The verified current-platform answer is D. Salesforce Conditional Field Formatting in Lightning App Builder allows Dynamic Forms fields to display configurable icons and colors according to rules and criteria. Critically, Salesforce explicitly supports formula fields when the formula resolves to a supported data type, so the existing formula field can drive the formatting rules. The app builder can configure different icons and icon colors without embedding presentation logic into the formula itself. IMAGE() and CASE() can produce formula-based images, but they are an older technique and do not provide the native Dynamic Forms conditional-formatting capability described by the current platform. Field help is static, and Screen Flow is unnecessarily complex. This corrects the PDF answer key, which lists A; current Salesforce documentation supports D.

================

The correct bulk-safe Flow pattern is to modify each current Case with an Assignment element and add the modified record to a record collection variable. After the Loop finishes, one Update Records element should update the complete collection. Salesforce explicitly warns against putting Get Records, Create Records, Update Records, or Delete Records elements inside loops because repeated SOQL or DML operations can quickly exceed governor limits. Trailhead ' s recommended pattern is to retrieve records before the loop, use assignments while iterating, store changed records in a collection, and perform one database update after the loop. A Collection Filter does not replace the collection used to stage modified records. An Update Records element inside the loop defeats the stated requirement for one database operation. Therefore, Assignment plus a collection variable is the correct architecture.

================

A standard custom Picklist field is the correct data model because each Loyalty Member must have exactly one value from a controlled set: Standard, Plus, or Elite. Salesforce defines a Picklist as a field that lets users select a single value from a predefined list. The value set can be restricted so users cannot introduce inconsistent values outside the administrator-approved choices. Picklists also work naturally with Salesforce reporting, including filtering and grouping by the selected value. A multi-select picklist would incorrectly allow one member to belong to multiple tiers simultaneously. A free-form Text field would permit spelling and capitalization variations that undermine data consistency and reporting. A formula field derives its value from other data rather than allowing users to select one of the defined tier classifications.

================

Current Salesforce functionality makes D. Dynamic Forms the appropriate declarative answer. Lightning App Builder supports visibility rules on Dynamic Forms Field and Field Section components, and Salesforce specifically documents device-based visibility through the Device context. An app builder can therefore configure a section to appear for the required form factor, such as phone or desktop, without developing a custom Lightning Web Component. Record Types determine business processes, picklist availability, and layout assignments; they are not device-detection mechanisms. Traditional Page Layouts likewise do not provide device-specific section visibility. A custom LWC could implement custom form-factor behavior programmatically, but it is unnecessary when Dynamic Forms provides native declarative visibility controls. This is a correction to the PDF answer key, which lists B.

================

Resource is specifically intended for approvers that must be resolved dynamically at runtime. Salesforce ' s Flow Approval Process documentation defines Resource as an approver type that references a variable containing a user ' s username, a public group ' s API name, or a queue ' s API name. At runtime, the associated orchestration resolves the value and determines the appropriate assignee. Therefore, the app builder should store the dynamically determined username in a text variable and select that resource in the approval step. Selecting User would require choosing a predetermined user while designing the approval process, which does not satisfy the runtime requirement. Queue similarly identifies a configured queue rather than dynamically resolving an individual user. A Formula cannot directly substitute for the Approver Type configuration specified by Salesforce ' s Flow Approval Process model.

================