Platform-App-Builder Practice Test Questions

Explanation:

Why these are correct:

A. My Domain must be deployed
In Salesforce, you cannot use custom Lightning components (like ones from AppExchange or custom-built) in the Lightning App Builder until My Domain is enabled and deployed.
This is because Lightning Components rely on namespace isolation, which My Domain provides.
Without My Domain, the component simply won’t appear in the Lightning App Builder.

D. The component is tagged for record pages instead of home pages
When developing Lightning components, the developer sets targets in the component’s .xml configuration file (e.g., lightning__RecordPage, lightning__HomePage, lightning__AppPage).
If the component is only tagged for Record Pages but not for Home Pages, it won’t show up when you try to add it to the Home page.
This is a common real-world issue with downloaded components.

Why the others are incorrect:

B. A custom tab must be created ❌
Creating a custom tab has nothing to do with placing a component on a Home Page.
Tabs are for navigation, not for component visibility in the Lightning App Builder.

C. The component requires a developer permission ❌
There is no such thing as a special “developer permission” required just to place a component on a page.
The visibility is controlled by My Domain + component targets, not permissions like “Author Apex” or “Modify All Data.”

📖 Reference:
Salesforce Docs: Enable My Domain
Salesforce Dev Guide: Configure Lightning Component for Lightning Pages

Explanation:

Process Builder is the best tool for this scenario because it can handle complex automation tasks, including updating a field and sending an outbound message with a time delay. In this case, when a lift is sold, Process Builder can:

→ Update the “To Be Installed” checkbox field to “True” on the Lift object.
→ Schedule an action to send an outbound message to the external system the next day.

For example, if a lift is marked as sold on August 26, 2025, Process Builder can automatically check the “To Be Installed” box and schedule an outbound message to notify the external system on August 27, 2025. Process Builder supports time-based actions, which are perfect for the “next day” requirement, and it can trigger outbound messages, which are used to communicate with external systems.

Process Builder is flexible, user-friendly for App Builders, and designed to handle multi-step automation like this, making it the ideal choice.

Why the Other Options Are Incorrect?

A. Approval Process: An Approval Process is used to route records for approval, such as when a manager needs to approve a discount on a deal. For example, if a lift sale required manager approval, this would be appropriate. However, this scenario doesn’t involve approvals—it’s about automatically updating a field and sending a message. Approval Processes can’t handle field updates or time-based outbound messages, so this option doesn’t fit.

B. Workflow: Workflow Rules are a legacy automation tool in Salesforce that can perform actions like field updates or sending outbound messages when a record meets certain criteria. For example, a Workflow could check the “To Be Installed” box when a lift is sold. However, Workflow Rules don’t support time-based actions, so they can’t delay the outbound message until the next day. This limitation makes Workflow unsuitable for the full requirement.

C. Flow: Flows are powerful for creating complex automation or guided user experiences, like a screen flow to collect data or an autolaunched flow to update records. For instance, a Flow could update the checkbox and send an outbound message. However, scheduling a time-based action (like waiting until the next day) requires additional setup, such as combining Flow with a scheduled job, which is more complex than using Process Builder’s built-in time-based actions. Process Builder is simpler for this specific task.

Summary: Process Builder (Option D) is the best choice because it can update the “To Be Installed” checkbox and schedule an outbound message for the next day in a single, easy-to-configure process. Approval Process is for approvals, not automation; Workflow can’t handle time-based actions; and Flow is unnecessarily complex for this scenario.

Reference:
Salesforce Help: Automate Processes with Process Builder
This documentation explains how Process Builder can handle field updates, outbound messages, and time-based actions.

Explanation:

This question tests your understanding of how to automate visibility into critical business data changes. Let's analyze the requirement and the purpose of each Chatter feature.

The core requirement is to have field value changes appear prominently on Chatter. This is a classic use case for automation that broadcasts record-specific updates.

Why D is Correct: Feed Tracking is a native Salesforce feature designed explicitly for this purpose. When enabled for specific fields on an object (like Asking_Price__c and Real_Estate_Agent__c on the House__c object), any change to the value of those fields automatically generates a post in the Chatter feed for that particular record. This creates a transparent, auditable history of important changes right on the record's feed, keeping all stakeholders (agents, managers, etc.) immediately informed. It requires no additional user action; the post is generated automatically by the system upon change.

Why A is Incorrect: Thanks is a social feature within Chatter that allows users to show appreciation for a post, comment, or file. It is a reactive, manual gesture of recognition between users. It has no functionality related to automating notifications or tracking changes to data within fields. It is about human interaction, not system-generated data alerts.

Why B is Incorrect: Publisher Actions are customizable buttons in the Chatter publisher that allow users to perform quick actions, such as creating a record, posting a poll, or logging a call. They are tools for users to initiate an activity. The requirement, however, is for an automatic system-generated post triggered by a data change, not a manual action a user must take. Publisher Actions are the cause of a post, not the automated result of a field update.

Why C is Incorrect: Topics are a method of categorization and discovery in Chatter. Users assign topics to records, posts, or files to make them easily searchable and to follow trends (e.g., topics like "#Waterfront" or "#FixerUpper"). While a field change feed post could be assigned a topic, the Topics feature itself does not create the post about the field change. It is a tagging mechanism, not an automation tool for tracking data modifications.

Key Takeaway: Distinguish between features that automate information sharing (Feed Tracking) and those that facilitate manual social interaction (Thanks, Publisher Actions, Topics). When the requirement is "automatically post a system update when a field changes," Feed Tracking is the unequivocal and designed solution.

Reference:
Salesforce Help: Enable Feed Tracking
Trailhead: Keep Track of Records with Feed Tracking

Explanation:

To meet the requirements, the App Builder needs a relationship field that connects the gift card object to the Account object and enforces strict data integrity. The key phrase here is "permanently ensure the gift cards are unable to be moved across any other Account once it is created." A master-detail relationship is the only standard Salesforce relationship type that enforces this behavior.

A master-detail relationship creates a tight link between two objects. The child record (gift card) cannot exist without a parent record (Account). If the parent record is deleted, all associated child records are also deleted. Most importantly, a master-detail relationship field is not reparentable by default. This means that once a gift card is created and related to a specific Account, it cannot be reassigned or "moved" to a different Account. This directly satisfies the requirement.

Furthermore, a master-detail relationship is a prerequisite for creating roll-up summary fields, which are necessary to track the total number of gift cards opened and issued on the Account. This aligns perfectly with the other part of the request.

Why the Other Options are Incorrect?

B. Roll-up summary: A roll-up summary field is a type of field used to aggregate data from child records onto a parent record (e.g., counting the number of gift cards). However, it is a result of a master-detail relationship, not the relationship field itself. You must first create the master-detail relationship before you can create a roll-up summary field.

C. Formula: A formula field is used to perform calculations or display information based on other fields. It does not create a relationship between two objects, nor does it enforce any data integrity rules like preventing a record from being reassigned.

D. Lookup relationship: A lookup relationship is a loose link between two objects. It does not enforce a strict dependency, meaning a child record can exist without a parent. Crucially, a lookup relationship field is reparentable by default, which means a user could easily change the associated Account on a gift card record, directly violating the stated requirement to permanently lock the relationship.

References:
Salesforce Help Documentation: "Relationships Between Objects"
Salesforce Trailhead: "Data Modeling" module, specifically the units on "Relationship Fields."

Explanation:

Correct Answer:
D. Update the change set and re-deploy ✅

Why this is correct:
Once a change set is deployed, you can go back to the source org (Developer Sandbox), open the same outbound change set, and add/remove/update components.
After saving, you can upload it again to the target org (Developer Pro Sandbox) and then re-deploy.
This is the proper way to move updated components after initial deployment.

Why not the others:

A. Refresh the test sandbox and re-deploy the change set ❌
Refreshing a sandbox wipes it clean and resyncs it with production — you’d lose your testing work.
Not required just to update and redeploy a change set.

B. Clone the change set and re-deploy ❌
Cloning creates a new copy, but that’s unnecessary. You can simply update the existing one.
Cloning is more useful if you want a different version for another environment, not when you’re updating an existing deployment path.

C. Rename the change set, add the changes, and re-deploy ❌
Renaming does nothing functionally.
Deployment depends on the contents of the change set, not its name.

📖 Reference:
Salesforce Help: Upload Outbound Change Sets
Trailhead: Change Set Development Model

Explanation:

Why a Custom Detail Page Link on the Contract Object is Correct?
The requirement specifies that users need access to the pricing guidelines document when viewing a Contract related to an Account. A custom detail page link on the Contract object is the best solution because it allows users to directly access the document from the Contract record’s detail page. For example, an App Builder can create a custom link labeled “View Pricing Guidelines” that points to the document’s URL (e.g., a file stored in Salesforce Files or an external link). When a user views a Contract record, they can click this link to open the document instantly.
This approach is simple and precise, ensuring the document is accessible exactly where the requirement specifies—on the Contract record. Custom detail page links are easy for an App Builder to set up and can be added to the Contract object’s page layout, making them visible to users in the right context.

Why the Other Options Are Incorrect?

A. Quick Action on the Contracts object: Quick Actions are used to create or update records, log calls, or perform other actions, like creating a new Opportunity from a Contract. For example, a Quick Action could let users create a related task. However, Quick Actions are not designed for simply linking to a document. While you could create a custom Quick Action to open a URL, it’s overkill for this purpose, as a custom detail page link is simpler and more direct for accessing a static document.

B. Quick Action on the Account object: This option places the action on the Account object, not the Contract object. Since the requirement is about accessing the document when viewing a Contract, placing a Quick Action on the Account object would make it less convenient for users. For example, users would need to navigate away from the Contract to the related Account to access the document, which doesn’t align with the requirement’s context.

C. A custom detail page link on the Account object: Like the Quick Action on the Account object, a custom detail page link on the Account object would provide access to the document from the Account record, not the Contract record. This doesn’t meet the requirement, as users need the document when viewing a Contract. For instance, if a user is working on a Contract and needs the pricing guidelines, they shouldn’t have to go to the Account record to find it.

Summary: A custom detail page link on the Contract object (Option D) is the best choice because it provides direct, easy access to the pricing guidelines document from the Contract record, exactly where users need it. Quick Actions are better for creating or updating records, not linking to documents, and placing the link or action on the Account object is less convenient since the requirement focuses on the Contract context.

Reference:
Salesforce Help: Create Custom Buttons and Links
This documentation explains how to create custom detail page links to provide quick access to external content or files from a record’s detail page.

Explanation:

This scenario presents a classic data integration challenge: ensuring idempotency (the ability to apply the same operation multiple times without creating duplicates) during regular data loads from an external system. Let's evaluate the tools and strategies.

Why B is Correct: This is the definitive best practice for this use case.
Create a unique External ID field: The app builder should create a field on the Delivery__c object (e.g., Shipping_App_ID__c) and mark it as an External ID. This field will hold the unique identifier from the records in the external shipping application. This tells Salesforce that this field can be used as a key for matching records during data operations.

Use Data Loader: The Data Loader (or another API-based tool like the upsert command) can use this External ID field to perform an upsert operation. Upsert is a combination of "update" and "insert".

How it works: The file from the shipping application will include its own unique identifier for each delivery record in a column that maps to the External ID field.
If a record in Salesforce already has a matching value in the External ID field, that existing record will be updated with the new information from the file.
If no matching record is found, a new Delivery__c record will be created.
This method is robust, automated, and designed for the exact purpose of synchronizing data between systems.

Why A is Incorrect: The Import Wizard is a useful point-and-click tool for one-time or occasional data imports, typically limited to ~50,000 records. It is not the right tool for a process that needs to run "on a regular basis." Furthermore, while it can match on a standard field (like a tracking number), it lacks the robustness of using a designated External ID field made for this purpose. Automating repeated use of the Import Wizard is impractical and error-prone.

Why C is Incorrect: This option is fundamentally flawed. The Salesforce ID (a system-generated, 18-character unique identifier) exists only within Salesforce. The external shipping application would have no knowledge of Salesforce IDs for the records it owns. Therefore, it is impossible to "match on the Salesforce ID" when the source data is coming from an external system. The external system has its own unique keys.

Why D is Incorrect: Duplicate and Matching Rules are excellent declarative tools for preventing users from manually creating duplicate records in the Salesforce UI (e.g., when a sales rep is creating a new Contact). However, they are not designed or recommended for governing bulk data loads via the API, like those performed by Data Loader. These rules can be bypassed in API operations unless explicitly enforced, and using them for this purpose would be less efficient and reliable than the standard upsert pattern using an External ID.

Key Takeaway:
For recurring data integration tasks from an external system, the established pattern is:
Define an External ID field on the Salesforce object to store the external system's primary key.
Use an API tool (like Data Loader) to perform an upsert operation using that External ID as the match key.
This ensures seamless synchronization, updating existing records and creating new ones as needed, without duplicates.

Reference:
Salesforce Help: What is an External ID?
Salesforce Help: Upsert Records (Explains the upsert operation in Data Loader)

Explanation:

The core of the problem is to count the number of related records (cases) and display that count on a parent record (the account). This is a classic "roll-up" scenario.

Roll-up summary fields are the standard declarative solution for this kind of problem, but they are only available for master-detail relationships. The relationship between the Account and Case objects is a lookup relationship. Therefore, a roll-up summary field cannot be used directly to count cases on an account.

Flow is the modern, powerful declarative tool that can be used to overcome this limitation. A record-triggered flow can be built on the Case object. Whenever a case is created, updated, or deleted, the flow can:

1. Check if the case is open (e.g., IsClosed equals False).
2. Get all related cases for the parent account.
3. Count the number of cases.
4. Update a custom number field on the Account record with the total count.
This provides an accurate, real-time count that can be displayed on the account page layout.

Why the Other Options are Incorrect?

B. Approval Process: An approval process is used to automate the approval or rejection of a record based on a series of steps and criteria. It has no functionality for counting related records or updating a field with that count.

C. Roll-up summary: As explained above, this option is incorrect because the Account and Case objects have a lookup relationship, not a master-detail relationship, which is required for roll-up summary fields.

D. Custom object: A custom object is a custom database table you create to store information unique to your organization. While you would need to create a custom number field on the Account object to store the count, the custom object itself is not the mechanism for performing the calculation and displaying the data. It's the destination for the data, not the process.

Explanation:

Correct Answer:
C. The Partial sandbox is at capacity. ✅

Why this is correct:
A Partial Copy Sandbox includes data defined in the sandbox template, but it’s limited by the 5 GB of data storage or 10,000 records per selected object (whichever is less).
Since Shipping__c has 2 million rows in production, it far exceeds the 10,000 record cap for a Partial Sandbox.
Result: Only up to 10,000 rows could be copied — and if the sandbox template wasn’t set up to include Shipping, or if the object was too large, you could end up with no records at all.

Why not the others:

A. The sandbox was refreshed too early ❌
Timing of the refresh doesn’t affect whether the data is included — only the template and sandbox limits do.

B. The selected objects in the sandbox template ❌ (tricky!)
If Shipping wasn’t selected in the template, yes, it would have no data.
BUT the question says there are 2 million rows in production — this hints that it was selected, but the data volume exceeded the Partial Sandbox limit.
On the exam, “at capacity” is the better answer because that’s what explains the missing data in large-volume objects.

D. The sandbox is still populating data ❌
Once a Partial Sandbox is refreshed, the data is copied during the refresh.
You don’t have a “delayed population” issue like with some asynchronous processes.

📖 Reference:
Salesforce Help: Sandbox Types
Salesforce Help: Partial Copy Sandbox

Explanation:

Why Criteria-Based Sharing Rules Are Correct?
Criteria-based sharing rules are the best tool for this scenario because they allow you to share records based on specific field values. In this case, AW Computing wants to share Opportunities with the Type field set to “Service Agreement” with all users in the Service Manager role. A criteria-based sharing rule can be set up to check if the Opportunity Type equals “Service Agreement” and then grant read access (or more, if needed) to users in the Service Manager role.

For example, imagine an Opportunity record with Type = “Service Agreement.” The criteria-based sharing rule would automatically share this record with all Service Managers, allowing them to view it, even though the Opportunity object uses a private sharing model. This solution is declarative (no coding required), automated, and perfectly matches the requirement to share based on a field value (Type).

Why the Other Options Are Incorrect?

A. Owner-based sharing rules: Owner-based sharing rules grant access based on who owns the record, not based on the record’s field values. For example, you could use an owner-based sharing rule to share all Opportunities owned by users in the “Sales Team” role with the “Service Manager” role. However, this scenario requires sharing based on the Opportunity Type (“Service Agreement”), not the owner, so owner-based sharing rules don’t meet the requirement.

C. Apex sharing rules: Apex sharing rules involve writing custom code (Apex) to programmatically share records. For instance, you could write Apex to share Opportunities with Type = “Service Agreement” with Service Managers. However, this is unnecessarily complex because criteria-based sharing rules can achieve the same result declaratively, without coding. Apex sharing is typically used for complex sharing logic that can’t be handled by standard sharing rules, which isn’t the case here.

D. Manual sharing: Manual sharing allows users to manually share individual records with other users or roles. For example, an Opportunity owner could manually share a “Service Agreement” Opportunity with Service Managers. However, this is not automated and requires users to take action for each record, which is inefficient and doesn’t meet the requirement for automatic sharing when the Opportunity Type is “Service Agreement.”

Summary:
Criteria-based sharing rules (Option B) are the best choice because they automatically share Opportunities with Type = “Service Agreement” with users in the Service Manager role, based on a field value, in a private sharing model. Owner-based sharing rules focus on the owner, not field criteria; Apex sharing rules are overly complex for this task; and manual sharing isn’t automated, making it impractical.

Reference:
Salesforce Help: Criteria-Based Sharing Rules
This documentation explains how criteria-based sharing rules work, including how to share records based on field values like Opportunity Type.