Platform-App-Builder Salesforce Certified Platform App Builder (Plat-Admn-202) Questions and Answers

The correct answer is A. The requirement is to combine four custom text fields into one formula field and display the result on two lines.

The formula works as follows:

Street__c displays the street on the first line.

BR() inserts a line break. Salesforce documents the BR formula function as inserting a line break in a text string.

City__c & " , " & Planet__c & " " & Galaxy__c displays the remaining location information on the second line. The & operator connects two or more strings in Salesforce formulas.

Why others are incorrect:

Options using field names without __c are not correct for custom fields. Options using __r are relationship references, not direct custom field references. Options without BR() do not satisfy the two-line requirement.

===========

The correct answers are A. Use a master-detail relationship between the Park and Trail objects and C. Use a roll-up summary field on the Park record to show the total number of trails .

To show the total number of child Trail records on the parent Park record without code, the app builder should use a roll-up summary field . Salesforce documentation states that roll-up summary fields display values on a master record based on related detail records.

That means Park should be the master object and Trail should be the detail object. Then a roll-up summary field on Park can count the related Trail records.

B is incorrect because standard lookup relationships do not support roll-up summary fields.

D is incorrect because a formula field cannot count multiple child records.

===========

The correct answer is D. Flow.

The requirement is to automatically clear the Phone field on Contact when the Do Not Call checkbox is checked. A record-triggered Flow can run when a Contact is created or updated, check whether Do_Not_Call is true, and then update the triggering Contact record by setting the Phone field to blank. Salesforce Flow supports updating records, including directly updating the record that triggered the flow.

B. Validation rule is incorrect because it can block a save but cannot delete or clear the Phone field automatically.

C. Quick action is manual, not automatic.

A. If-then rule is not the best current Salesforce automation tool for this requirement.

===========

The correct answer is C.

The app builder needs to display only the first five digits from the parent Account’s ZIP+4 custom text field. Salesforce’s LEFT() function returns a specified number of characters from the beginning of a text string, so the correct formula is:

LEFT(Account.Zip_Code__c, 5)

Salesforce formula documentation confirms that LEFT returns characters from the beginning of a text string.

BEGINS() checks whether text starts with specific characters. LPAD() pads text to a specified length. TEXT() converts certain data types to text, but it does not extract the first five characters.

===========

The correct answer is C. Add the standard Chatter feed component.

To add Chatter feed functionality to a custom object Lightning record page, the app builder should use the standard Chatter component in Lightning App Builder. Salesforce documentation states that the Feed component was renamed Chatter in Lightning App Builder and is used to place the publisher and feed combination on a record page.

A is incorrect because no custom Chatter feed component is required. B is incorrect because related lists do not add the Chatter feed. D is incorrect because the standard Chatter component is already available; an AppExchange component is unnecessary.

===========

The correct answers are A. Set up new public Chatter groups and D. Use post action on the Account object.

Public Chatter groups support open collaboration where company users can share information in a group feed. Salesforce Chatter groups are designed for teams to share information, files, and discussions.

Post action on the Account object allows users to discuss customer accounts directly from the Account record feed. Salesforce Chatter feeds appear on record pages and allow users to follow records and see updates about them.

Why others are incorrect:

Private Chatter groups are not suitable because CK wants all company employees to see the conversations.

Chatter actions to create tasks help assign work, but they do not primarily solve open company-wide collaboration around accounts.

===========

The correct answer is C.

A Partial Copy sandbox uses a sandbox template to determine which objects and data are copied from production. Salesforce states that sandbox templates let admins select specific objects and data to copy to a Full or Partial Copy sandbox. If the custom object Shipping was not included in the sandbox template, its production records would not be copied into the refreshed partial sandbox.

Why others are incorrect:

A is not the likely issue; refresh timing does not explain one object having no data.

B is less likely as the scenario points to template selection.

D is not the best answer because capacity may limit copied data, but missing all data for a specific object usually indicates the object was not selected in the sandbox template.

===========

The five permissions common to the entire department should be bundled into a permission set group. Salesforce defines permission set groups as a mechanism for combining multiple permission sets around a job persona or role, simplifying assignment and ongoing maintenance. Users assigned to the group receive the combined permissions from its component permission sets. Higher-level staff can then receive the same permission set group plus additional individual permission sets that represent their extra responsibilities. This avoids repeatedly assigning the same five permission sets one-by-one and supports least-privilege access. Data Import Wizard is not the standard administration mechanism for permission-set assignments, and Data Loader is unnecessary for the described configuration. The Manage Assignments approach with a permission set group plus individual exceptions provides the cleanest scalable permissions model.

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

The correct answer is A.

When custom tabs are deployed through change sets without profile settings or permission sets, the deployed custom tabs are hidden by default for all users. Salesforce Help states that deployed custom tabs are hidden by default unless the change set also includes profiles that set the tab visibility.

Tab visibility is controlled through profile or permission set tab settings such as Default On, Default Off, and Tab Hidden.

Why others are incorrect:

B and C are incorrect because the tabs are not automatically default off or default on for all users.

D is incorrect because the custom tabs are deployed; they are just not visible until access is configured.

===========

The correct answers are C. Custom object, D. Apex class, and E. Custom field.

Change sets are used to move metadata between related Salesforce environments, such as sandbox and production. Salesforce documentation confirms that change sets can migrate components such as custom objects, custom fields, and Apex classes. Salesforce also notes that custom fields can be migrated individually in a change set.

A. Web-to-lead is not one of the common metadata components normally selected as an item in this exam context. B. Standard fields are standard Salesforce metadata and are not moved like custom fields in change sets.

===========

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

Customers and dealers are both separate business entities, and separate bills are sent to each. In Salesforce, business entities are best represented as Accounts, while the single individual at each business should be stored as a Contact under the correct Account. Salesforce account hierarchy is used to show parent-child relationships between related accounts.

Why not D? Account Teams represent internal Salesforce users working on an account, not external customer/dealer representation.

The correct answer is A. Sharing rules.

Because the Account OWD is Private, users can’t automatically see records owned by users in another branch of the role hierarchy. Salesforce sharing rules are used to extend record access beyond the organization-wide default and role hierarchy. Salesforce documentation states that sharing rules grant additional access to users in public groups, roles, or territories.

Why others are incorrect:

B. Public groups can be used inside a sharing rule, but the public group alone does not share records.

C. Aliases are user display shortcuts, not security controls.

D. Assignment rules assign records; they do not grant cross-team record visibility.

===========

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.

===========

The correct answer is B. Cross-object formula.

Opportunity has a standard relationship to Account, so an app builder can create a formula field on Opportunity that references the parent Account field. Salesforce defines a cross-object formula as a formula that spans related objects and references fields on those related objects.

Because Account_Region__c is a picklist on Account, the Opportunity formula would commonly be a text formula like:

TEXT(Account.Account_Region__c)

Field history tracking only tracks changes, a lookup field would create a relationship rather than display the Account field value, and field-level security controls visibility but does not copy or display the parent field on Opportunity.

===========

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.

===========

The correct answer is C.

The Lightning record page already supports both mobile and desktop, but the downloaded custom component is not visible on mobile. That points to the component itself, not the page activation. Lightning components must be configured to support the required form factors. Salesforce developer documentation explains that components can be configured for desktop form factor Large, phone form factor Small, or both.

So, if the AppExchange component was built only for desktop pages or only supports the large form factor, users cannot view it in the Salesforce mobile app.

A and D are incorrect because the issue is not page activation if the page already supports mobile and desktop. B is incorrect because the scenario states the record page supports both mobile app and desktop.

===========

This question is testing the classic Salesforce Process Builder automation best practice , not a generic Flow-only rule. Salesforce’s official process design guidance states that an org should have only one record-change process per object . The reason is simple: every time a record is created or updated, Salesforce evaluates the record-change processes for that object. If an object has multiple record-change processes, the automation becomes harder to predict, harder to troubleshoot, and more likely to hit governor limits. Salesforce specifically explains that consolidating automation into one record-change process gives admins a single view of all criteria and actions for that object, reduces duplicated automation overhead, and allows the app builder to control the order of criteria evaluation.

A is not the best exam answer here. In modern Flow architecture, “one Flow per object” is often discussed as a design pattern, but it is not the exact best-practice wording being tested by this Platform App Builder-style question. Salesforce Flow design is more nuanced today because record-triggered flows can vary by trigger timing and event. B is wrong because validation rules should be separated by validation requirement, not forced into one rule per object. C is wrong because invocable processes are reusable modular processes, not the main record-change automation container.

The correct answer is A. Highlights panel.

In Lightning Experience, record actions such as New Task appear in the Highlights Panel area of the Lightning record page. Salesforce documentation explains that the actions in the highlights panel come from the object’s page layout, specifically the Salesforce Mobile and Lightning Experience Actions section, unless dynamic actions are enabled.

Since the custom action was already added to the Mobile & Lightning Actions section on the page layouts, the app builder must add the Highlights Panel component to display those actions on the Lightning record page.

Activities shows activity timeline/composer-related functionality, but it is not where page-layout actions are generally displayed. Related Lists and Related Record do not display the main action bar.

===========

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.

A roll-up summary field requires a master-detail relationship. Since Galaxy__c and Star__c currently have a lookup relationship, the app builder cannot create a standard roll-up summary field to count related Star__c records. The lookup must be converted to master-detail first, with Galaxy__c as the master and Star__c as the detail. Salesforce Trailhead confirms that roll-up summary fields display values on the master record based on directly related detail records in a master-detail relationship.

===========

Users need Read access to both master objects.

Request Inventory is a junction object with two master-detail relationships: Inventory and Order. For junction objects, access is based on the associated master records and the sharing behavior of the master-detail relationships. Salesforce documentation for object relationship considerations explains that sharing access to a junction object record is determined by access to both associated master records.

Why not the others? Sharing rules are not created directly on a master-detail detail object in the same way, because it is controlled by parent. Apex-based sharing is not needed. Read access to only the first master object is not enough because the junction record connects two master records.

===========

The correct answer is A. Sharing Hierarchy.

Sales reps want to see who has access to an Account record and why/how they have that access. Salesforce provides this through Sharing Hierarchy. Salesforce documentation states that users can click Sharing Hierarchy from the record action menu to display users who have access to the record. Salesforce release documentation also explains that selecting Sharing Hierarchy lets users view record access and the reason for that access.

C. Sharing is not the best answer because the Sharing button is mainly used to manually grant access, not to view the full access hierarchy and access reasons. B. New Task and D. Edit do not relate to record access visibility.

===========

The correct answer is B. Queue.

The approval request must go to department members who can approve overnight shipments. In Salesforce approval processes, routing an approval to a queue is appropriate when a group of users can own or act on the approval request and any one of the queue members can handle it. Salesforce approval documentation describes approval processes as automation that specifies each approval step, including who receives the approval request.

A queue is better than a role or hierarchy field when the request needs to be handled by a department group rather than a single manager or a specific user from a hierarchy field.

A. Role is less appropriate because roles are for hierarchy-based access and routing.

C. Hierarchy field is used when routing to a user identified through a manager-style field.

D. Public group is used for sharing and grouping users, but approval queues are the standard routing choice for a group of approvers in this scenario.

===========

The required metric is the total monetary value of won Opportunities for each Account. Salesforce supports roll-up summary fields on Account that aggregate Opportunity Amount and apply filtering criteria so that only qualifying child records are included. The appropriate configuration therefore uses SUM on Opportunity Amount with a filter restricting the calculation to Opportunities whose Stage represents Closed Won. Option C would incorrectly include open and lost Opportunities. COUNT-based options calculate the number of records rather than total sales value, and the roll-up belongs on the Account because that is where the summarized result must appear. Salesforce ' s current documentation specifically gives the example of an Account roll-up displaying total Opportunity amount and filtering the aggregation to only won Opportunities.

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

The correct answer is D.

Managers need to create child Accounts directly from a parent Account and auto-populate fields from that parent record. This is an object-specific custom action use case. Salesforce Trailhead states that object-specific actions can create records that have automatic relationships to other records and provide a streamlined experience across desktop and mobile. Salesforce also documents that predefined field values can be used with quick actions to set field values automatically, improving consistency and speed.

A. Global Quick Action is not ideal because it does not run in the specific parent Account context. B. Path does not create child records. C. Custom link is not the recommended Lightning approach for creating related records with predefined values.

===========

The correct answer is A. Page structure will automatically adapt to the device being used to view the record page.

When choosing a Lightning record page template, the app builder should consider how the template displays across supported devices. Salesforce Lightning pages are designed for Lightning Experience and the Salesforce mobile app, and Salesforce documentation states that the chosen template controls how the page displays across devices.

B is incorrect because users do not need “View All Data” just to view a Lightning record page; normal object and record access applies.

C is incorrect because Salesforce supports switching Lightning page templates, subject to template-switching considerations.

D is incorrect because the app builder does not create a separate template for every device type.

===========

Custom objects are supported metadata components that can be included in outbound change sets and deployed between connected Salesforce organizations. Salesforce ' s current list of components available in change sets explicitly includes Custom Object . Change sets migrate metadata and configuration rather than business data or user records. Salesforce notes that a custom object can be deployed and that dependent components such as its custom fields should also be included when the complete object configuration is required. Users themselves cannot be migrated through change sets because they are records rather than deployable metadata. Standard fields are Salesforce-provided components rather than custom metadata to be transported this way. Although some profile configuration can carry page layout assignments, a Lightning page assignment itself is not the correct standalone answer among the options. Therefore, A is the supported component. Salesforce

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

Change sets are Salesforce ' s native declarative mechanism for transferring metadata between connected environments, including from a sandbox to its associated production organization. Salesforce ' s current deployment documentation specifies a two-stage process: create and upload an outbound change set from the source sandbox, then access and deploy the corresponding inbound change set in the target production org. Change sets can contain metadata components such as custom fields, page layouts, Apex classes, flows, and other supported customizations. A sandbox refresh operates in the opposite direction by copying production configuration into a sandbox; it does not refresh production from development. Manually recreating components is inefficient and creates configuration-drift risk. Managed packages are principally intended for packaged distribution and are unnecessary for straightforward lifecycle deployment between related sandbox and production environments.

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

The correct answer is A. Add the field to the custom report type field layout.

The report already exists: Position with or without Applicants Report. The issue is not that reporting is disabled for the object; the issue is that the new Applicant field is not available as a column in that custom report type. For custom report types, fields available to report builders are controlled by the custom report type field layout. Salesforce’s documentation for adding fields to a custom report type directs admins to open the report type and use Edit Layout to add the missing fields.

B is incorrect because field-level security can hide a field from a user, but the troubleshooting step for a field missing from a custom report type column list is to add it to the custom report type layout.

C is incorrect because the report type already exists and is being used.

D is incorrect because the field data type was already assigned when the field was created.

===========

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.

===========

Current Salesforce documentation makes C the correct answer. Salesforce Help states that to enforce validation rules during Lead conversion, the Require Validation for Converted Leads setting must be enabled under Lead Settings. If it is disabled, validation automation that would otherwise protect the resulting Account, Contact, or Opportunity can be bypassed during conversion. Therefore, missing information on Accounts created through Lead conversion indicates that this Lead setting has not been enabled.

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

Actions and Related Records identifies an after-save record-triggered flow . Salesforce states that this optimization should be selected when automation must perform actions after the triggering record has been saved, including updating related records, creating records, and sending notifications or email. The flow can trigger when an Opportunity changes to Closed Won, reference the related Account and Account owner, perform any required related-record operation, and invoke the appropriate email action. Fast Field Updates is a before-save configuration optimized only for changing fields on the triggering record itself. A validation rule cannot invoke an autolaunched flow, and a Screen Flow requires user interaction. Because this automation requires post-save related-record processing and an email notification, D is the Salesforce-supported architecture.

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

A Global Picklist Value Set is used when the same picklist values must be reused across multiple objects and fields. Salesforce states that global picklist value sets let admins share values across objects and custom picklist fields.

Why not others:

A. Shared Custom Field is not a Salesforce feature for this requirement.

C. Dependent Picklist controls values based on another field.

D. Related Picklist is not the correct Salesforce feature.

===========

Path is designed to give users a visual representation of a record ' s progression through a process based on a picklist field such as Status or Stage. Salesforce describes Path as an at-a-glance indicator that shows where a record currently sits in a process and where it is progressing next. For delivery tracking, the app builder can configure delivery statuses as Path stages and place the Path component on the Lightning record page. Related Lists display associated records rather than process progression. Details displays record fields, while Related Record exposes information from another related record. Because the stated requirement is specifically for a visual representation of delivery status, Path is the native declarative component that directly satisfies the requirement.

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

The Repeater component is specifically designed to collect and modify multiple instances of the same type of information within a Screen Flow. Salesforce supports using a record collection as the Repeater ' s data source, allowing existing records to be prepopulated. At runtime, users can modify those items and, when configured, add or remove additional instances. That directly matches the requirement to display existing Order Line Items while permitting users to add new line items within the same interactive screen. A Data Table is primarily intended to display and select records rather than provide this repeated add/edit data-entry pattern. Section only organizes screen components, while Slider captures a numeric value. Salesforce ' s current Repeater functionality explicitly supports prepopulated records together with user additions and modifications.

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

The correct answer is B. Apex unit test failures.

When installing a package that contains Apex in a production org, Salesforce runs Apex tests as part of the installation/deployment validation. Salesforce documentation states that package installs or upgrades can fail when Apex test requirements are not met.

Even though the unmanaged package was tested in a Full Copy sandbox, production installation can still fail if Apex tests fail during production validation.

Why others are incorrect:

A, C, and D are not the best answer because the package already installed successfully in a Full Copy sandbox that matched production. The most certification-relevant reason for production failure is Apex unit test failure.

===========

For an unmanaged package, Salesforce documentation states that the developer who created and uploaded the package has no control over installed components and can’t change or upgrade them after installation.

Therefore, an unmanaged package does not follow the normal managed-package upgrade path. To get a newer version, the practical process is to remove the installed unmanaged package and install the newer version.

Why others are incorrect:

B and D describe managed/update-style behavior, not unmanaged package behavior.

C is not the package upgrade process itself; it describes a deployment workaround, not upgrading the installed unmanaged package.

===========

The correct answers are A. Processes that update record owners do not transfer child records and C. Processes will fail on records owned by inactive users.

When Process Builder updates a record owner, Salesforce does not automatically transfer associated child records such as related Contacts or other child records. Salesforce documentation says processes that update owners do not automatically transfer associated items, so separate update actions are required for each related record type.

Also, Salesforce documentation states that processes can’t update records owned by inactive users. If records are still owned by inactive users, automation that tries to update them can fail.

B is not the correct consideration here.

D is not the best answer because the issue described is about ownership-based access to Accounts and Contacts, not simply whether a process version is active.

===========

Global actions are designed to be available broadly, not only from one object’s record page. Salesforce Trailhead states that global actions can be placed anywhere actions are supported and can let users send email without leaving the page they are on.

This fits the requirement because users need a Send New Email action available from Leads, Contacts, and Accounts in the Salesforce mobile app.

Why others are incorrect:

A is incorrect because a global action layout does not automatically clone the default page layout.

B is incorrect because the Lightning Component Library is not the reason to use global actions.

C is incorrect because global actions are not record-specific; object-specific actions are record-specific.

===========

The correct answer is D. Rich text area.

The requirement says users need to write detailed descriptions that can include pictures and links. Salesforce Rich Text Area fields are designed for formatted text and support images and hyperlinks.

Long text area supports longer plain text but not rich formatting with images. URL stores a single web address. Multi-select picklist stores selected values, not detailed formatted descriptions.

===========

A permission set is the appropriate way to selectively grant the Salary record type to the hiring manager and VP of HR while other HR users retain ordinary access to applicant records. Salesforce explicitly supports assigning custom record types through permission sets. The base profile can provide the common Applicant object permissions and Hourly record type, while the additional permission set expands Salary record-type availability only for authorized users. This separates record creation capability from record-level visibility. Changing organization-wide defaults would unnecessarily affect who can view applicant records and does not control record-type selection. Simply making Hourly the default also does not prevent users from choosing another record type if they have access to it. Object-level Create permission cannot distinguish between two record types of the same object. Therefore, D provides the required granular access.

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

Collection Sort is designed to reorder a collection and optionally reduce the number of records retained after sorting. Salesforce documents that the Collection Sort element can sort a record collection by a selected field in ascending or descending order and can specify the maximum number of items to keep afterward. The flow should therefore sort the Opportunity collection by Amount in descending order and retain only five records. A Collection Filter selects records based on Boolean-style criteria, but it does not identify the top N records based on ranking. A Decision controls execution paths rather than restructuring a collection. Transform maps data between structures but is not intended to rank and limit records. Collection Sort directly implements both requirements—highest Amount first and only five records retained.

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

Record type availability determines which record types a user can select when creating records. Salesforce allows record types to be assigned through profiles, permission sets, and permission set groups. Therefore, if the support team ' s profile currently provides access to Bronze, removing Bronze from that profile prevents users from selecting that record type, assuming it is not granted through another permission set. Organization-wide defaults and sharing rules regulate access to records after they exist; they do not control which record types a user can select during creation. A permission set group containing Platinum and Diamond could grant additional access but does not inherently revoke Bronze access already provided by the profile. The direct solution described by the options is therefore to remove the Bronze record type assignment from the support team ' s profile.

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

The correct formula is:

IF(

NOT(ISBLANK(Nickname__c)),

Nickname__c,

FirstName

)

Salesforce recommends ISBLANK() to check whether a field has no value, including text fields. Since Nickname__c is optional, the formula first checks whether it is not blank. If it has a value, Salesforce uses the nickname. If it is blank, Salesforce uses FirstName .

A is incorrect because BLANKVALUE() is not used this way inside NOT() .

B is incorrect because the logic is reversed and ISNULL() is not preferred for text fields.

D is incorrect because TEXT() is not needed for a text field and does not perform a blank check.

===========

The correct answer is C. Developer sandbox.

For small, individual projects where teams need separate environments before moving work into a larger shared testing sandbox, a Developer sandbox should be considered first. It is intended for development and testing of configuration changes in an isolated environment and is the lowest-cost sandbox option compared with Developer Pro, Partial, and Full sandboxes. Salesforce describes sandbox types for different testing and development needs, with Developer and Developer Pro sandboxes copying configuration/metadata rather than full production data.

Developer Pro provides more storage, but the question emphasizes small projects and keeping costs down. Partial and Full sandboxes are better for broader testing with data, but they are not the first choice for many small isolated development efforts.

===========

A Screen element creates a transaction boundary. In the original design, the Opportunity is created before the second Screen, so that record is committed when the flow reaches the Opportunity Product Screen. If subsequent Opportunity Product creation fails, a Roll Back Records element can roll back only pending changes in the current transaction; it cannot undo the already committed Opportunity from the previous transaction. The solution is therefore to collect both sets of user input first, then create the Opportunity and Opportunity Product in the same transaction after the second Screen. A fault connector from Create Opportunity Product to Roll Back Records then cancels all pending record changes in that transaction. Salesforce explicitly documents using Roll Back Records on a Screen Flow fault path to cancel all pending changes

Page layouts are metadata components. When an updated layout is included in a deployment, the target organization receives the source version of that layout rather than merging independent layout customizations field by field. Consequently, if three fields existed only on the production version but were absent from the sandbox version being deployed, those field placements can disappear when the source layout configuration replaces the target configuration. Salesforce ' s deployment documentation emphasizes that metadata deployments apply the layout configuration supplied in the deployment payload and warns that page-layout metadata and assignments require complete deployment planning. Option A cannot be correct because a failed deployment is rolled back. Missing field permissions affect visibility, but the scenario specifically identifies fields disappearing from the deployed layout configuration. Therefore, B best explains the behavior.

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

Performing Data Manipulation Language operations such as Update Records inside a Loop is a classic Flow governor-limit anti-pattern. Each loop iteration can perform another database operation, rapidly consuming transaction limits when a large collection of Opportunities is processed. Salesforce ' s official Flow guidance explicitly says never to place DML operations inside loops. Instead, the app builder should iterate through the records, use Assignment elements to modify them and add them to a record collection, and perform one bulk Update Records operation after the loop. Fault paths improve error handling but do not prevent governor-limit consumption. Schedule-triggered flows can update standard objects, so D is incorrect. The scalability problem described is therefore directly caused by performing Update Records repeatedly inside the Loop element.

A master-detail relationship provides the required cascade-delete behavior. Supplier__c should be configured as the master and Supplier_Item__c as the detail. Salesforce explicitly states that when a master record is deleted, its related detail and subdetail records are also deleted. This ensures that terminating the Supplier relationship removes the dependent Supplier Item records automatically without additional Flow or Apex automation. An indirect lookup relationship is used primarily to relate external-object data to Salesforce records and does not provide the required ownership and cascade behavior. A hierarchical relationship is available only for relationships involving the User object. Many-to-many describes a data-model pattern normally implemented with a junction object and does not itself specify the required parent-child cascade. Master-detail therefore directly implements the stated lifecycle dependency.

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

The correct answer is A. Configure Campaign Interactions and Campaign statistics.

The option text appears to contain an OCR/wording issue. The intended Salesforce feature is Campaign Hierarchies and Campaign statistics. For advertising ROI, Salesforce Campaigns are the correct feature because Campaign ROI reports calculate return on investment using campaign cost and won opportunity value. Salesforce also states that campaign hierarchy metrics roll up from child campaigns to parent campaigns, which helps analyze campaign performance across related marketing efforts.

B is incorrect because Account interactions and roll-up summary fields are not the standard marketing ROI solution.

C is incorrect because changing the whole org to a public security model is unnecessary.

D is incorrect because an opportunity pipeline report alone does not provide campaign ROI analysis.

A Screen Flow is Salesforce ' s interactive flow type and is specifically intended to guide users through a business process while collecting input. The app builder can create multiple Screen elements representing troubleshooting steps, display instructions and questions, store the representative ' s responses, and then use Create Records to generate the follow-up Case at the end of the process. Salesforce explicitly distinguishes Screen Flows from background automation because Screen Flows require user interaction and support screens, choices, and other interactive components. Schedule-triggered, record-triggered, and platform event-triggered flows execute automatically in the background and therefore do not provide the required multi-step wizard interface. The combination of guided navigation, data capture, and record creation makes Screen Flow the appropriate declarative solution.

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

A schedule-triggered flow is designed for batch automation that must execute at a defined time and frequency. Salesforce allows this flow type to run once, daily, or weekly and to select an object plus entry conditions in the Start element. Universal Containers therefore can configure Account as the target object, Weekly as the frequency, Sunday at 2:00 a.m. as the start schedule, and conditions that identify Accounts whose Last Activity Date is more than 90 days old. A scheduled path on a record-triggered flow is tied to individual record-triggering events rather than a weekly evaluation of all qualifying Accounts. Option D runs only once and fails the recurring requirement. Salesforce explicitly supports weekly schedule-triggered flows for this batch-processing pattern.

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

Use a Component visibility filter. The issue is not object access or field access. The Contact Lightning record page is shared, but one component should be hidden for users with the Marketing profile. Salesforce Lightning App Builder supports visibility filters on Lightning page components, so the app builder can conditionally show or hide that component based on user/profile criteria.

Why not the others? AppExchange is unrelated. Detail page layouts control field layout, not visibility of a Lightning page component. Field-level security controls field access, not whether a large component appears on a Lightning record page.

===========

The correct answer is D. Set the Organization-Wide Default to Private for accounts. Create criteria-based sharing rules for each marketing team, and create an Inside Sales Team profile with the “View All” setting for Accounts.

The field sales team should only see Accounts they own, so Account OWD must be Private. Salesforce OWDs define users’ default access to records they do not own.

North American and European marketing teams need access by region, so use criteria-based sharing rules based on the Account region. Salesforce criteria-based sharing rules share records when records match field criteria.

Inside sales needs access to all Account records, so give that group View All Records on Account. Salesforce object permissions define that View All Records lets users view all records for that object regardless of sharing settings.

===========

The correct answer is B. Approval Process.

An Approval Process is used when a record must be reviewed and approved before moving forward. Salesforce Trailhead gives a very similar example: opportunities with high discounts requiring approval before proceeding.

Here, Cloud Kicks needs CFO sign-off when a major shoe retail deal has a discount greater than 30% before it can be closed. This is exactly what an approval process is designed to handle.

Why others are incorrect:

Slack message only sends communication.

Email alert only notifies someone.

Field update changes a field value but does not collect formal approval.

===========

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.

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

A criteria-based sharing rule can identify Project records according to the Department field and share matching records with the appropriate public group. Salesforce documents that criteria-based sharing rules determine which records are shared based on field values and can grant access to public groups. Administrators can therefore maintain departmental public-group membership as employees change roles. When an employee leaves one department, removing that user from its public group removes the sharing path to those departmental Projects after sharing recalculation. Permission sets and profiles control object and field permissions but are not targets for criteria-based record-sharing rules. Account Teams apply specifically to Account collaboration and are unrelated to a custom Project object. With Project OWD set to Private, public groups plus criteria-based sharing provide the required controlled departmental visibility.

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

The correct sandbox type is Partial Copy.

A Partial Copy sandbox is built for testing with a subset of production data. Salesforce lists Partial Copy sandboxes with 5 GB data storage and a 5-day refresh interval, which supports the requirement to refresh it every weekend.

Why the other options are wrong:

Developer and Developer Pro sandboxes are mainly for development and do not copy a production data subset in the same way. A Full sandbox can copy all production data, but its refresh interval is longer and it is unnecessary for a subset under 5 GB.

===========

The correct answer is B. Data is unable to be deployed with change sets.

Change sets deploy metadata/configuration, not business data. Salesforce documentation states that change sets can contain setup modifications, but they cannot be used to upload a list of records such as contacts.

So the report itself can be deployed, but the underlying records needed for the report results are not deployed through the change set. If the Partial Copy sandbox does not contain matching sample data, the report returns no data.

Why others are incorrect:

Data is not deployed just because it is added to a change set.

Reports do not have to be manually recreated if they are deployed properly.

“Salesforce OK” is not a deployment requirement.

===========

Flow Orchestration is designed for sophisticated, long-running business processes that coordinate multiple flows, users, teams, and stages. Salesforce distinguishes ordinary Flow from Orchestration by describing flows as primarily record-centric, whereas orchestrations are user-centric and coordinate processes involving different people and different parts of an organization. Interactive orchestration steps can create work items and assign them to individual users, groups, or queues, making them suitable for onboarding activities distributed across multiple participants and days. A Screen Flow can guide one interactive session but is not the strongest choice for coordinating long-running work across multiple users. Entitlement processes are primarily service-management mechanisms, and a custom LWC would introduce unnecessary development. The multi-user, multi-stage nature of the requirement therefore directly aligns with Flow Orchestration. Salesforce

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

When deploying from sandbox to production using Change Sets, the following are critical considerations:

A. Transactions will revert if the deployment errors – Salesforce applies deployments as a single transaction; any failure rolls back the deployment to maintain org integrity.

D. Change sets do not include all components and may require manual configuration – Certain components, such as record data or some metadata, may need manual setup or additional deployment steps.

Salesforce documentation emphasizes that change sets cannot deploy everything and must be carefully reviewed before validation. (Salesforce Help)

B. Users being logged out is not required; deployments can occur while users are logged in.

C. Salesforce Connect does not automatically link environments; it is unrelated to change sets.

===========

The correct answers are B. Roles and Subordinates, C. Public Groups, and D. Users / Individual Users.

Salesforce manual sharing allows record owners or users with proper access to share individual records with users, public groups, and roles. Salesforce documentation specifically states that manual sharing is used to share individual records with other users, public groups, and roles.

For Lightning manual sharing, Salesforce also describes entering groups, users, roles, or territories in the sharing search box.

So, based on your option wording:

B appears to mean Roles and Subordinates.

C is Public Groups.

D appears to mean Users / Individual Users.

A. Permission Set Groups is incorrect because permission set groups grant object, field, app, and system permissions, not case-by-case record sharing.

E. Private Groups is not the standard answer for this Platform App Builder manual-sharing question.

===========

The correct answer is A. Make the Opportunity Type a required field on the initial Opportunity page layout and use automation to update the record type based on the Opportunity Type.

The requirement has two phases: first, show users only the fields needed to create the Opportunity; after save, show the full record page based on the Opportunity type. This can be handled by using a required Opportunity Type field first, then automation can update the Opportunity record type. Salesforce page layouts can be assigned by profile and record type, which allows different Opportunity types to show different layouts after the record type is set.

B is incomplete because it only mentions page layouts based on profile, not dynamically changing the layout based on Opportunity Type after creation. C is incorrect because sharing rules control record access, not field display. D relies on users manually expanding sections and does not meet the streamlined requirement.

The correct answer is D. Approval process.

The requirement is to automate travel request form submission and enforce an internal approval policy. Salesforce approval processes are specifically designed to automate how records are submitted, reviewed, approved, rejected, recalled, and acted upon. Salesforce Trailhead explains that an approval process defines the criteria a record must meet before submission, the approval steps, approvers, and the actions taken when the record is approved or rejected.

This exact scenario also aligns with Salesforce’s travel approval training example, where a Travel Approval object uses an approval process to route travel requests to the employee’s manager and, when needed, to another approver.

A is incorrect because assignment rules route leads or cases, not approval requests.

B is incorrect because validation rules prevent invalid saves but do not manage approval routing.

C is incorrect because Apex is unnecessary when a standard declarative approval process fits the requirement.

===========

The correct answers are B. External ID and C. Unique.

The legacy ID field should be marked as External ID because Salesforce can use an external ID field to match records during import, integration, and upsert operations. Salesforce documentation confirms that external IDs can be used to create or update records through upsert.

The field should also be marked Unique so Salesforce prevents duplicate legacy ID values. Salesforce custom field attribute documentation states that the Unique option prevents duplicate field values.

Why others are incorrect:

A is incorrect because encrypted text is not the right choice for a matching legacy ID used in upserts.

D is not the best answer because making the field required does not enable upsert matching or prevent duplicate external IDs.

===========

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 solution is to add a Rich Text component to the Case Lightning record page and then use component visibility so it only appears when the related Account’s support level is Platinum.

Salesforce Lightning App Builder supports visibility rules that show or hide components based on field criteria. Salesforce documentation confirms that visibility filters on record pages rely on field data associated with the page’s object, and related lookup fields can be used in visibility-rule considerations.

This is the best declarative solution because the requirement is only to display a text notification. A custom Lightning Web Component or cloned Lightning page is unnecessary.

Why others are incorrect:

A is incorrect because assigning a Case page to “platinum accounts” is not the correct assignment model.

C and D are incorrect because custom Lightning Web Components add unnecessary development effort for a simple text notification.

===========

A validation rule is required because Cloud Kicks needs to prevent , rather than merely discourage, users from skipping required Opportunity stages. A validation formula can evaluate the new StageName together with the prior stage, required fields, or other process criteria and block the save when the transition violates the sales process. Salesforce validation rules are designed to prevent records from being saved when specified business conditions are violated. Path and Guidance for Success improve usability and tell representatives what they should do, but neither inherently stops a user from jumping directly to Contract Signed. An approval process would add unnecessary managerial routing and does not directly represent the requirement to enforce valid stage progression. Therefore, a validation rule is the most efficient declarative mechanism for enforcing the required pipeline sequence.

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

The correct answers are A. Assign app to profiles and B. Build a Custom Tab for the app.

Your option A appears corrupted as “Asking new options,” but the known Salesforce wording for this question is Assign app to profiles.

To make a custom Lightning app available to internal users, users must have access to the app through profile/app assignment. Salesforce documentation explains that assigned app settings specify which apps users can select from the Lightning Platform app menu.

A Custom Tab is also needed when exposing the custom app/component as something users can access from the Salesforce UI. Salesforce documentation states that custom tabs can appear in the app navigation bar and App Launcher.

Adding the app to a Visualforce page is not required, and uploading it to Static Resources is not how Lightning apps are made available to users.

===========

In-App Guidance is Salesforce ' s native capability for contextual onboarding, feature adoption, prompts, and guided walkthroughs directly inside Lightning Experience. Salesforce documents that administrators can create prompts and walkthroughs, determine the target audience, and specify where and when that guidance appears. Targeted prompts can highlight a specific page element, while walkthroughs connect multiple prompts into a step-by-step guided experience. This aligns directly with Universal Containers ' goals of increasing adoption and guiding users through a newly launched application. A Screen Flow is appropriate when collecting information or executing an interactive business process, but it is not the dedicated adoption feature. Dynamic Actions control which actions appear, while Dynamic Forms controls field and section presentation. Neither provides structured onboarding walkthroughs.

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

The correct answers are B. Cross-object field updates between Training and Student records are not supported and C. On Training record, the Student Lookup field can be made optional.

This question is about creating a Student lookup field on the Training object. A lookup relationship is a looser relationship than master-detail. Salesforce documentation explains that lookup relationships do not support roll-up summary fields, unlike master-detail relationships.

Because this is a lookup relationship, the Student lookup field on Training can be optional unless the app builder marks it required. Cross-object field updates are also not supported in this lookup relationship scenario; Salesforce documents that cross-object field updates work for master-detail relationship scenarios, not normal lookup relationships.

A is incorrect because roll-up summary fields require a master-detail relationship.

D is incorrect because deleting Student records is controlled by object permissions and relationship delete behavior, not simply by access from the Training record.

===========

The correct answers are B. Assign the page to a combination of apps and profiles, C. Make the page the default homepage for specific apps, and E. Make the page the org default.

When activating Lightning pages, Salesforce supports assigning a page as an org default, assigning it to specific Lightning apps, and assigning it to combinations such as app and profile. Salesforce Trailhead also confirms that Lightning record page activation supports org default, app default, and app/record type/profile assignments.

A is incorrect because Lightning page activation uses profiles, not permission sets, for this assignment model.

D is incorrect because Lightning pages are not activated by role as a standard activation option.

===========

The correct answer is D. Flow.

A call center representative needs to collect customer information through a series of question prompts. This is a classic use case for a Screen Flow. Salesforce describes screen flows as interactive automation that asks users questions, presents information, and uses user responses to update records or show more prompts.

Approval Process is for approvals, Path guides users through stages, and Validation Rule enforces data quality. None of those tools provide a guided question-and-answer experience.

===========

A managed package provides important intellectual-property protection when an application is distributed to other Salesforce organizations. Salesforce ' s packaging documentation states that Apex classes and triggers contained in a managed package are obfuscated and cannot normally be viewed in the installing subscriber organization, apart from exposed global method signatures and specific support-access scenarios. Managed packages are therefore the appropriate model when a publisher wants to distribute an application while protecting proprietary Apex implementation details. A package does not need to be sold on a per-user basis simply because it is managed; free managed packages can be distributed. Unmanaged packages expose components for subscriber modification and aren ' t designed to provide the same provider-controlled upgrade and IP-protection model. Therefore, A is the relevant consideration for publishing this application. Developer

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

The correct answer is C. Compact layout.

Compact layouts control the key fields shown in the record highlights area at the top of a record, including in the Salesforce mobile app. Salesforce documentation states that compact layout fields populate the record highlights section at the top of record views in the Salesforce mobile app.

Why others are incorrect:

A. Mobile navigation controls navigation menu items, not fields on a record.

B. Record Detail component shows record fields but does not specifically place key fields at the top.

D. Object specific action is used for actions, not at-a-glance field display.

===========

Agentforce is Salesforce ' s platform for autonomous AI agents that can understand requests, reason over context, retrieve business information, determine appropriate next steps, and execute actions. Salesforce describes Agentforce agents as autonomous and proactive applications capable of taking action with or without continuous human intervention. Agents can use Salesforce CRM data and invoke flows, Apex, APIs, prompts, and other configured actions to complete business tasks. This directly matches the requirement for end-to-end customer service handling. Case Assignment Rules only route Cases. Experience Cloud with Live Chat provides customer interaction channels but does not independently reason and execute complete workflows. Einstein Bots provide conversational automation but do not represent the current autonomous agent architecture described in the scenario. Agentforce is therefore the verified answer.

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

The correct answers are C. Text field and D. Number field.

Salesforce allows custom Text, Number, Email, and Auto Number fields to be marked as External ID fields. Since the available choices include Text and Number, those are the two valid answers.

Why others are incorrect:

A. Phone field cannot be marked as an External ID.

B. URL field cannot be marked as an External ID.

===========

When deploying from a sandbox on a newer Salesforce version to production on a current version, any components that rely on features not yet available in production will fail.

Change sets do not automatically upgrade production.

All features must be supported in the target org at deployment time.

Salesforce documentation notes that compatibility issues may occur if components use version-specific features, and deployments must be tested against the target org’s current version. (Salesforce Help)

A is incorrect because deployments do not automatically wait for production upgrades.

B is partially true, but deployments are possible if features are supported.

C is incorrect; components are not automatically upgraded.

===========

The correct answers are A. Change the Lead Duplicate Rule details to Bypass Sharing Rules and D. Change the Lead Duplicate actions to Block on Create.

Because Lead OWD is Private, users may not have access to existing duplicate Lead records. Salesforce duplicate rules can be configured to bypass sharing rules, allowing the duplicate rule to check possible duplicates regardless of ownership or user visibility. Salesforce Help specifically explains duplicate prevention can block users from creating duplicate records whether or not they have access to the existing record.

D is also required because detecting a duplicate is not enough. The duplicate rule action must be set to Block on Create to stop users from saving new duplicate Leads.

Why others are incorrect:

B is incorrect because Lead Assignment Rules assign leads; they do not prevent duplicate creation.

C may expose more Lead records, but changing OWD from Private to Public Read is not the best security-safe solution when duplicate rules can bypass sharing.

===========

The Automation Lightning App ' s Monitor tab is Salesforce ' s centralized interface for examining failed and paused flow interviews. Salesforce states that the Monitor tab displays failed interviews, their error information, and details needed to determine why execution failed. From the failed interview details, an administrator can open the run in debug mode and inspect the execution information without requiring the user to reproduce the issue. This directly satisfies the requirement to troubleshoot intermittent production failures from historical flow runs. Option A focuses primarily on paused interviews and is not the current comprehensive monitoring experience. Apex Replay Debugger is intended for Apex debugging rather than declarative Flow execution. Running the flow manually as another user creates a new test execution rather than analyzing the specific production failures that already occurred.

The correct answer is C. Configure Campaign Hierarchies and Campaign statistics.

To understand return on investment for an advertising buy, Universal Containers should use Salesforce Campaigns, especially Campaign Hierarchies and campaign reporting/statistics. Salesforce campaign hierarchy documentation explains that child campaign metrics roll up to the parent campaign, and Salesforce campaign reports can include campaign-hierarchy statistics for aggregate values.

The private security model does not require changing the whole org to public. The business need is marketing ROI tracking, so Campaigns are the correct feature.

A is incorrect because an opportunity pipeline report does not directly track advertising campaign ROI.

B is incorrect because Account Hierarchies and roll-up summaries are not the standard solution for campaign ROI.

D is incorrect because changing to a public security model is unnecessary and weakens data security.

===========

The Custom Error element allows a record-triggered flow to prevent the triggering database change and present a targeted error directly to the user. Salesforce supports displaying the message either at the record-page level or as an inline error on a specific field, which exactly meets the requirement to place the error on the Opportunity Stage field. When the Custom Error element executes, Salesforce rolls back the record change until the user corrects the problem. A Screen element is not valid for providing this experience inside a background record-triggered flow. An Assignment on a fault path merely stores values and does not automatically surface a validation-style error. Ending the flow also does not prevent the record from being saved. Therefore, the Custom Error element is the correct declarative equivalent to validation-style feedback. Salesforce

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

The correct answer is C. Record Detail.

The Record Detail component on a Lightning Record Page displays the fields and sections from the object’s assigned page layout. After using Lightning Object Creator to create the object, fields, and data, the app builder must add the Record Detail component if users need to see the fields from the page layout on the Lightning Record Page. Salesforce documentation states that the Record Detail component displays fields and sections from the page layout associated with the object.

Why the other options are incorrect:

Highlights Panel shows key record actions and compact-layout information.

Recommendations displays recommendation records.

Path shows guided stage/status progression, not all page-layout fields.

===========

The correct answer is B.

When customer invitations are enabled for Chatter groups, invited customers get limited collaboration access. Salesforce documentation states that customers can see only the groups they’re invited to and can interact only with members of those groups.

A is incorrect because invited customers do not automatically get broad group-invitation rights. C is incorrect because Chatter customer access does not grant access to Account records. D is incorrect because customers are invited to specific groups; they do not receive general public-group request access.

===========

The correct answers are A. The NOW() function in the formula field and D. A cross-object field referenced in the formula field.

Salesforce allows roll-up summary fields to summarize formula fields only when the formula does not contain unsupported dynamic or cross-object references. Salesforce documentation states that roll-up summaries can calculate formula fields only if the formula does not contain cross-object field references or functions that derive values dynamically, such as NOW() or TODAY().

A is correct because NOW() changes dynamically based on current date/time.

D is correct because cross-object field references prevent the formula from being used in the roll-up summary.

C is incorrect because CASE() itself is allowed.

B is incorrect because the issue is not simply a field update; the restriction is specifically cross-object references or dynamic formula functions inside the formula being summarized.

===========

omprehensive and Detailed Explanation with all Platform App Builder documents: =

The correct answer is A. Sandbox cloning.

Cloud Kicks needs many parallel sandboxes that start from the same base configuration and data. Sandbox cloning is designed for this because Salesforce copies the source sandbox’s data and metadata into a new sandbox. Salesforce documentation states that cloning a sandbox copies its data and metadata into the new sandbox.

Partial copy and full copy are sandbox types, not the best mechanism for repeatedly creating many sandboxes from the same prepared baseline. Sandbox refreshes update existing sandboxes; they do not create at least 20 parallel environments from the same baseline.

===========

The correct answer is D.

Validation rules are the right declarative tool to enforce data compliance before a record is saved. They can prevent a Case from moving backward to an earlier Status and can require specific fields when Case criteria are met. Salesforce formula functions such as ISCHANGED() compare whether a field value changed, and validation rules can use formula logic to stop invalid saves.

Why others are incorrect:

Approval Process is for routing records for approval.

Dependent picklists control picklist value availability, not status regression.

Case Flow can automate case processes, but validation rules are the best tool for enforcing save-time compliance.

===========

The correct answer is C. Flow.

This requirement needs automation that can do multiple things: update the To Be Installed checkbox when a Lift is sold, then notify an external system the next day using an outbound message. Salesforce states that Flow Builder is the optimal tool for triggered automation because it combines workflow and process automation capabilities in one point-and-click tool. Record-triggered flows can run when records are created, updated, or deleted, and can update records, send notifications, initiate processes, and maintain data consistency.

The “next day” timing points to a scheduled path in a record-triggered flow. Salesforce explains that scheduled paths delay automation for minutes, hours, days, or months after the triggering record change. Salesforce also documents outbound messages as a Flow Builder core action for record-triggered flows, used to send a SOAP message to a designated endpoint.

Approval Process is for approvals, Validation Rule only prevents invalid data, and Assignment Rule is for assigning records such as leads or cases. None of those tools can meet the full requirement.

An input value from something outside the flow must be received through a Flow variable configured as Available for Input . Salesforce defines an input variable as a variable marked Available for Input that receives values from outside the flow. The app builder therefore creates a Variable resource, selects the required data type, and enables Available for Input under Availability Outside the Flow. The invoking Lightning component can then pass a value into that resource when the flow starts. $Record is a Flow global variable used in specific record contexts and does not replace a configurable external input parameter. Constants cannot receive changing runtime values because their values are fixed. Public component properties describe the LWC side but do not by themselves create a receiving Flow variable. Salesforce

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

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.

===========

Use a Record-Triggered Flow optimized for Actions and Related Records.

Submitting a record for approval is an action in Flow. Salesforce provides a Submit for Approval action, and after-save record-triggered flows are used when the automation needs to perform actions or work with related records after Salesforce saves the triggering record.

Option A is wrong because Fast Field Updates is the before-save path, mainly for updating fields on the triggering record. It is not the right optimization for submitting an approval request. Option B still requires a custom button and manual user action. Option C is unrelated because this requirement is based on an Opportunity record change, not a platform event.

===========

The correct answer is B. Validation Rule.

DreamHouse Realty wants to prevent an Opportunity from entering the Qualified stage unless Expected_Close_Date__c is populated. A validation rule is the correct tool because Salesforce validation rules check whether record data meets specified criteria before the user can save the record.

A validation rule could check:

Stage = Qualified

AND

Expected_Close_Date__c is blank

If both are true, Salesforce blocks the save and displays an error message.

A. Page Layout can make a field visible or required on a layout, but it cannot conditionally require the field only when Stage equals Qualified.

C. Activity History is unrelated.

D. Record Type controls business processes and layouts but does not enforce this condition by itself.

===========

The correct answers are C. Lightning App Builder and D. Lightning components in Setup.

In Lightning App Builder, custom Lightning components that are configured for use in Lightning App Builder appear in the Lightning Components pane.

In Setup → Lightning Components, Salesforce allows admins to view a list of Lightning Web Components and Aura components in the org.

Why others are incorrect:

A. Visualforce components in Setup lists Visualforce custom components, not Lightning components.

B. Salesforce Optimizer App analyzes org configuration and recommendations; it is not the place to list available custom Lightning components.

===========

Change sets can be exchanged only between deployment-connected organizations, such as a production org and its own sandboxes. UMS Logistics is a separate production organization and has no deployment relationship with the UMS source environment, so an outbound change set cannot be sent there. Salesforce documents unmanaged packages as a mechanism for packaging metadata components in a source org, uploading the package, obtaining an installation URL, and installing those components into another Salesforce organization. A managed package is intended primarily for distributed applications requiring namespace and provider-controlled versioning, such as commercial AppExchange solutions, and is unnecessary for this evaluation transfer. A sandbox likewise cannot be refreshed from an unrelated organization ' s Developer sandbox. Therefore, the appropriate deployment vehicle is an unmanaged package installed through its generated URL.

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.

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

The correct answer is B. Use an AppExchange solution.

UC has a time-sensitive need and the developers are delayed for several months. AppExchange is the best recommendation because it provides ready-to-install apps, components, and solutions that can extend Salesforce without building everything from scratch. Salesforce describes AppExchange as the marketplace for ready-to-install solutions, including apps, components, and experts.

A and C still require building the solution internally. D. Bolt solution is more specific to prebuilt Experience Cloud/community templates and is not the best answer for a general custom component requirement. Salesforce describes Bolt Solutions as combinations of Lightning apps, business process flows, and Experience Builder templates/pages.

===========

Based on the exact options provided, the correct answer is A. Create a master-detail relationship field on Open Position to Application.

The requirement says one applicant must be able to apply for multiple open positions using a single application. In Salesforce, the relationship field is created on the detail/child object. Therefore, to allow one Application__c record to relate to multiple Open_Position__c records, the master-detail field would be created on Open_Position__c and point to Application__c . Salesforce Trailhead confirms that in a master-detail relationship, the relationship field is created on the detail object.

Salesforce also uses master-detail relationships and junction objects to model many-to-many relationships.

Important note: In a fully normalized recruiting data model, a separate junction object between Application and Open Position is usually cleaner. But from the provided answer choices, A is the only option that supports one Application being connected to multiple Open Positions.

===========

The correct answer is A. Web-to-Case is the Salesforce feature designed to let visitors submit case information from a public-facing website. Salesforce documentation states that Web-to-Case is set up by enabling the feature, creating and customizing a web form, and adding that form to a website.

Why others are incorrect:

B. Outbound message sends data out of Salesforce; it does not create cases from a website.

C. Screen flow could require extra site/guest-user setup and is not the standard feature for this requirement.

D. Email-to-case creates cases from inbound email, not directly from a public web form.

Developer Pro satisfies both requirements. Salesforce ' s current sandbox reference states that a Developer Pro sandbox can be refreshed every one day and provides 1 GB of data storage by default, comfortably exceeding the required 250 MB. A standard Developer sandbox also has a one-day refresh interval, but its standard data-storage allocation is only 200 MB, so it does not satisfy the stated storage requirement without an additional storage upgrade. Partial Copy provides significantly more storage but can only be refreshed every five days. A Full sandbox mirrors production-scale data and storage but has a 29-day refresh interval. Therefore, Developer Pro is the only standard sandbox type among the choices that simultaneously supports at least 250 MB and daily refresh capability.

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

The correct answers are A. Remove the delete button from the Delivery page layout and C. Remove the Delete permission from the Shipper profile.

The real security control is C because object permissions define whether users can create, read, edit, or delete records for an object. To prevent shipping users from deleting Delivery__c records, the app builder must remove the Delete object permission from the Shipper profile.

A is also a valid supporting UI step because Salesforce page layouts can control whether standard/custom buttons are displayed. Removing the Delete button reduces the visible delete option on the record page. However, this alone is not complete security because hiding a button does not fully remove the underlying permission.

Why others are incorrect:

B is incorrect because a regular permission set grants additional access; it does not remove profile access.

D is incorrect because OWD controls record-level sharing, not object-level Delete permission.

===========

omprehensive and Detailed Explanation with all Platform App Builder documents: =

The correct answer is A. Roll-up Summary.

DreamHouse Realty wants to show the highest value from related Offer records on each Property record. Because the objects have a master-detail relationship, a roll-up summary field is the correct declarative solution.

Salesforce documentation explains that roll-up summary fields calculate values from related detail records and display the result on the master record. Salesforce also lists MAX as the roll-up type used to display the highest value from related records.

B is not a Salesforce field type for this requirement.

C, D, and E are data-entry field types and cannot calculate the highest related Offer value.

===========