Free Platform-App-Builder Practice Test Questions (2026)

Explanation:

Changing the data type of custom fields in Salesforce has specific limitations that need to be considered to ensure system integrity and prevent errors:

A. It is not possible to change the data type of a formula field to any data type. Formula fields are calculated based on other field values and cannot be converted into a storage data type because they do not store data themselves.
D. It is not possible to change the data type of a Text Area (Long) field to Text. Text Area (Long) fields support up to 131,072 characters, which far exceeds the 255 character limit of standard Text fields. Converting such a field to a smaller capacity field would potentially lead to data truncation or loss.

For official guidance on data type changes, refer to Salesforce's Custom Field Considerations.

Explanation:

When importing Opportunities (or any other object that can use a currency) into a multi-currency org, it is critical to specify which currency each record should use. The standard CurrencyIsoCode field is used for this purpose.

Option C is correct:
The import file must include a column for the CurrencyIsoCode field. This column should contain the 3-letter ISO currency code (e.g., 'USD', 'EUR', 'GBP') for each record. This tells Salesforce which currency the Amount field on that specific Opportunity is in.

Option B is correct:
Data Loader is the appropriate tool for this import. It provides the flexibility to map the CurrencyIsoCode field from the import file to the corresponding field in Salesforce. The Import Wizard has more limitations and is generally not recommended for complex data models or for objects that require specific field mappings like CurrencyIsoCode.

Option A is incorrect:
You do not modify the actual currency Amount field itself to include the ISO code. The Amount field should contain only the numeric value (e.g., 1000.00). The association of that number to a currency is handled by the separate CurrencyIsoCode field.

Option D is incorrect:
This option is grammatically incorrect and nonsensical ("Use Import the currency ISO Code Column"). It seems to be a malformed repetition of the correct concept from option C.

Option E is incorrect:
The Import Wizard is a simpler, UI-based tool that is best for importing standard objects with simple data mappings. It is less suited for a multi-currency import where you need to ensure precise mapping of the CurrencyIsoCode field, making Data Loader the more reliable and powerful choice.

Reference:
Salesforce Help: "Enable Multiple Currencies" - Overview of the feature.
Salesforce Help: "Considerations for Working with Currency Fields" - Explains how currency data is handled, including the role of the CurrencyIsoCode field.
Salesforce Help: "Import Data with the Data Import Wizard" vs. "Import Data with Data Loader" - The documentation for these tools highlights the advanced capabilities of Data Loader for complex data operations.

Explanation:

Ursa Major Solar needs to model a many-to-many relationship between:
Contact (standard object)
Solar Project (custom object)
In Salesforce, the best practice for modeling many-to-many relationships is to use a junction object. This is a custom object that connects two other objects via two master-detail relationships.

✅ Why Option D is Correct
You create a junction object (e.g., “Project Contact Assignment”).
This junction object has:
A Master-Detail relationship to Contact
A Master-Detail relationship to Solar Project
This setup allows:
One Contact to be linked to many Solar Projects
One Solar Project to be linked to many Contacts
The junction object holds the relationship records and inherits ownership and sharing from both master objects.

❌ Why the Other Options Don’t Work
A. You cannot have two master-detail relationships directly on the Contact and Solar Project objects. That doesn’t create a junction object.
B. Two lookup relationships on a custom object would work, but lookup relationships don’t support roll-up summaries or strict referential integrity like master-detail does.
C. One lookup on each object doesn’t create a junction object and doesn’t support many-to-many relationships.

📘 Reference
You can read more in Salesforce’s official guide to many-to-many relationships

Explanation:

Roll-up summary fields can only reference formula fields if the formula itself is deterministic. This means the formula field's value must not change unless one of the fields it references is updated on the same record. If the formula is not deterministic, a roll-up summary cannot rely on it because the value could change at any time, leading to inaccurate summarization.

B. A cross-object field reference in the formula field:
A formula field that references a field on a related record is considered non-deterministic for the purpose of a roll-up summary. The value of the referenced field on the related object can change independently, so Salesforce cannot reliably calculate the roll-up summary.
D. The NOW() function in the formula field:
Functions that calculate values based on the current time, such as NOW() and TODAY(), are inherently non-deterministic. Their value changes constantly, so they cannot be used in formula fields that are referenced by a roll-up summary.

Why the other options are incorrect
A. A cross-object workflow updating a field referenced by the formula field:
A workflow rule that updates a field will only fire under specific conditions (e.g., when a record is created or edited). A roll-up summary field can correctly handle this, as it recalculates whenever a child record is saved, potentially triggering the formula update. This doesn't prevent the formula field from being referenced.
C. The CASE() function in the formula field:
The CASE() function is a deterministic function. As long as all the fields referenced by the CASE() function are on the same object as the formula field, it can be successfully used in a roll-up summary.

Explanation:

Why:
You can validate an inbound change set in Production ahead of the window. Validation runs the tests and confirms the deployment without actually deploying, so any issues are caught early. After a successful validation, you can use Quick Deploy during the window (even if the developer is away), which is faster because tests don’t need to re-run.

Why not the others:
A. Removing Apex classes just to avoid tests is risky and defeats the purpose; plus the classes are part of what you intend to deploy.
C. “Use a metadata package set” isn’t a standard Salesforce change-set step.
D. There’s no such thing as validating the outbound change set; validation happens on the inbound change set in the target org.

Tip:
After validation succeeds, monitor it on Deployment Status and Quick Deploy within the allowed window.

Explanation:

During an active approval process, a record lock is typically applied to prevent changes that could undermine the integrity of the approval. The specific behavior is controlled by the "Lock the record during the approval process" setting on the approval process definition.

Option A is correct:
If the approval process is configured to lock the record (which is a common and recommended practice), any user, including the submitter, who tries to edit the record will receive a notification that the record is locked. They will be unable to make any edits until the record is recalled, rejected, or approved.

Option B is incorrect:
The record lock applies to the entire record, not just specific fields. If the record is locked, no edits are permitted to any field.

Option C is incorrect:
While the manager may be assigned as an approver, ownership of the record does not automatically change upon submission. Ownership only changes if a field update is specifically configured in the approval process to reassign the record.

Option D is incorrect:
This is not how record locking works. The lock is on the entire record. The user would not be able to edit the name or the description.

Key Consideration:
An app builder can configure the approval process to not lock the record, which would allow certain edits. However, the default and most secure behavior is to lock it. Since the question does not specify otherwise, we assume the standard, locked behavior. The most accurate and general answer is that the user will be prevented from editing by a record lock notification.

Reference:
Salesforce Help: "Lock Records During Approval" - This article explains the record locking behavior: "While a record is locked, only users with the “Modify All” object-level permission can edit the record. Other users can’t edit the record until it’s unlocked... When a user who doesn’t have “Modify All” permission tries to edit a locked record, a message appears saying that the record is locked."

Explanation:

When a master-detail relationship is created between two objects in Salesforce:
The child object (Star__c) is tightly bound to the parent object (Galaxy__c).
Salesforce automatically generates a standard report type in the format: “Galaxy__c with Star__c”
This report type allows users to build reports that show Galaxy__c records along with their related Star__c records, perfect for analyzing parent-child data in one view.

🔍 Why the Other Options Don’t Work
A. Incorrect format — the report type is named after the parent WITH child, not the other way around.
B. No need to manually create a custom report type — Salesforce handles this automatically for master-detail relationships.
D. Same issue — a custom report type is not required in this scenario.

📘 Reference
Salesforce confirms this behavior in their documentation on Criteria to Generate a Standard Report Type

Explanation:

Since the organization-wide default (OWD) for opportunities is Private, record access must be granted to users who don't own the records. The sales operations team needs both read and write access to all opportunities, so these two solutions are the best approach:
A. Create a criteria-based sharing rule to all opportunities with the sales operations public group: Sharing rules are used to automatically grant access to groups of users beyond the OWD. Since the sales operations team needs access to all opportunities, a criteria-based sharing rule can be set up for Opportunity.RecordType equals (the record type of all opportunities). This rule would grant "Read/Write" access to a Public Group containing all the members of the sales operations team.
C. Add a permission set with 'View All' and 'Modify All' opportunity permissions enabled: The "View All" and "Modify All" object permissions ignore sharing rules and settings, giving users access to all records for a specific object, regardless of the sharing model. This is an efficient way to grant broad access to a specific team.

Why other options are incorrect
B. Add a manual share for all opportunities with each user on the sales operations team: This is not a scalable solution. With a large number of opportunities, manually sharing each one with every team member would be extremely time-consuming and difficult to maintain. Sharing rules automate this process.
D. Create a criteria-based sharing rule to share all opportunities with the sales operations private group: Sharing rules are used to grant access to public groups, roles, and territories, not private groups. Private groups are typically used for more manual, ad-hoc sharing.

Explanation:

Why:
In Salesforce approvals, a manager can designate a Delegated Approver on their user record. If the approval step is configured to allow it (“The approver’s delegate may also approve this request”), the delegate can approve while the manager is away—keeping the leaderboard current at quarter-end.

Why not the others
A. Forwarding the email doesn’t grant approval rights in Salesforce. The recipient must be the approver or a configured delegate.
C. Having the manager log in to reassign isn’t practical when they’re on vacation; delegated approver is the intended mechanism.
D. You don’t use Process Builder to assign a delegated approver; it’s set on the manager’s User record (Delegated Approver field and preferences).

Tip:
Confirm each approval step has “approver’s delegate may also approve” enabled so the delegate can act.

Explanation:

DreamHouse Realty (DHR) is planning to migrate Cloud Kicks' Salesforce org from Salesforce Classic to Lightning Experience and is looking for prebuilt resources to assist with the migration and overall adoption. Let’s analyze each option to determine the best source for these resources:

Option A: Import Wizard
This is incorrect. The Data Import Wizard is a tool for importing data into Salesforce objects (e.g., leads, contacts, or custom objects) from CSV files. It is not designed to provide prebuilt resources for migrating to Lightning Experience or aiding user adoption.
Option B: Lightning Object Creator
This is incorrect. The Lightning Object Creator is a tool that allows users to create custom objects from spreadsheets by automatically generating fields and layouts. While useful for creating new objects, it does not provide prebuilt resources specifically for migrating to Lightning Experience or supporting adoption.
Option C: AppExchange
This is correct. The Salesforce AppExchange is a marketplace offering a wide range of prebuilt apps, components, and solutions, many of which are designed to facilitate the transition from Salesforce Classic to Lightning Experience. For example, AppExchange provides tools like the Lightning Experience Transition Assistant, adoption kits, training modules, and third-party apps that help with migration planning, user training, and enhancing Lightning adoption. These resources can include prebuilt reports, dashboards, Lightning components, and guided adoption paths tailored to Lightning Experience.
Option D: Flow Builder
This is incorrect. Flow Builder is a Salesforce tool for creating automated processes and guided user experiences (e.g., screen flows or record-triggered flows). While it can be used to build custom solutions to enhance the Lightning Experience, it does not provide prebuilt resources specifically for migrating to or adopting Lightning Experience.

Additional Notes:
The Lightning Experience Transition Assistant (available in Setup within Salesforce) is a key internal tool for guiding the migration process, but since the question specifically asks about prebuilt resources, AppExchange is the best answer because it offers a broader range of external tools, apps, and adoption resources.
AppExchange solutions may include free or paid apps, such as Lightning adoption tools, training content, or prebuilt Lightning components that streamline the user experience and support the transition.
For adoption, AppExchange also offers resources like Trailhead-based adoption kits or third-party training apps that help users learn Lightning Experience features.

References:
Salesforce Documentation: AppExchange Overview
Describes the AppExchange as a source for apps and solutions to enhance Salesforce functionality, including Lightning adoption tools.
Salesforce Help: Transition to Lightning Experience
Mentions AppExchange as a resource for finding tools and components to support the Lightning Experience migration.
Salesforce AppExchange: Lightning Experience Apps Lists apps and solutions specifically tagged for Lightning Experience support.