Platform-App-Builder Practice Test Questions

Explanation:

This requirement can be met in different ways, but the question asks for the two most appropriate declarative (clicks-not-code) automation tools for this specific use case.
Why A (Escalation Rules) is Correct: Escalation Rules are explicitly designed for this exact purpose. They are built to monitor support cases and trigger actions (like sending an email alert to a user or queue) when a case remains in a certain status for a defined amount of time. You can easily set a rule that says: "If Status equals 'New' for more than 4 business hours, then send an email notification to the Director of Customer Service." Escalation Rules handle the timing and automation natively.
Why C (Process Builder) is Correct: Process Builder can also accomplish this by using a scheduled action. You could create a process that starts when a case is created or edited and meets criteria (e.g., Status is 'New'). The process would then schedule an action for 4 business hours later. That scheduled action would check if the case is still in the 'New' status and, if true, send an email alert. This is a powerful and flexible declarative approach.

Why B (Flow Builder) is Incorrect: While Flow is incredibly powerful for automating complex business processes, it is not the best tool for a time-based trigger like this on its own. You could potentially use a Scheduled-Triggered Flow, but this is a more advanced technique and is generally less straightforward for this specific use case than using a Process Builder scheduled action or an Escalation Rule.
Why D (Scheduled Apex) is Incorrect: Scheduled Apex is a programmatic (code-based) solution. While it would work (you could write a class that runs every hour to check for cases meeting these criteria), the question is aimed at a Platform App Builder who should prioritize declarative tools. Since declarative options exist that are perfectly suited for the task, Scheduled Apex is not the best choice.

Reference:
Escalation Rules: Salesforce Help Article: "Create Escalation Rules." This is the premier tool for time-based case actions.
Process Builder: Salesforce Help Article: "Use Scheduled Actions in Process Builder." This details how to use the "Schedule" node to create time-based logic.

Explanation:

Why:
With a master–detail between Shoe__c (master) and Subscription__c (detail), you can put a Roll-Up Summary field on Shoe__c to COUNT related Subscription__c records. That gives you the number of subscriptions sold per shoe catalog automatically.

Why not the others:
B. Lookup field — Doesn’t aggregate anything.
C. Master-detail relationship field — The relationship already exists; adding another doesn’t count records.
D. Number field — Static; would require manual updates or extra automation.

Explanation:

The solution that an app builder should use for this request is a lookup field. A lookup field is a type of relationship field that links two objects together and allows users to select a record from another object. The app builder can create a lookup field on the account object that references the user object and allows users to assign a customer service manager (CSM) to the account.

Option A is incorrect because a multi-select picklist field is not suitable for this request, as multi-select picklist fields allow users to select multiple values from a predefined list, not from another object.
Option B is incorrect because a picklist field is not suitable for this request, as picklist fields allow users to select one value from a predefined list, not from another object.
Option D is incorrect because a text field is not suitable for this request, as text fields allow users to enter any alphanumeric characters, not from another object.

Explanation:

The requirement is to create a formula field on the Order object that displays only the first five digits of the Zip Code from the parent Account’s custom text field, Zip_Code__c, which is formatted as a US ZIP+4 code (e.g., "12345-6789"). The Salesforce formula function LEFT is the most appropriate choice for extracting a specified number of characters from the start of a text string.

C. LEFT(Account.Zip_Code__c, 5):
The LEFT function extracts the specified number of characters from the left side of a text string. In this case, LEFT(Account.Zip_Code__c, 5) retrieves the first five characters from the Zip_Code__c field on the parent Account (e.g., "12345" from "12345-6789"). Since Order likely has a lookup or master-detail relationship to Account, the formula uses __c for the custom field (not __r, which is used for relationship names in formulas). This formula correctly meets the requirement.

Why not the other options?
A. BEGINS(Account.Zip_Code__r, 5):
The BEGINS function checks if a text string starts with a specified substring and returns a Boolean (true/false), not a portion of the string. For example, BEGINS(Account.Zip_Code__c, "123") would return true if the zip code starts with "123", but it cannot extract characters. Additionally, __r is incorrect here, as it’s used for the relationship name, not the field itself.
B. TEXT(Account.Zip_Code__c, 5):
The TEXT function converts a value (e.g., a number, date, or picklist) to a text string but does not support extracting a specific number of characters. It takes a single argument (e.g., TEXT(NumberField)), and adding a second argument like 5 is invalid syntax. This option doesn’t achieve the requirement.
D. LPAD(Account.Zip_Code__r, 5):
The LPAD function pads a text string with a specified character to reach a desired length, adding characters to the left if the string is too short. It does not extract characters. For example, LPAD("123", 5, "0") would return "00123", not truncate to five characters. Also, __r is incorrect for referencing the field directly.

Additional Notes:
The formula assumes a relationship exists between Order and Account (e.g., a lookup or master-detail field like AccountId). In the formula, Account.Zip_Code__c correctly references the custom field on the parent Account.
The US ZIP+4 format is typically "XXXXX-YYYY" (e.g., "12345-6789"), and extracting the first five digits ("12345") aligns with the requirement.
The formula field on Order should be set to return a Text output type to display the five-digit zip code.

References:
Salesforce Help: Formula Operators and Functions (Details the LEFT function for extracting characters).
Salesforce Trailhead: Use Formula Fields (Covers creating formula fields for custom logic). Salesforce Help: Custom Field Relationships (Explains referencing parent fields in formulas using __c).

Explanation:

When overriding standard buttons to prevent record creation, an App Builder must understand the capabilities and limitations of this feature.

Why B is Correct:
This is the primary mechanism for overriding a standard button. You can replace the standard "New" button's functionality with a custom Visualforce page or a Lightning component. This custom page could display an error message, redirect the user, or implement custom logic to control when record creation is allowed. This directly accomplishes the goal of preventing the default creation behavior.
Why C is Correct:
This is a critical consideration. Not all standard buttons can be overridden (e.g., the "Edit" button on the user detail page). However, even if a button cannot be overridden, you can almost always hide it from the page layout. This is a key alternative strategy for controlling user actions. For the "New" button on a related list, hiding it is a simple and effective way to prevent creation if an override is not possible or necessary.

Why A is Incorrect:
This statement is false. The ability to override a standard button is a global setting for that object. When you override the "New" button for an object, it is overridden everywhere that button appears—on the object's tab, in lookup dialogs, in list views, and in search results. You cannot change it in only some places.
Why D is Incorrect:
This statement is misleading and mostly incorrect. While you can override a standard button and you can relabel or relocate custom buttons on a page layout, you cannot relabel or relocate a standard button itself. The override replaces its functionality, but its position on the page layout is fixed unless you hide it.

Reference:
Salesforce Help Article: "Override Standard Buttons." The key points are that overrides use Visualforce pages/Lightning components, affect the button everywhere it appears, and that hiding buttons is a separate layout control. Understanding the difference between overriding (changing functionality) and hiding (removing from the UI) is essential for an App Builder.

Explanation:

The requirement is to concatenate four custom fields—Street__c, City__c, Planet__c, and Galaxy__c—into a single formula field that displays the result on two lines.
Option C fulfills this by:
Street__c & BR() &
City__c & ", " & Planet__c & " " & Galaxy__c

Street__c appears on the first line
BR() inserts a line break
City__c, Planet__c, and Galaxy__c are concatenated on the second line with proper formatting
This is the correct syntax for a Text formula field in Salesforce that includes a line break and concatenates multiple fields.

🔍 Why the other options don’t work:
A. Uses field names without __c suffix
Invalid references to custom fields
B. Just a string, not a formula
Doesn’t use field references or line breaks
D. No concatenation or formatting
Just lists field names without logic

🔗 Reference:
Formula Field Functions – Salesforce Help
BR() is a valid function in Text formulas to insert a line break

Explanation:

When an app builder creates a new field using Schema Builder in Salesforce, the field is added to the object and, by default, is accessible to all profiles unless specific field-level security (FLS) settings are configured afterward. This means that the field is visible and editable by all users, regardless of their profile, unless the app builder explicitly modifies the field’s visibility through Field-Level Security settings in the Profiles or Permission Sets. This default behavior ensures that new fields are immediately available across the organization, allowing for quick deployment, with the ability to restrict access later as needed.

Why not the other options?
A. Standard profiles:
Standard profiles (e.g., System Administrator, Standard User) do not receive exclusive default access. All profiles, including both standard and custom ones, inherit access to the new field unless restricted.
B. No profiles:
This is incorrect because new fields are not hidden by default; they are accessible to all users unless security settings are applied to limit access.
C. Internal profiles:
The term "internal profiles" is not a standard Salesforce classification, and access is not limited to internal users (e.g., employees) versus external users (e.g., partners or customers) by default. All profiles, including those for internal and external users, get access unless restricted.

Additional Notes:
After creating the field, the app builder should review and adjust Field-Level Security in the Profile or Permission Set settings to enforce the desired access levels (e.g., Read-Only, Hidden) based on organizational requirements.
This behavior applies to custom fields on custom or standard objects created via Schema Builder or the Object Manager.

References:
Salesforce Help: Field-Level Security (Explains that new fields are accessible to all profiles by default until FLS is configured).
Salesforce Trailhead: Customize a Salesforce Object (Covers field creation and default accessibility in Schema Builder).
Salesforce Help: Schema Builder Overview (Details the process of adding fields and their initial accessibility).

Explanation:

Why:
A junction object typically uses two master-detail relationships (here: Account Interest → Account and Interest). Access to a detail record is controlled by its master(s). To see a junction record, a user must have Read access to both parent objects. If the user lacks Read on Interest, they can still open the Account record, but the Account Interest related list items won’t be visible, nor will the Interest records themselves.

Why not the others:
A. Wrong—no Read on Interest means they can’t see Interest, and thus can’t see the junction records either.
B. Wrong—lack of Interest access doesn’t block visibility to the Account record.
D. Wrong—you can’t see the junction record at all without Read to both masters.

Explanation:

The import wizard only allows values to be imported into a dependent picklist if they match the appropriate controlling field. This ensures data integrity and prevents invalid values from being imported.
Custom picklist fields can be either controlling or dependent fields. This allows the app builder to create custom dependencies between custom picklists.
Checkbox fields can be controlling fields but not dependent fields. This allows the app builder to create dependencies based on checkbox values, such as true or false. Multi-select picklist fields can be dependent picklist fields but not controlling fields.
This allows the app builder to create dependencies based on multiple values selected in a multi-select picklist field. Standard and custom picklist fields can be dependent fields, but not all standard picklist fields can be controlling fields.
Some standard picklist fields, such as Lead Status or Opportunity Stage, cannot be controlling fields because they are used in other processes, such as lead conversion or sales path.

Explanation:

Why:
A record-triggered Flow on Account (run after save, on Update) can check if Type changed to “Past-Customer” and then update related Contact records to set Status = “Re-Market.” You can do this with Update Related Records (no loops needed).

Why not the others
A. Screen flow — requires user interaction; not automatic on field change.
B. Lightning component — UI component, not the right tool for background automation.
C. Validation rule — prevents bad data; it can’t update related records.