Platform-App-Builder Practice Test Questions

Explanation:

The solution that the app builder should configure to meet these requirements is creating three lead record types each with its own page layout containing the relevant fields. This way, the app builder can customize the fields and sections that appear on each record type based on the source of the lead.

Option B is incorrect because creating a partner community and a record type for web and trade show leads does not address the requirement of collecting information that is unique to each type of lead, as partner community users may have different fields and layouts than internal users.
Option C is incorrect because creating three sections on the lead layout and instructing users to collapse the non-relevant fields does not address the requirement of collecting information that is unique to each type of lead, as users may still see or enter data in the wrong fields.
Option D is incorrect because creating custom page layouts for each type of lead only containing the relevant fields does not address the requirement of collecting information that is applicable to all sources, as users may miss some common fields.

Explanation:

Why:
“Two months after” should respect calendar months (28–31 days), not a fixed number of days. A simple Date formula handles this cleanly:
ADDMONTHS(Due_Date__c, 2)
(For Tasks, the Due Date field is ActivityDate, so you’d use ADDMONTHS(ActivityDate, 2).)

Why the others are wrong
A. Process Builder with (365/12)*2 — uses an average month length (≈60.83 days), which will drift from real calendar months.
B/C. Add 60 days (via formula or Process Builder) — 60 days ≠ two calendar months for many date ranges.
Process Builder isn’t needed at all; a formula field is simpler, real-time, and maintenance-free.

Explanation:

Why:
With OWD on Account = Private and Sales/Marketing in different role branches, role hierarchy won’t give cross-branch access. A (owner-based) sharing rule is the standard way to make exceptions to OWD and grant Marketing read (or read/write) access to Accounts owned by Sales—typically by sharing records owned by the Sales role (or a Sales public group) with a Marketing public group/role.

Why not the others:
A. Public Group:
Useful as the target of a sharing rule, but creating a group alone doesn’t grant access. You still need a sharing rule to share records to that group.
B. Flow:
Not the correct tool for defining org-wide record access; declarative sharing via sharing rules is the recommended approach for this requirement.
C. Workflow:
Workflow rules don’t control record sharing. They’re for field updates, emails, tasks, etc. The access requirement is solved by sharing rules.

References:
Salesforce Help: Sharing Rules – “automatic exceptions to your org-wide sharing settings” and owner-based sharing rules.
Salesforce Help: Organization-Wide Defaults (context on Private vs. opening access).

Explanation:

An unmanaged package in Salesforce is a collection of components (e.g., apps, objects, fields, or Apex code) that can be distributed and installed in other Salesforce orgs. Unlike managed packages, unmanaged packages do not support upgrades, and the components can be freely edited by the recipient org. Below is an analysis of each option:

A. Distributing open-source projects on the AppExchange (Correct):
Unmanaged packages are ideal for sharing open-source projects because they allow recipients to view and modify the components freely. Developers often use unmanaged packages to distribute sample code, templates, or open-source solutions on the AppExchange, enabling others to customize them as needed.
Reference: Salesforce Help - About Unmanaged Packages

B. Publishing an application for sale on the AppExchange (Incorrect):
Applications intended for sale on the AppExchange are typically distributed as managed packages. Managed packages provide intellectual property protection, support upgrades, and allow developers to control which components are editable. Unmanaged packages are not suitable for commercial distribution because they expose all components and do not support upgrades.
Reference: Salesforce Help - Managed vs. Unmanaged Packages

C. Deploying from a Developer Edition environment (Correct):
Unmanaged packages are commonly used to deploy components from a Developer Edition environment to another Salesforce org. Developer Edition orgs are often used for building and testing solutions, and unmanaged packages provide a simple way to share these components with other orgs without the restrictions of managed packages.
Reference: Salesforce Trailhead - Package and Distribute Your Apps

D. Distributing upgradeable components to another Salesforce org (Incorrect):
Unmanaged packages do not support upgrades. Once installed, the components are treated as native to the recipient org, and subsequent updates cannot be pushed automatically. For distributing upgradeable components, a managed package is required.
Reference: Salesforce Help - Unmanaged Packages

Summary:
Unmanaged packages are best for scenarios where flexibility and customization are needed, such as sharing open-source projects or deploying components from a Developer Edition environment. For commercial apps or upgradeable components, managed packages are the appropriate choice.

Explanation:

Why A is Correct:
A Custom Action is the modern and supported way to create a quick, inline editing experience directly from the Chatter feed on both desktop and the Salesforce Mobile App. You can create a "Update Record" action that is pinned to the publisher layout. This allows users to see and interact with specific fields (like Status and a custom Due Date) without having to navigate away from the feed to the full record edit page. This provides the "quick way" the business user requires, especially on mobile where screen space is limited.
Why B is Incorrect:
Custom Buttons are built using JavaScript or a URL. They are not fully supported or displayed in the Salesforce Mobile App. Even if they were, they typically navigate the user to a new page, which is not the "quick" inline experience requested from the feed.
Why C is Incorrect:
A Quick Access Link (part of the Utility Bar) is designed for global navigation within the Salesforce console or app. It is not used for editing specific fields of a record from its feed. It's a navigation tool, not an editing tool.
Why D is Incorrect:
A Custom URL Formula field is a read-only field that displays a hyperlink. It cannot be used to edit the data on the record itself. Its purpose is to link to an internal or external page.

Reference:
Salesforce Help - "Add Actions to the Publisher Layout" and "Actions Overview". The documentation specifically promotes using actions for quick updates: "Create actions to make your users more productive. For example, add an action that lets users update a record... without navigating away from the page they’re on." This functionality is core to the Lightning Experience and Mobile App.

Explanation:

In the Salesforce1 mobile app (now part of the Salesforce mobile experience), navigation menus can be customized by profile. This means:

You can create distinct mobile navigation menus for different user profiles.
The App Builder can configure what tabs, objects, and apps appear for each team.
This allows sales and marketing teams to see different navigation names and layouts, tailored to their needs.

This is the only option that directly addresses the requirement to customize navigation menus based on team.

❌ Why the other options don’t work:
A. Create sales and marketing profiles to ensure read access to different objects
This controls data access, not navigation layout.
B. Create roles and assign homepage layouts
Homepage layouts affect desktop experience, not mobile navigation.
D. Create public groups and mobile menus
Mobile navigation menus cannot be assigned to public groups — only to profiles.

🔗 Reference:
Salesforce Help: Customize the Salesforce Mobile App Navigation
Trailhead Module: Salesforce Mobile App Customization

Explanation:

Customers and Dealers are separate business entities:
Since both customers and dealers are distinct business entities with whom UC has direct relationships and sends separate bills, they should each be represented as separate accounts in Salesforce.
Representatives are individuals:
Each individual at the customer and dealer should be created as a contact and associated with their respective account.
Relationship between customers and dealers:
The Account Hierarchy feature in Salesforce allows you to establish a parent-child relationship between accounts. This would enable UC to represent that the customers sell their products through dealers.
Clear display of relationships:
This approach clearly displays the customers and dealers as distinct business entities and their relationship through the Account Hierarchy. The individual representatives are linked to their corresponding organizations as contacts.

Why other options are incorrect
A. Create a single parent record, add each rep as a contact to the parent account and add each dealer as a child record:
This option suggests creating a single parent record for both customers and dealers, which doesn't accurately represent them as distinct entities with direct billing relationships.
B. Create both customer and dealer as accounts, create account teams on each account and associate the dealer records with the parent account:
While creating both as accounts is correct, using account teams is for internal collaboration on an account, not for defining the primary business relationship between a customer and its dealers. The association mentioned is better represented by an account hierarchy.
C. Create a single account record, add each rep as a contact and create a custom dealer object:
Creating a single account record for the customer would not correctly represent the dealer as a separate billable entity. While custom objects offer flexibility, using the standard Account object with its hierarchy feature is the most straightforward and recommended approach for representing related business entities like customers and dealers.

Explanation:

The issue described involves a high number of inactive picklist values on the Account object’s picklist fields, which negatively impacts system performance and user experience. Salesforce provides Global Value Sets (also known as Picklist Value Sets) as a solution to manage picklist values more efficiently, especially when values are reused across multiple fields or need frequent updates.

B. Set up Global Values in Picklist Value Sets (Correct):
Global Value Sets allow you to define a single set of picklist values that can be reused across multiple picklist fields in different objects. By converting the picklist fields on the Account object to use a Global Value Set, Universal Containers can centrally manage the values, including deactivating or removing outdated ones. This reduces redundancy, simplifies maintenance, and can improve performance by minimizing the number of inactive values stored for each field. Additionally, Global Value Sets make it easier to update values across all associated fields at once, addressing the issue of frequent changes due to evolving business requirements.
Reference: Salesforce Help - Define Picklist Value Sets

Why not the other options?
A. Establish upper bound on existing picklists in Picklist Settings (Incorrect):
Salesforce does not provide an option in Picklist Settings to set an upper bound on the number of picklist values (active or inactive). While there are system limits (e.g., 1,000 total values for a standard picklist, including active and inactive), these are not configurable by the admin in the way described. This option does not address the issue of managing inactive values or improving performance.
Reference: Salesforce Help - Picklist Limitations

C. Remove upper bound on inactive picklist values in Picklist Settings (Incorrect):
There is no setting in Salesforce to specifically “remove an upper bound” on inactive picklist values. The platform imposes limits on the total number of picklist values (active and inactive), and inactive values still count toward this limit. Removing or adjusting such a bound is not a feature in Salesforce, and this option does not solve the performance or user experience issue.
Reference: Salesforce Help - Picklist Field Limits

D. Convert the picklist fields to a different field type that will still meet the business requirements (Incorrect):
Converting picklist fields to another field type (e.g., text, multi-select picklist, or lookup) may not be feasible or desirable, as it could disrupt existing business processes, reports, or integrations that rely on the picklist structure. Additionally, this does not directly address the issue of managing inactive values or improving performance. It’s a drastic change that may not meet the business requirements without significant rework.
Reference: Salesforce Help - Change Field Type

Recommended Approach:
Navigate to Setup > Object Manager > Picklist Value Sets.
Create a new Global Value Set with the required picklist values.
Update the Account object’s picklist fields to use the Global Value Set instead of individual picklist values.
Review and remove unnecessary inactive values from the Global Value Set to streamline performance.
Test the updated fields to ensure they meet business requirements and improve user experience.

Additional Notes:
Inactive picklist values can impact performance, especially in large orgs, as they are still stored and processed in the background (e.g., in reports, list views, or SOQL queries). Using Global Value Sets reduces redundancy and simplifies value management.
If the number of inactive values is significantly high, you can also archive or delete unused values (if not referenced in historical data) to further optimize performance, but this must be done cautiously to avoid data integrity issues.

Reference:
Salesforce Help: Create and Manage Global Picklist Value Sets
Salesforce Trailhead: Data Modeling - Picklist Administration

Explanation:

Why:
A. To convert a lookup to master-detail, every child (Star) record must have a value in the Galaxy lookup. If any Star record has the Galaxy field blank, the conversion is blocked.
D. An object can be the detail in at most two master-detail relationships. Since the master-detail field lives on the child object, you must ensure Star currently has fewer than two master-detail fields before converting.

Why not the others:
B. The “two master-detail” limit is about the detail (child) object, not the master. Galaxy (the master) isn’t capped at two children in that sense.
C. You don’t need existing roll-up summaries to convert. You create roll-up summary fields on the master (Galaxy) after the relationship is master-detail.

References:
Salesforce Help — Considerations for Object Relationships (conversion prerequisite).
Salesforce Help — Object Relationships Overview (two master-detail limit per object).
Salesforce Help — Create a Roll-Up Summary Field (roll-ups live on the master and can be added after conversion).

Explanation:

Formula fields in Salesforce are powerful tools that allow you to:
Reference parent fields (via relationships)
Concatenate text, numbers, and dates
Apply logic using functions like IF(), TEXT(), CONCAT(), etc.
In this case, the Opportunity Product (technically the OpportunityLineItem object) can access fields from its parent Opportunity using relationship syntax like Opportunity.Name or Opportunity.Description.
So, combining two text fields from the parent Opportunity — such as Opportunity.Text_Field__c + " " + Opportunity.Description__c — is fully supported in a formula field.

❌ Why the other options don’t work:
A. A hyperlink to the parent Account of the parent Opportunity
Formula fields cannot traverse two relationships (i.e., from Opportunity Product → Opportunity → Account). You can only go one level up.
B. A Rich Text area field that uses HTML to bold certain characters
Formula fields do not support Rich Text formatting or HTML styling like < b > tags.
D. A mix of functions and concatenation of 10 Account fields and 10 Opportunity fields
You cannot access Account fields from Opportunity Product via formula — that’s two levels up.
Also, this would likely hit the formula character limit (3,900 characters for compiled size).

🔗 References:
Salesforce Help: Formula Field Limits and Capabilities
Trailhead: Formulas & Validations