Pass the Salesforce App Builder Platform-App-Builder Questions and answers with CertsForce

The correct answers are A. Detail page layout, B. Custom actions, and D. Custom fields.

To deploy a new Account detail page layout successfully and make it look the same in production, the change set must include the actual page layout plus the components used on that layout.

Salesforce page layouts control the arrangement of fields, actions, buttons, and related lists on record detail pages. Therefore, if the layout uses new custom fields or custom actions, those components must also exist in production or be included in the change set. Salesforce change set guidance also notes that custom fields must be added individually when deploying customizations.

C. System administrator profile is not required just to deploy the visual layout. Profiles are only relevant if deploying access settings or layout assignments.

E. Lightning App Builder is not the component needed for a standard detail page layout; a Lightning Record Page would be a different metadata component.

The correct answers are A. Dynamic Actions and C. Approval Process.

An Approval Process is required because sales managers must provide formal sign off when an Opportunity discount meets the defined criteria. Salesforce approval processes define the criteria a record must meet, the steps required for approval, and who must approve it.

Dynamic Actions are also needed because Universal Containers wants the sign-off action available quickly from the Opportunity record page. Dynamic Actions let app builders control which actions appear on Lightning record pages based on conditions.

Why others are incorrect:

Schema Builder is for data model design, not approval/sign-off UI behavior.

Validation Rule can block invalid data, but it does not provide manager approval or sign-off.

===========

The correct solution is to configure validation rules with help text/error messaging.

Validation rules are the right tool because they evaluate record data before save and stop the save when the record does not meet the defined conditions. They can enforce that a Case status is not changed back to an earlier value by using formula logic such as PRIORVALUE() and picklist checks. They can also require certain fields only when specific Case criteria are met by checking whether those fields are blank under those conditions.

Why the other options are wrong:

Dependent picklists control valid picklist values, but they do not enforce status progression or conditional required fields across all save paths. Approval processes are not the best fit for real-time save validation. Page layout required fields are UI-level requirements and are not flexible enough for criteria-based enforcement.

The correct answer is A.

UC has three Lead sources: web, trade shows, and partners. Some Lead information is common to all, while other fields are unique to each source. The best configuration is to use Lead record types with separate page layouts so each type of Lead shows the fields relevant to that process. Salesforce documentation states that record types allow different business processes, picklist values, and page layouts for different users or record categories.

B is not ideal because it leaves irrelevant fields visible and relies on users to collapse sections. C unnecessarily creates a different Lead object for the partner community. D is incorrect because separate custom objects would fragment Lead management and prevent standard Lead functionality from being used consistently.

===========

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

This requirement is a many-to-many relationship: one Contact can relate to many Solar Projects, and one Solar Project can relate to many Contacts. Salesforce models this with a junction object, which is a custom object with two master-detail relationships.

A simple lookup on one object would not properly support the many-to-many data model.

===========

The correct answer is D. Unable to reference the child records.

Formula fields can reference fields from related parent records using cross-object formulas, but they cannot directly pull values from multiple child records onto a parent record. Salesforce describes cross-object formulas as formulas that can reference fields from a parent object when the formula is created on the child/detail side of the relationship.

In this case, Account is the parent and Contacts are child records. Since the formula is being created on Account and trying to reference related Contacts, the relationship does not appear in the formula editor.

Correct design alternatives: use a roll-up summary where supported, Flow, Apex, or reporting.

===========

The correct answer is B. Flow.

The requirement is to show the number of open Cases for both the Account and the Parent Account. This is not a simple native roll-up summary scenario because standard roll-up summary fields are mainly for master-detail relationships, while lookup relationships do not support standard roll-up summary fields.

Salesforce specifically documents Flow examples where a flow looks up the parent account, checks how many open cases it has, and evaluates that count. Salesforce also has guidance for creating roll-up-style summaries using Flow, including a use case to count Cases related to an Account.

Why others are incorrect:

A. Approval Process is for approvals, not counting open Cases.

C. Custom object is unnecessary.

D. Roll-up summary is not the best fit for counting Cases across Account and Parent Account relationships.

===========

The correct answers are B. Set organization-wide default to Private, D. Disable Grant Access Using Hierarchies, and E. Create a criteria-based Sharing Rule for the HR Department.

Set the Review object’s OWD to Private so review records are not visible to all employees by default. Organization-wide defaults define the baseline record access users have to records they do not own.

Disable Grant Access Using Hierarchies because this is a custom object and the requirement says only HR and the submitting employee should see the review. Salesforce allows this setting to be disabled for custom objects so managers higher in the role hierarchy do not automatically inherit access.

Create a criteria-based sharing rule for the HR department so HR can see the Review records even though the default access is private. Salesforce sharing rules are used to grant wider access beyond OWD.

Why others are incorrect:

A is not needed and a Master-Detail relationship to User is not the right access-control design.

C is incorrect because removing Review Read permission from non-HR users would also prevent the submitting employee from viewing their own submitted review.

===========

The correct answer is B, based on the intended Salesforce wording.

In a private data model, users normally access records they own or records shared with them. Salesforce role hierarchy opens record access upward: users higher in the hierarchy can view, edit, and report on records owned by users below them, depending on object permissions and hierarchy settings.

Because the Service Coordinator needs access to work orders and related records owned by technicians, placing the SC above the technicians in the role hierarchy gives the required record access without granting excessive org-wide permissions.

Why others are incorrect:

Modify All Data is too broad.

Modify All on Work Order only applies to that object and does not solve access to other related technician-owned records.

Workflow does not grant record access.

===========

A managed package is designed for distributable Salesforce solutions whose components can be maintained and upgraded by the package provider. Salesforce states that managed packages provide fully upgradeable application resources, and AgentExchange guidance distinguishes them from unmanaged packages by specifically noting that providers can automatically upgrade managed solutions. This makes a managed package appropriate when Universal Containers wants a complete preconfigured application while minimizing ongoing manual maintenance. An unmanaged package provides editable components but does not have the same provider-managed upgrade mechanism; receiving a newer unmanaged version generally requires replacement or reinstallation. A change set transfers metadata between related Salesforce orgs and is not an AgentExchange distribution package. A data kit is not the package type used to deliver an upgradeable Salesforce application.

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