The Salesforce Certified Platform App Builder (Plat-Admn-202) (Platform-App-Builder)

The correct answers are C. Email Alert, D. Task, and E. Outbound Message.

In a standard Salesforce approval process, available approval action types include Email Alerts, Tasks, Field Updates, and Outbound Messages. Since Field Update is not listed in the answer choices, the three valid action types from the options are Email Alert, Task, and Outbound Message. Salesforce documentation identifies approval-process actions around task, email alert, field update, and outbound message automation.

A. Invocable Flow is incorrect because it is not a standard approval-process action type in this exam context.

B. Decision Element is incorrect because Decision is a Flow element, not an approval-process action.

===========

Feed Tracking is the correct feature because Salesforce can automatically generate feed updates when a tracked field changes on a record. Salesforce Help explains that feed tracking detects changes to tracked record fields and posts updates to the feed. It can also be configured for custom objects.

For this scenario, the app builder would track the travel request approval/status field. When the request becomes Approved, Salesforce posts that tracked change automatically on the record feed.

Why others are incorrect:

Auto-response rule sends automatic email responses, mainly for Lead/Case scenarios.

Approval process manages record approval routing, but the feature that creates automatic feed posts for field changes is Feed Tracking.

Feed quick action is manual, not automatic.

===========

The correct answer is B. The deployed permission set will only contain changes related to the change set.

When permission sets are included in change sets, the deployment carries permission settings related to the components included in the change set. The existing permission set in production is not completely overwritten as a whole object, and field-level security changes can be included when the relevant fields are part of the deployment. Salesforce documents permission sets and profile settings as access settings that can be included with change sets.

A is incorrect because the whole permission set is not simply wiped and replaced.

C is incorrect because field-level security can be deployed when included properly.

D is close in plain language, but the more accurate exam answer is that the deployed permission set contains only changes related to the change set.

===========

In the Salesforce mobile app, navigation depends on the Lightning app the user is using. Salesforce documentation states that mobile navigation items depend on the active Lightning app, and when a Lightning app is enabled for desktop and phone, the desktop navigation tabs sync to the mobile navigation menu. Salesforce also notes that different menu configurations cannot simply be set directly for different user types. Therefore, the correct design is to create separate Sales and Marketing Lightning apps with different navigation items, then assign access to the appropriate profiles.

The correct answers are A. Create a master-detail relationship field on Application to Open_Position and B. Create a master-detail relationship field on Application to Job Candidate .

This requirement describes a many-to-many relationship : one Job Candidate can apply for multiple Open Positions, and one Open Position can have multiple Job Candidates. The correct Salesforce design is to use a junction object , which in this case is Application__c .

Salesforce documentation states that many-to-many relationships can be modeled using master-detail relationships between a junction object and the two related objects.

So Application__c should have:

A master-detail relationship to Job_Candidate__c

A master-detail relationship to Open_Position__c

This allows applications to appear on the Job Candidate record and also on the Open Position record.

C and D are incorrect because the relationship fields should be created on the junction object , Application__c , not from the parent objects back to Application.

===========

The correct answer is C. Use Dynamic Forms to display the Years of Previous Experience field if Previous Experience is checked.

This is a conditional field-visibility requirement. Salesforce Dynamic Forms lets app builders manage fields and sections directly in Lightning App Builder and use visibility rules to show users only the fields they need, when they need them.

So the app builder can place the Years of Previous Experience field on the Dynamic Forms-enabled record page and set visibility so it displays only when Previous Experience = True.

A is unnecessary and overcomplicated.

B is incorrect because field dependencies apply to picklists, not checkbox-to-number visibility.

D is incorrect because Visualforce is unnecessary when Dynamic Forms provides a declarative solution.

===========

The correct answers are A. Lightning App Builder and D. Quick Action.

A Lightning component can be exposed for use in Salesforce pages through supported targets such as App Page, Home Page, and Record Page, which are configured through Lightning App Builder. Salesforce developer documentation also confirms that components can be configured as quick actions using targets such as lightning__RecordAction or lightning__GlobalAction .

C. Validation Rule is incorrect because validation rules are business logic formulas, not places where Lightning components are placed or rendered. B. Time Failure is not a valid Salesforce area for using Lightning components based on the given option wording.

The correct answer is D. Create a new text field and import the formula field values in it.

The existing Specialty__c field is a formula field, so users cannot manually edit it. Formula fields calculate their value automatically from other fields. Since Cloud Kicks now wants Opportunity Specialty__c values to be different from the related Account value, the app builder should create a new editable field, such as a Text field, and then load the existing calculated formula values into that new field for existing Opportunity records.

This preserves historical Opportunity values while allowing sales reps to enter or update Specialty values going forward. Salesforce documentation explains that roll-up/formula-style calculated values are system-derived, while changing custom field types has limitations and requires care when data must be preserved.

A and B are incorrect because a formula field cannot simply become an editable text field while safely preserving all existing calculated values.

C is incomplete because creating a new text field without importing the existing formula values does not preserve the current values on existing Opportunities.

===========

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.

===========