Platform-App-Builder Practice Test Questions

Explanation:

The app builder should provision a Partial Data sandbox to the developer. A Partial Data sandbox can have up to 5 GB of data, which meets the requirement of having at least half a gigabyte of data. A Partial Data sandbox can also be refreshed every 5 days, which meets the requirement of refreshing after each three-day sprint.

Option A is incorrect because a Developer sandbox can only have up to 200 MB of data, which does not meet the requirement.
Option B is incorrect because a Full Copy sandbox can only be refreshed every 29 days, which does not meet the requirement.
Option C is incorrect because a Developer Pro sandbox can only have up to 1 GB of data, which may not be enough for the requirement.

Explanation:

Universal Containers has a Lightning record page that supports both the mobile app and desktop, and a custom Lightning component downloaded from AppExchange is not visible on mobile devices. The most likely issue is that the component has been developed for Desktop Pages only. Many AppExchange components are designed and optimized for desktop use, and their documentation or metadata may indicate they are not compatible with the Salesforce mobile app (e.g., Salesforce Mobile App or Lightning Experience on mobile browsers). To be mobile-compatible, a Lightning component must explicitly support the Salesforce mobile framework, which requires the developer to ensure responsiveness and compatibility with the mobile runtime.

Why not the other options?
A. The record page needs to be activated:
If the record page were not activated, it would not be visible on either desktop or mobile, and the issue specifies that users can see the page on desktop but not mobile. Activation applies to the entire page, not selective components, so this is not the cause.
C. The component needs to be activated:
Lightning components from AppExchange are typically installed and available for use once deployed, unless explicitly deactivated by an administrator. Deactivation would affect visibility on both desktop and mobile, not just mobile, making this unlikely.
D. The record page template is unable to support mobile devices:
The problem states that the record page supports both the mobile app and desktop, implying the template (e.g., a standard or custom Lightning page template) is mobile-compatible. The issue is specific to the component, not the template, so this is not the root cause.

Additional Notes:
To confirm, the app builder should check the component's documentation on AppExchange or contact the publisher to verify its mobile compatibility.
If the component is desktop-only, the builder could explore alternatives (e.g., a mobile-compatible version) or customize the page to hide the component on mobile using the Lightning App Builder's "Component Visibility" filter (e.g., based on device type).

References:
Salesforce Help: Lightning Components for Mobile (Details mobile compatibility requirements for components).
Salesforce Trailhead: Build UI with Lightning Components (Covers component development and deployment considerations).
AppExchange: Component Listings (Often includes mobile compatibility notes in component descriptions).

Explanation:

The requirement is to use a field to store a legacy system ID for the purpose of linking records during future data loads (upserts). This is a classic use case for an External ID field.

Why C (External ID) is Correct:
This is the primary attribute needed. Marking a field as an External ID allows it to be used as a unique identifier for upsert operations in the Data Import Wizard, Data Loader, or other APIs. When you upsert records, you can specify this External ID field to match records from your source file to existing records in Salesforce, updating them if they exist or creating them if they don't.

Why A (Unique) is Correct:
For an External ID to work reliably for upserts, it must be unique. If the legacy ID values are not unique, the upsert operation will fail because Salesforce won't be able to determine which single record to update. Therefore, selecting the Unique attribute is mandatory to ensure data integrity and the success of the upsert process.

Why B (Required) is Incorrect:
While you might want this field to be populated, making it Required is not necessary for the upsert operation to work. The upsert process only uses the External ID to find a match. If the field is blank in your source file for a new record, the upsert will simply create a new record with a blank value in that field. Making it required could unnecessarily complicate your data load if the legacy system has any missing IDs.

Why D (Text (encrypted)) is Incorrect:
An encrypted text field cannot be used as an External ID or have a unique index. The encryption prevents Salesforce from indexing the values, which is a prerequisite for both the External ID and Unique attributes. Therefore, this field type is incompatible with the stated requirement.

Reference:
Salesforce Help Article: "Upserting Records" and "External ID Fields." The documentation clearly states that an external ID is a field that can store a record identifier from a system outside of Salesforce and that you can use upsert to match against this field. It also notes that the field must have the "External ID" attribute selected and typically should be unique.

Explanation:

Salesforce provides several standard Opportunity fields that can be configured directly through the UI (Setup → Object Manager → Opportunity → Fields & Relationships). These fields can be customized in terms of:
Picklist values
Field-level security
Page layout visibility
Here’s how each correct option qualifies:
🔹 B. Stage
✅ Fully configurable picklist
You can define custom stages, assign probability percentages, and map them to forecast categories
🔹 C. Lead Source
✅ Standard picklist field
You can customize the values to reflect your organization’s lead generation channels
🔹 D. Type
✅ Standard picklist field
Often used to categorize Opportunities (e.g., New Business, Existing Customer)

❌ Why A. Forecast Category is incorrect:
Forecast Category
❌ Not directly configurable — it’s mapped to Stage values via the Sales Process setup. You can’t edit it independently.

🔗 Reference:
Customize Opportunity Fields – Salesforce Help
Sales Process and Stage Mapping – Trailhead

Explanation:

To upgrade an unmanaged package that is currently installed in a production org, the recommended process is to use the Installed Packages page in Salesforce Setup. An unmanaged package is a collection of components (e.g., custom objects, fields, workflows) that, once installed, cannot be upgraded in the traditional sense like managed packages because the source code and metadata remain editable by the installing org. However, if the package publisher releases an updated version, users can upgrade by navigating to Setup > Installed Packages, locating the package, and clicking the Update link (if available). This initiates the upgrade process, installing the new version over the existing one while preserving customizations made in the org.

Why not the other options?
A. Uninstall the current version and install the new version:
Uninstalling an unmanaged package removes all associated components and any customizations, which is not a viable upgrade path as it would require rebuilding custom work. This approach is disruptive and incorrect for upgrading.
B. Use the Install Wizard to install the upgrade to production:
The Install Wizard is used for initial installation of a package, not for upgrading an existing one. For an upgrade, the Installed Packages page provides the specific update mechanism, making this option inaccurate.
C. Install the new version to a Developer org then deploy to production:
This process applies to custom development or managed packages with change sets or deployment tools (e.g., Salesforce DX), not unmanaged packages. Unmanaged packages do not support deployment from a Developer org to production as a standard upgrade method, and this would overwrite the production org's customizations incorrectly.

Additional Notes:
The availability of an update link depends on the package publisher releasing a new version and the org having internet access to check for updates.
After clicking the update link, follow the prompts to review and confirm the changes, ensuring no conflicts with existing customizations.
Test the upgrade in a sandbox (if available) before applying it to production to mitigate risks, though this is a best practice rather than a required step.

References:
Salesforce Help: Install and Upgrade Packages (Explains the update process for installed packages).
Salesforce Trailhead: Package Basics (Covers unmanaged package behavior and upgrade options).
Salesforce Help: Unmanaged Packages (Details limitations and upgrade process).

Explanation:

Why this is correct:
Your custom report type’s primary object is Opportunities. Because Opportunity looks up to Account, you can edit the report type layout and use Add fields related via lookup to pull in fields from the parent Account—such as Account → Rating—so they’re selectable in reports built from that type.

Why the others are wrong:
A. Change the primary object to Account — You can’t change a report type’s primary object after creation, and switching to Account wouldn’t match the “Opportunities with or without Shipments” use case.
B. Add the Account Rating field to the opportunity record page — Page layouts don’t control reportable fields. Reporting availability comes from the report type layout, not the record page.
D. Change the account/opportunity relationship to master/detail — The standard Account–Opportunity relationship is a lookup and can’t be made master-detail. It’s also unnecessary; related lookup fields are reportable via the custom report type layout.

Reference:
Custom Report Types → Edit Layout → Add fields related via lookup (lets you include parent-object fields like Account fields on an Opportunity-based report type).

Explanation:

Ursa Major Solar (UMS) currently uses a public sharing model for accounts (likely Public Read/Write or Public Read Only), and they want to move to a more restrictive sharing model (e.g., Private) while ensuring the Sales team retains access to all accounts with the Sales record type. This requires adjusting the organization-wide defaults (OWD) and using a sharing rule to grant specific access. Here’s how:
B. Update the organization-wide defaults:
Changing the OWD for the Account object to a more restrictive setting (e.g., Private) is the first step to enforce a tighter sharing model. This limits access to account records to the record owner and users with higher access (e.g., via roles or sharing rules), replacing the public access model. This aligns with the goal of moving to a restrictive sharing model.
C. Create a criteria-based sharing rule:
A criteria-based sharing rule can grant access to all accounts with the Sales record type to the Sales team. The rule can be configured with a criterion like RecordType.Name = 'Sales' and share those records with a public group, role, or role hierarchy containing the Sales team members, setting access to Read Only or Read/Write as needed. This ensures the Sales team retains access to the specified records post-OWD change.

Why not the other options?
A. Update the Sales profile:
Updating the Sales profile (e.g., modifying object or field permissions) does not directly address record-level access based on record type. Profiles control permissions (e.g., Create, Read, Edit) but not sharing rules or record visibility, which are managed by OWD and sharing rules. This is insufficient for the requirement.
D. Create an owner-based sharing rule:
An owner-based sharing rule grants access based on the record owner’s role or public group (e.g., sharing records owned by Sales reps with managers). However, this does not guarantee access to all accounts with the Sales record type, especially if ownership varies across teams. A criteria-based rule is more precise for targeting record type, making this less suitable.

Implementation Notes:
Change the Account OWD to Private via Setup > Security > Sharing Settings.
Create a criteria-based sharing rule under Sharing Settings > Account Sharing Rules, setting the criterion to RecordType.Name = 'Sales' and assigning access to the Sales team’s role or public group.
Test the change in a sandbox to ensure no unintended access restrictions occur.

References:
Salesforce Help: Set Organization-Wide Sharing Defaults (Explains OWD configuration).
Salesforce Help: Create Criteria-Based Sharing Rules (Details how to use record type in sharing rules).
Salesforce Trailhead: Data Security (Covers OWD and sharing rule concepts).

Explanation:

The two considerations that an app builder should keep in mind during the deployment process using change sets are:
Change sets do not include all components and may have to perform some changes manually. Change sets are a way to deploy metadata changes from one Salesforce org to another, but they do not support all types of components, such as reports, dashboards, email templates, etc.
The app builder may have to use other methods, such as unmanaged packages or manual configuration, to deploy these components.

Users should be logged out of production when receiving inbound change sets. This is a best practice to avoid any errors or conflicts that may occur when deploying changes to production.
Users may be working on records or components that are being updated by the change set, which may cause data loss or inconsistency. Salesforce Connect does not automatically establish a link between environments. Salesforce Connect is a feature that allows users to access data from external sources without storing it in Salesforce. It does not have anything to do with deploying changes between Salesforce orgs. Transactions will not revert if the deployment errors.

Transactions are units of work that are either completed entirely or not at all. If a deployment error occurs during a transaction, the transaction will be rolled back and no changes will be made to the target org. However, this does not mean that the source org will revert to its previous state before the deployment.

Explanation:

Why:
An approval process enforces sign-off before a record can proceed. You can set entry criteria like “Part Price = 0” (or a “Free Part” checkbox) and route submissions to the Marketing Director. Until approved, actions (like fulfillment) can be blocked via record locking and validation/workflow.

Why the others are wrong:
A. Stack post — Not a Salesforce control mechanism (and not a standard Salesforce feature). Doesn’t enforce authorization.
B. Chatter approval — There’s no separate “Chatter approval” feature. Chatter can notify about approvals, but the approval process is what enforces sign-off.
C. Automated email message — Sends notifications only; it doesn’t require or record an approval decision.

Reference:
Salesforce Help — Create an Approval Process / Approval Processes Overview (sets criteria, approvers, actions, and record locking).

Explanation:

The requirement is to allow users to quickly create child accounts from a parent account record page, with several fields pre-populated from the parent. This calls for a streamlined UI action directly on the account page.

Why D is Correct:
A custom action (specifically, an object-specific quick action) is the ideal solution. The App Builder can create a "Create Child Account" quick action on the Account object. This action can be placed on the Account page layout. When configured, it can pre-populate fields on the new child account record (e.g., Parent Account, Billing Address, Phone, etc.) from the values in the current parent account record. This provides a one-click solution for users right from the context they are working in.

Why A is Incorrect:
Path is a guidance tool that helps users understand what stage a record is in and what to do next. It is not used for creating related records or pre-populating fields. It is purely a visual indicator and navigational aid within the Lightning Experience.

Why B is Incorrect:
A custom link is a URL that can be added to a page layout. While it could potentially link to a pre-populated edit page, it is a much less seamless and more complex solution than a quick action. It often requires writing URL parameters and does not provide the integrated, form-based experience that a quick action offers.

Why C is Incorrect:
A Global Quick Action is not tied to a specific record. It is accessible from the global navigation bar and does not have the context of the parent account record from which the user is trying to create a child. Therefore, it cannot automatically pre-populate fields from that parent account. An object-specific quick action (a type of custom action) is the correct choice here.

Reference:
Salesforce Help Article: "Create Actions." Object-specific actions are designed to let users quickly create records and log tasks from within the context of a related record, and they support pre-populating field values from the source record.