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

The correct answers are A. Create owner-based sharing rules that give Read access to the master objects and C. Set Sharing Settings to Read Only on both Master-Detail relationship fields.

A junction object is normally created with two master-detail relationships to represent a many-to-many relationship. Salesforce documentation states that sharing access to a junction object record is determined by the user’s access to both associated master records and the Sharing Setting option on the master-detail relationship fields.

Because the master objects, Seminars and Attendees, have private organization-wide defaults, selected users need record access to those master records. Owner-based sharing rules can grant the selected group Read access to the master object records. Salesforce also documents that organization-wide defaults define baseline record access, and sharing rules are used to extend access when defaults are private or restricted.

The Read Only sharing setting on the master-detail relationship allows users with at least read access to the master records to work with related detail records, assuming they also have the required object permissions on the junction object.

B is incorrect because lookup filters restrict selectable related records; they do not grant record access.

D is incorrect because junction object records in master-detail relationships inherit sharing from the master records. Sharing is not handled directly through an owner-based sharing rule on the junction object.

==========

A Screen Flow is the best declarative tool when the user must answer questions through a guided UI and use those answers to update record fields. Salesforce documents that screen flows provide a UI that guides users through a business process, and they can be launched from quick actions or Lightning pages.

A custom button or action can launch the flow, collect the extra approval-related information, update the Account fields, and then continue the approval submission logic.

Why not others:

A. Custom object only stores data; it does not provide the popup/question flow.

B. Visualforce could be custom-coded, but Flow is the declarative App Builder solution.

D. Custom Lightning component requires development and is not the best declarative answer.

===========

The correct answers are C. The report is in the manager’s Private reports folder and D. The report does not have a chart.

The Report Chart component is used to display a chart from a report on a Lightning page. If the report has no chart, it cannot be used as a Report Chart component source. Salesforce documentation describes the Report Chart component as a way to include a chart from a report in a Lightning page.

The app builder also must have access to the report through report folder sharing. Reports saved in a user’s private report folder are not visible to other users unless moved/shared appropriately. Salesforce explains that reports are saved by default into private reports or dashboards folders unless a public/custom folder is selected.

A is incorrect because a report having no returned data does not stop the report from being selectable. B is incorrect because the app builder does not need to be the report creator; they need access to the report folder and the report must contain a chart.

===========

Grouping is the correct reporting capability because the requirement is to compare Case counts across two categorical dimensions: Status and Priority. Salesforce reports support grouping records by rows and columns. The app builder can group Cases by Status and then by Priority, or configure a matrix-style report using one field for row grouping and another for column grouping. The resulting subtotals and grand totals make the comparison immediately visible. Filters determine which records are included but do not organize the resulting records into comparison categories. Bucket columns are useful for creating temporary categories without adding Salesforce fields, but Status and Priority already provide the required categories. A custom report type controls which related objects and fields are available, not how existing Case records are grouped.

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

The correct answer is C. The user wants to update the related Account directly from the Opportunity page. The proper declarative solution is to create an Update a Record quick action for Account and expose it through the Related Record component on the Opportunity Lightning record page. Salesforce documentation identifies Related Record as a standard Lightning page component and notes that quick actions such as Create a Record and Update a Record are supported in Lightning page experiences.

Why others are incorrect:

A updates fields through automation, but the user wants to edit directly.

B formula fields are read-only.

D the Record Detail component is for the current record, not editing a related Account from Opportunity.

===========

The correct answers are A. Create an object-specific action on Account and D. Create predefined values for most of the fields.

For this requirement, sales reps need to create a custom Feedback record related to an Account with minimal clicks on mobile. An object-specific quick action is the best solution because it runs in the context of a specific Account record and can create a related child record automatically. Salesforce Trailhead states that object-specific actions let users create records with automatic relationships to other records and provide a streamlined mobile and desktop experience.

Predefined field values reduce manual typing and save mobile users time. Salesforce mobile customization guidance explains that quick actions can include predefined fields, and Trailhead specifically shows predefined values being used to prepopulate fields on action layouts.

B. Create a feedback object as a parent of Account is incorrect because the Feedback record should be related to each Account, normally as a child record or lookup-related record. C. Create a global action on Account is incorrect because global actions create records without record context; Salesforce explains that global actions create records with no relationship to other records, while object-specific actions work in the context of a particular object.

===========

The correct answer is D. Approval process with a record-triggered flow.

Salesforce does not provide a simple “approval before delete” button behavior by default. The practical declarative pattern is to use an Approval Process for manager permission and a record-triggered Flow to automate the submit/delete logic. Flow includes a Submit for Approval action for Classic Approval Processes and also supports deleting records through the Delete Records element.

Why not the others:

A two-step approval process only handles approval routing; it does not complete the deletion automation by itself. A scheduled path or schedule-triggered flow is not appropriate because this is based on a user’s delete request, not a time-based batch process.

===========

The correct answer is D. Create both customer and dealer as accounts, add each rep as a contact on the corresponding account and create an account hierarchy.

Universal Containers needs to represent separate business entities because separate bills are sent to each customer and each dealer. In Salesforce, business accounts are used to represent companies or organizations, and contacts represent the people who work for those accounts. Salesforce account hierarchies are used to show relationships between related accounts through the Parent Account field.

So the best model is:

Customer = Account

Dealer = Account

Representative at each business = Contact on that Account

Customer/dealer relationship = Account Hierarchy

A is incorrect because Account Teams represent internal Salesforce users working on an account, not external dealer/customer representatives.

B and C are incorrect because they do not correctly represent separate billing entities as separate Accounts.

===========

Limitations when changing custom field data types include:

A. It is not possible to change the data type of a formula field – formula fields cannot be converted to other field types because they are calculated dynamically.

D. It is not possible to change a Text Area (Long) field to Text – Salesforce prevents reducing the field length because data loss could occur.

Salesforce documentation highlights these restrictions: (Salesforce Help)

B is partially true; changing fields referenced in Apex requires careful handling, but Apex references can sometimes be updated automatically.

C is allowed with some limitations if the External ID type is compatible.

===========

The correct answer is C. Custom object with Master-detail field to Opportunity.

AW Computing needs many help requests related to one Opportunity, so the help request should be a custom child object under Opportunity. Because the Opportunity page must show the most recent request date, the app builder needs a Roll-Up Summary field on Opportunity using MAX on the request date field.

Salesforce roll-up summary fields work on the master side of a master-detail relationship, and MAX can be used for date/date-time fields.

A is backward because the master-detail field belongs on the child object, not Opportunity.

B and D use lookup relationships, which do not support standard roll-up summary fields.

===========