Salesforce-Certified-Administrator Practice Test Questions

Explanation:

When your flow needs to search Salesforce for records that meet specified criteria and then hold values from those records for later use, the Get Records element is the correct choice. The Get Records element lets you point to any object, define filter conditions (for example, “Status = ‘Open’ AND Priority = ‘High’”), and store either a single record or a collection of records into flow variables. Once the records are retrieved, you can reference any of their fields throughout your flow—for example, to make decisions, assign new values, or update related records. Assignment, Create, and Update elements serve other purposes: Assignment simply sets variable values; Create Records writes new data; and Update Records changes existing data. None of those elements query Salesforce for existing records. Only Get Records provides the powerful, declarative ability to fetch data from the database for logic and processing downstream in your automation.

Explanation:

Salesforce does not allow users to select more than one value on a standard picklist—but multi-select picklists do. To enforce single-value selection going forward, you must convert the existing multi-select picklist to a standard (single-select) picklist. However, changing the field type can alter or clear existing data, so best practice is to back up current selections first (for example, via a report or data export) before making the change. After you switch the field’s data type in Setup, your Shoe Style field becomes a single-select picklist, ensuring users can choose only one style per record. If any historical values become inactive during conversion, you can also reactivate them afterward under the picklist’s value settings, but the two critical steps are data backup and field-type change.

Explanation:

When converting a Lead, Salesforce only automatically maps standard Lead fields to their corresponding Opportunity fields. Custom Lead fields must be explicitly mapped to custom Opportunity fields. To pass the “Product Category” from Lead to Opportunity upon conversion, you create a custom picklist (or text) field named “Product Category” on the Opportunity object, then go into Lead Field Mappings in Setup and map the custom Lead field to the new Opportunity field. From that point on, whenever a Lead is converted, Salesforce transfers the Product Category into the newly created Opportunity field automatically. Workflow or picklist settings on the Product object won’t accomplish this mapping, as only field-to-field mappings on the Lead Conversion page take effect.

Explanation:

Auto-response rules are designed to send instant email acknowledgements to customers when they submit cases, and they support multiple rule entries within a single rule. By creating one auto-response rule for your Ursa Major Solar org, you can then add three entries—one each for Low, Medium, and High priorities. Each entry’s criteria filters on Priority = Low/Medium/High and selects the corresponding email template. When a case is created via the web or Email-to-Case, Salesforce evaluates the entries in order: the first matching entry fires and sends its designated template to the customer. Assignment rules are for routing cases, workflow rules don’t email the case creator automatically, and you cannot create three separate auto-response rules—each org supports exactly one.

Explanation:

By default, when you set an object’s Organization-Wide Default (OWD) sharing to Private, records owned by subordinates are visible to their managers through the sharing hierarchy. For the feedback custom object, you want feedback records to remain invisible to anyone except their creator (and system administrators). After setting the OWD for the custom object to Private, you must disable hierarchy-based access so that managers in the “Direct Manager” field cannot see down into their team’s feedback. This is done by unchecking the “Grant Access Using Hierarchies” option on the object’s Sharing Settings. Criteria-based or owner-based sharing rules aren’t needed because you aren’t granting extra access; you’re strictly removing hierarchical visibility.

Explanation:

When HR needs a user’s access removed immediately, freezing the user is best practice: it locks the account so they cannot log in but preserves all ownerships and references. Because this user is set in a “Direct Manager” lookup on other records, you cannot deactivate them until no queries or formulas reference the lookup. Freezing avoids login while you update all records that point to them (or reassign that lookup). Deactivation immediately breaks those references and can cause errors; deleting a user is never allowed in Salesforce; changing their profile to read-only still permits API access. Thus, freeze first, then correct all Direct Manager lookups, and finally deactivate the user cleanly.

Explanation:

Picklist values in Salesforce can vary by Record Type. When users report different picklist options on Opportunity, it usually means their profile is seeing a different record type configuration. To update which values appear, you navigate to the Opportunity object, open each Record Type’s settings, and add or remove the picklist values under “Picklists Available for Editing.” Adjusting fields and relationships or the global value set affects all record types; lookup filters don’t control the master list; and picklist value sets manage the list of possible values but cannot assign them by record type. Only the Record Type interface allows you to tailor which values are visible on that type of opportunity.

Explanation:

The Highlights Panel on Lightning record pages displays fields defined in the Compact Layout. To surface your new custom text area in that panel, go to Setup → Object Manager → Account → Compact Layouts, either edit an existing compact layout or create a new one, and add your field to it. After saving, assign that compact layout as the primary layout for the org. There is no drag-and-drop in the page layout editor for the Highlights Panel, and making a field required or moving it in the standard page layout does not affect the compact layout. Only the compact layout controls which fields display in the header area.

Explanation:

To ensure reps complete key fields before advancing an Opportunity stage, combine three declarative features:

1. Validation Rules enforce that certain fields meet criteria (for example, close date must be populated) before a user can save a record—blocking stage progression until requirements are met.

2. Opportunity Path gives users visual guidance on each stage, and you can mark key fields as “Required” within the Path configuration so that users see inline reminders and tooltips for fields that must be filled in before moving past that stage.

3. Page Layout Required (via the wrench icon next to picklist fields) forces data entry on the layout itself.

Guided Selling (the older feature) is deprecated, and Flows to mark fields required adds unnecessary complexity when simpler, native tools already enforce data quality.

Explanation:

When you require the same picklist values across multiple objects (Accounts and Cases), you use a Global Picklist Value Set. Global picklists centralize your value definitions; you then create custom picklist fields on each object and point them to the global value set. Record Types can tailor which values are available per record type, but the underlying list of values comes from the global set. A standard custom picklist field without a global value set would require individually maintaining each field’s values. Dependent and multi-select picklists serve different use cases.