Text preview & study summary

Salesforce ADM-201 - Certified Administrator - Security Automation Objects Data Reports

A free sample of 5 questions from this quiz, shown in full with answer choices and explanations. No interactivity — everything is visible on this page for study and review.

Want to test your knowledge? Launch the Interactive Exam Simulator

Question 1

An administrator is building a report to show the number of Closed Won Opportunities by Sales Rep for the current fiscal year, grouped by month. Which Salesforce report type should be used?

Answer choices

  • A. Tabular Report

  • B. Summary Report grouped by Owner Name (rows) and Close Month (columns) with a COUNT or SUM of Amount in the cross-tabular matrix

  • C. Matrix Report with Owner Name as Row Group and Close Month as Column Group, filtered on Stage = Closed Won and Close Date = Current Fiscal Year (Correct)

  • D. Joined Report combining Opportunities and Users objects

Explanation

A Matrix Report with rows grouped by Sales Rep (Owner) and columns grouped by Close Month provides the exact view requested — each cell shows the count of Closed Won Opportunities (or sum of Amount) for a specific rep in a specific month. Filters: Stage = Closed Won, Close Date = Current Fiscal Year. This gives a cross-tabular view that makes it easy to compare rep performance month-by-month. Option A (Tabular) shows a flat list with no grouping — can't summarize by rep and month. Option B describes a Summary Report (single-dimensional grouping) — Summary Reports group by rows but provide column-based cross-tabulation only in Matrix format. Option D (Joined Report) combines data from multiple report blocks — useful for combining objects but overkill for this single-object analysis.

Question 2

An administrator wants to allow a specific group of users to edit Opportunities even when the Opportunity is in a "Locked" state (post-approval process lock). What feature enables this?

Answer choices

  • A. Create a Permission Set granting "Modify All" on Opportunities

  • B. In the Approval Process configuration, add these users to the "Locked Record Edit" list; alternatively, grant the "Modify All Data" system permission which overrides approval locks (Correct)

  • C. Configure an After-Save Flow to automatically unlock records for these users

  • D. Change the Opportunity sharing settings to Public Read/Write

Explanation

Salesforce Approval Processes include a locking mechanism that prevents record editing after a record is submitted for approval (or approved). The override options are: (1) In the Approval Process settings, specify specific users who can edit locked records; (2) Users with the "Modify All Data" or "Modify All" permission on the object can edit locked records regardless of approval status. Permission Sets can be used to grant "Modify All" on Opportunities to a specific group without giving them system-wide Modify All Data. Option A (Modify All Permission Set) grants edit access on all Opportunity records beyond just locked ones — may be appropriate depending on the business need. Option C (Flow to auto-unlock) would unlock records for everyone, not just specific users. Option D (Public Read/Write sharing) affects sharing visibility, not approval locks.

Question 3

A Salesforce administrator is setting up a new product: Solar Panel Installation. Opportunities for this product must capture different fields than standard Opportunities (e.g., Panel Count, Installation Date, Roof Type). Different stages are also required. What Salesforce feature enables this?

Answer choices

  • A. Create a new Custom Object called "Solar Opportunity"

  • B. Create an Opportunity Record Type for "Solar Installation" with a custom Page Layout showing Solar-specific fields (Panel Count, Installation Date, Roof Type as custom fields), and configure a custom Sales Path with Solar-specific stages in the Opportunity Stage picklist (Correct)

  • C. Add all Solar fields to the standard Opportunity object and use Profiles to hide non-relevant fields

  • D. Use Field Sets to dynamically show different fields based on user profile

Explanation

Record Types in Salesforce enable: different picklist values (different Opportunity stages for Solar vs. standard sales process), different Page Layouts (Solar fields visible only on Solar Opportunity records), and different process configurations (Sales Path). A Record Type "Solar Installation" with its specific Page Layout shows Panel Count, Installation Date, and Roof Type without cluttering the standard Opportunity layout. Option A (custom object) loses native Opportunity functionality (pipeline, forecasting, activity tracking, standard reports). Option C (all fields + profile hiding) creates a cluttered object with many hidden fields — less maintainable and not role-appropriate. Option D (Field Sets) are used in Visualforce/LWC development for dynamic field rendering, not for business process differentiation.

Question 4

An administrator needs to ensure that sales managers can see all records owned by users in their team, while senior sales managers can see records from all teams below them. No sharing rules are needed. What Salesforce security component achieves this?

Answer choices

  • A. Sharing Rules sharing all Sales records to the Management team

  • B. Role Hierarchy: configure a Role Hierarchy with Senior Sales Manager at a higher level than Sales Managers, and Sales Reps at the lowest level; set OWD for Opportunities to "Private"; roles higher in the hierarchy automatically inherit read access to records owned by subordinate roles (Correct)

  • C. Create Permission Sets for each management level with expanded record access

  • D. Set Opportunity OWD to "Public Read Only" so everyone can see all records

Explanation

Role Hierarchy in Salesforce provides automatic record access inheritance upward: with Opportunity OWD = Private, a Sales Manager in the hierarchy automatically sees records owned by all Sales Reps in their reporting chain. A Senior Sales Manager positioned above multiple Sales Manager roles sees records from all teams below. This is configured entirely through role assignments — no Sharing Rules are needed. This exactly matches the requirement. Option A (Sharing Rules) would work but is unnecessary when the Role Hierarchy handles it automatically for management visibility. Option C (Permission Sets) grant object-level permissions (CRUD), not record-level access based on hierarchy. Option D (Public Read Only) gives everyone access to all Opportunities — too broad, as requirements specify team-based visibility only.

Question 5

A Salesforce administrator wants to ensure that when an Opportunity is Closed Won, the associated Account's "Last Won Opportunity Date" custom field is automatically updated to today's date. The Account is a related record (parent). What is the MOST appropriate declarative solution?

Answer choices

  • A. Create a Workflow Rule on Opportunity with a Field Update action — but note that Workflow cannot update related (parent) record fields

  • B. Create a Record-Triggered Flow on Opportunity that triggers when Stage = "Closed Won," uses a Get Records element to retrieve the related Account, then uses an Update Records element to set the Account's Last Won Opportunity Date = Today (Correct)

  • C. Ask developers to write an Apex Trigger to update the parent Account

  • D. Use a Roll-Up Summary Field on Account to calculate the last Closed Won date

Explanation

Record-Triggered Flows can update related (parent or child) records — a significant advantage over Workflow Rules, which can only update fields on the same record or fields on the directly related Master in a Master-Detail relationship. A Flow on Opportunity: Trigger = when record is updated, Entry Condition = Stage Equals "Closed Won," Get Records to retrieve the parent Account (via Opportunity.AccountId), Update Records on Account to set Last Won Opportunity Date = TODAY(). Option A — Workflow Rules can update fields only on the triggering record itself or its parent if it's a Master-Detail relationship, not a Lookup relationship. This is the key limitation. Option C (Apex Trigger) works but is unnecessary when Flow handles it declaratively. Option D (Roll-Up Summary) only works on Master-Detail relationships (not Lookup) and calculates COUNT/SUM/MIN/MAX, not a date update on a change condition.