Salesforce-Platform-Administrator-II Practice Test Questions (2026)

Explanation:

A year-over-year (YoY) change calculation requires comparing a value from the current period (e.g., this year) with the value from the same period one year ago (e.g., last year). This is a sequential comparison across grouped data.

Let's analyze the options:

A. A row-level formula to compare amounts grouped by year. (Incorrect)
A row-level formula calculates a value for each individual row (record) in the report. It cannot access summary data from other groups or years. Since the YoY calculation requires the total for one year compared to the total for the previous year, a row-level formula is useless for this task.

B. A joined report with two report blocks for each year (Incorrect)
While a joined report could technically display the totals for two different years side-by-side, it is a manual and non-dynamic process. You would have to create and maintain two separate report blocks with different date filters. More importantly, a joined report cannot perform a calculation between the two blocks. You could see last year's total and this year's total, but you could not have a third column that automatically calculates the difference or percentage change.

C. A custom summary formula with PARENTGROUPVAL function (Incorrect)
The PARENTGROUPVAL function is used to reference a value from a parent grouping level in a hierarchy (e.g., getting the total for a Quarter to calculate the percentage of the Year total). It is not designed to access the value from a previous sibling group, like the previous year.

D. A custom summary formula with the PREVGROUPVAL function. (Correct)
The PREVGROUPVAL function is specifically designed for this type of sequential analysis. It allows a custom summary formula to retrieve the value of a summary field from the previous group in a series.
How it works: You would create a summary report grouped by "Fiscal Year" (or Closed Date grouped by Year). You would then create a custom summary formula that uses PREVGROUPVAL to get the total amount from the previous year's group and subtract it from the current year's total to find the change.
Sample Formula: (SUM(Amount) - PREVGROUPVAL(SUM(Amount), FY)) / PREVGROUPVAL(SUM(Amount), FY)
This would calculate the percentage change from the previous fiscal year.

Reference:
PREVGROUPVAL Function: A summary formula function that returns the value of a summary field from the previous group in the report. It is the essential tool for creating period-over-period comparisons, such as month-over-month or year-over-year changes.
Custom Summary Formulas: These are used to perform calculations on summarized data (like sums and counts) in a report, rather than on individual record data.

Explanation:

Why:
Use Dynamic Forms on the Membership Details Lightning record page to show/hide fields (or entire Field Sections) based on the running user’s profile: show all sections for Marketing; show only the “Support preferences” section for Support. This controls what appears on the page without changing data access. Keep Field-Level Security (FLS) with Read access for both profiles so both can report on all fields (reports rely on FLS, not page layout visibility).

Why not the others:
A. Two record types + two page layouts – Record types are unnecessary; the requirement is user-based display, not different business processes. Dynamic Forms handles conditional display per profile without new record types.
C. Permission set with Muting – Muting permissions are for Permission Set Groups, not a mechanism to conditionally show fields on a page. They don’t solve per-profile page display.
D. Field-Level Security – Using FLS to hide fields would also hide them from reports; the ask says both groups must be able to report on all data. Page/UI visibility should be handled with Dynamic Forms, not by removing FLS access.

Build tips:
Add “Support Preferences” as a Fields Section; set Visibility rule: Profile equals Support.
Leave other sections visible to Profile equals Marketing (or not restricted).
Ensure FLS “Read” on all fields for both profiles so reporting works as requested.

Explanation:

✅ The correct solution is option D.
In a many-to-many relationship, access to the junction object records (Item) is governed by the sharing settings of the two parent objects (Account and Quota). The requirement states that a new account owner can only see an Item record if they also own the related Quota record. This indicates that the Organization-Wide Default (OWD) sharing settings for the Item object are likely set to Private, and sharing is controlled by its parent relationships.
For a user to see a junction object record, they must have at least Read access to both parent records involved in that relationship. Therefore, explicitly ensuring that the account owner has Read access to the Quota object (likely through a sharing rule, permission set, or team) is the direct and necessary step to grant access to the Item records, as it satisfies the prerequisite for parent-driven sharing.

❌ Option A is incorrect and potentially dangerous. Changing a master-detail relationship to a lookup relationship is a significant data model alteration that can lead to data loss (as the required field becomes optional) and completely breaks the inherited sharing and cascade delete behavior. It does not solve the core issue of granting read access to the parent Quota records.

❌ Option B is incorrect and based on a misunderstanding of junction objects. In a many-to-many relationship, both relationships from the junction object (Item) to the two parents (Account and Quota) are of the same type (either both master-detail or both lookup). You cannot designate one as "primary" and the other as "secondary" for sharing purposes in the way this option suggests. Sharing is evaluated symmetrically for both parents.

❌ Option C is incorrect because criteria-based sharing rules are used to share records from a parent object to users or groups (e.g., share Quota records with a role). They cannot be used to grant access to a parent object (Quota) based on a change in a different, related object (Account). The ISCHANGED function operates only on fields within the object for which the rule is created (the Quota object). It cannot reference fields from the Account object.

Reference: This solution is based on the core Salesforce security principle of "sharing through a parent." The official documentation states that for a user to view a record of a junction object, they must have Read access to both associated parent records. This is a fundamental concept tested in the sharing and visibility designer certification and is critical for Platform Administrator II.

Explanation:

Here's the breakdown of why this is the necessary step:

The Conflict: The administrator's new validation rule was created directly in Production, which likely caused the development team's deployment to fail. The deployment likely contained code or metadata (like a trigger or a flow) that tried to insert or update records in a way that violated the new validation rule, as the developers had not tested their changes against this new rule.
The Solution (Testing in a Shared Sandbox): To prevent this, all non-emergency changes—whether admin-created (like validation rules) or developer-created (like custom code/metadata)—must be created and deployed through a consistent, shared environment. By creating the validation rule in a shared sandbox first (like a Full or Partial Sandbox), the development team could have:
Pulled the new validation rule into their development environment.
Tested their deployment against the rule in the sandbox.
Fixed any conflicts before attempting to deploy to production.

Evaluation of Other Options

A. Review the setup audit trail prior to changes.
The audit trail shows past changes. It might show the administrator created the rule, but it doesn't prevent the conflict or provide a test environment for the developers.
B. Refresh the full copy sandbox daily.
This creates a fresh copy of Production data, but doesn't establish the process of testing admin changes with development changes. The conflict would just happen the day after the refresh.
D. Build automation and validation rules using screen flows.
Validation rules and screen flows serve different purposes. While screen flows can enforce data entry (automation), they do not replace the record-level data integrity enforcement of a validation rule. This is not a preventative measure for a deployment conflict.

Explanation:

Correct Option Explanation:

✅ Option D: Page Layout.
Page layouts in Salesforce determine which fields, sections, and related lists are visible to users on the record detail page. When a sales user opens an Opportunity record, the fields they see in the details section are controlled directly by the assigned page layout. By editing the page layout, the administrator can add or remove fields, reorder sections, and tailor the record view specifically for new logo opportunities. This ensures sales users only see the fields relevant to their process, which makes data entry faster and keeps the interface clean. Page layouts are the standard tool for managing field visibility within record details in Lightning record pages.

Incorrect Options Explanations:

❌ Option A: Record Detail Component.
The Record Detail component in a Lightning page acts as the container that displays record details, but it does not control which fields show up. It simply renders whatever is configured on the page layout. If you place the Record Detail component on a Lightning record page, it pulls its field configuration from the assigned page layout. Therefore, this component is not the place where you configure fields.

❌ Option B: Custom Lightning Component.
Creating a custom Lightning component would allow developers to design highly specific field displays, but this is unnecessary and overly complex for the requirement. Salesforce already provides point-and-click control through page layouts. Using a custom Lightning component would introduce unnecessary development work and complexity when page layouts can solve the problem directly.

❌ Option C: Record Types.
Record types control business processes, picklist values, and which page layout is assigned to a record, but they do not themselves define which fields display. A record type may assign a different page layout to sales users for new logo opportunities, but the actual field visibility is still configured at the page layout level. So while record types are related, they are not the tool to directly control fields in the record detail section.

🔗 Reference: Salesforce Help – Customize Page Layouts

✨ Key Takeaway:
If you need to control what fields users see in the record details section, always edit the Page Layout. Record types can assign layouts, and the Record Detail component displays them, but the actual field control comes from the page layout.

Explanation:

A bucket field in Reports lets you group existing picklist values into custom “buckets” without changing the underlying data or creating new fields. For CK’s request, you can create a report on Opportunities/Products (where the Shoe Type Preference field is available), add a Bucket on that picklist, and map specific values into two buckets (e.g., “List A” and “List B”). The report can then group, summarize, and chart by those two buckets.

Why not the others?

A. PREVGROUPVALUE: That’s a report formula function for comparing values between summary groups—not for remapping picklist values into categories.
B. Summary Formula: Useful for numeric calculations on summaries/subtotals, not for regrouping text/picklist values into categories.
D. Matrix Report: A layout that groups by rows/columns; it doesn’t create new categories or merge picklist values. You could display buckets in a matrix, but the bucket field is the needed functionality.

Explanation:

✅ The correct tool to evaluate the cause of errors is the Debug Log.
When users report errors during their work in the Salesforce interface, these errors are often caused by behind-the-scenes automation such as validation rules, processes, flows, or Apex triggers. The Debug Log is specifically designed to capture detailed, granular information about the execution of database operations, automation, and code. It records the exact error messages, stack traces, and the point in the logic where a failure occurred. This makes it the definitive tool for an administrator to diagnose why reps are encountering errors when they try to update the newly created leads, as it will reveal which specific rule or automation is failing and why.

❌ Option A, Login History, is incorrect.
This tool provides information about user logins, logouts, and authentication attempts (e.g., IP address, browser, time). It is used for auditing user access and troubleshooting login problems, but it provides zero insight into the errors occurring during data processing or automation within the application.

❌ Option C, Setup Audit Trail, is incorrect.
This is an administrative audit log that tracks changes made to your org's configuration and setup (e.g., who changed a field or modified a page layout). It is invaluable for tracking what was changed and by whom, but it does not monitor real-time user activity or log errors encountered by users during their daily work.

❌ Option D, Record History, is incorrect.
This refers to the tracked field history on individual records. It shows how the data on a specific record has changed over time and who changed it. While useful for auditing data modifications, it does not capture error messages or the underlying logic failures that cause those errors when a user tries to save a record.

Reference:
The use of Debug Logs is a primary method for troubleshooting system errors and is a core skill for any advanced Administrator. It is covered extensively in the Salesforce documentation on monitoring and debugging, which is a key domain for the Platform Administrator II exam.

Explanation:

Why this answer is correct
Public Groups are purpose-built for scenarios where you need to target a specific, heterogeneous set of users—often spanning different departments, profiles, and roles—for sharing and notifications. In Salesforce, Email Alerts (the action you use in Flow, Process, or Workflow) can be addressed to Public Groups directly, which makes them ideal for sending a single notification to “everyone on this project,” even when that team is a cross-functional mix. Because your project teams include users with different roles and different departments, you can’t rely on role-based or org-structure-based targeting; a group that you define explicitly for each project is the clean, least-surprising way to ensure exactly the intended recipients get the email when the Project status changes to Allocated.

Operationally, you would:

Create a Public Group per project (e.g., “Project Phoenix Team”), add the relevant users (and, if helpful, other groups/roles/subordinates),
Build a Record-Triggered Flow (or Process Builder/Workflow if still in use) on the Project object that fires when Status changes to Allocated,
Use an Email Alert action whose recipients include the corresponding Public Group.

This keeps the logic declarative and easy to maintain. When team composition changes, an admin (or delegated owner) simply adds/removes users in the group—no need to touch the automation or create complicated recipient logic. Importantly, Public Groups are recognized recipients in many places: Email Alerts, Report & Dashboard sharing, folder sharing, and record sharing (when combined with sharing rules), which keeps your “who is on this project” list reusable across the platform.
Finally, using Public Groups avoids security/visibility side effects. You are not reshaping your role hierarchy (which affects reporting rollups and implicit sharing), nor are you using queues (meant for record ownership handoff, not broadcast notifications). Public Groups give you precise targeting for the email without unintended consequences elsewhere. For an exam-style best practice answer, this is the standard, scalable choice: public group per project + email alert to that group.
Good references to review: Salesforce Help on Public Groups (creating and adding members) and Email Alerts (supported recipient types include Public Groups).

Why the other options are incorrect?

A. Configure a queue for the project team and have members view the queue’s list view.
Queues are designed primarily for record ownership and work distribution (e.g., Cases, Leads, custom objects set “Queue-enabled”), not for addressing notifications to a set of people. Adding users to a queue makes the queue the owner of records so members can claim or work those records; it does not inherently function as a mailing list for email alerts. While some automations can notify a record owner (which might be a queue for supported objects), that’s both indirect and brittle here: (1) it depends on using an object that supports queues and assigning the project record to the queue (not typical for a “Project” record), and (2) many project scenarios don’t want the queue to be the owner at all. Moreover, a queue doesn’t solve the requirement to notify all project team members just because status changes—you would still need logic to ensure the queue is the recipient, and even then, a queue is a single entity, not an explicit, flexible roster of varied users you can also reuse for sharing and reporting. In short, queues are the wrong abstraction: they’re for triage and assignment, not a clean cross-functional notification list. Public Groups exist precisely to aggregate users for sharing/notifications; queues don’t replace that function, and they can add ownership side effects you likely don’t want for Projects.

B. Use sharing rules to automatically share with the individual users in the project team.
Sharing rules control data visibility, not who receives an email. You can grant read/write access to project records to a set of users, roles, or groups with sharing rules, but that alone doesn’t send notifications to those users when status changes. You’d still need a separate mechanism (Flow/Email Alert) for sending the message—and when defining recipients in an Email Alert, you can’t target a list of “users who got access via sharing rules” as a dynamic recipient set. Practically, you’d end up duplicating membership logic in two places: once in sharing rules and again in the email’s recipient list. That’s harder to maintain and error-prone. Also, the question’s goal is ensuring proper users receive the email, not expanding access. Public Groups directly satisfy the recipient target; sharing rules alone do not provide an addressable notification audience.

C. Move the project users to the same role and send the email alert to everyone in the role.
Changing users’ roles just to target an email is an anti-pattern. The Role Hierarchy models management/reporting structure, influences implicit record access (role roll-ups), and affects many other areas (e.g., forecast rollups, reporting). Moving cross-functional project members into a single role merely to send an email breaks your org’s security model and reporting semantics. It also scales poorly: each new project would need a new role (or shuffling users across roles), causing constant churn and potentially violating the principle that roles reflect organizational lines, not ad hoc teams. Even if you could aim an Email Alert at a role, that list would include everyone in that role, not just the curated team for a given project. Because project teams are cross-role by design, a Public Group—which can include users from any role/department—is the correct, minimal-disruption solution.

Bottom line:
Queues are for ownership/work routing (not mailing lists), sharing rules grant visibility (not notifications), and roles reflect org structure (not ad hoc teams). Public Groups are the right construct to represent a project team and to receive a single email alert when the project status flips to Allocated.

Explanation:

Correct Option Explanation

✅ Option C: Account Teams.
Account Teams are the best way to give additional users access to an account when an organization is using a private sharing model. With an account team, the account owner or administrator can manually add specific users (such as an engineer) to an account and grant them predefined levels of access, such as Read Only or Read/Write, not only to the account itself but also optionally to related records like opportunities and cases. This allows fine-grained, record-level access without changing the overall security model. For AW Computing, this ensures the engineer only gets access to the accounts they are explicitly added to and does not receive unnecessary access to other accounts. This balances collaboration with data security.

Incorrect Options Explanations

❌ Option A: Permission Set.
Permission sets grant object-level and field-level permissions, but they do not provide access to specific records. For example, a permission set might allow an engineer to read all Accounts, but in a private sharing model, that does not override record ownership or sharing rules. So while permission sets are useful for adding functional permissions, they cannot solve the need for granting access to just one account record.

❌ Option B: Permission Set Group.
A permission set group simply bundles multiple permission sets together for easier assignment. Just like a single permission set, it controls object-level and field-level access, not record-level access. Assigning a permission set group to the engineer would give them broader permissions across the system, which does not meet the requirement of granting access to a single account securely.

❌ Option D: Custom Profile.
A profile controls baseline object, field, and system permissions for a group of users, but it also does not override record-level sharing. If the sharing model for accounts is private, a profile cannot grant an engineer access to specific account records. Changing a profile would instead affect all users assigned to it, which could unintentionally broaden access and violate data security principles. Therefore, profiles are not an appropriate solution here.

🔗 Reference: Salesforce Help – Account Teams

✨ Key Takeaway: In a private sharing model, use Account Teams to grant specific users (like engineers) access to a particular account while keeping overall data secure.

Explanation:

Why B is correct
Validation rules fire before workflow rules. A Workflow Field Update happens after the record is saved (in the workflow portion of the order of execution). Because validation has already run, the workflow can write a value that doesn’t get re-validated, leaving the record with data that violates the validation rule.
That’s why you can see invalid data even though a validation rule exists—workflow field updates don’t trigger validation again.

Why the others are incorrect
A. Update Records in Flow – Record-triggered Flows (before- or after-save) respect validation on any DML they perform. If a Flow performs an update that would violate a validation rule, the DML fails with a validation error rather than silently saving bad data.
C. Apex before trigger – Validation rules run after before triggers, so any invalid value set in a before trigger would be caught by the subsequent validation stage and blocked from being saved.
D. Modify All Data – This permission bypasses sharing constraints, not validation rules. Users (or automations acting in system context) don’t skip validation just because of this permission.

Admin tip
If you must keep the workflow, consider moving the logic to Flow so you can control timing and avoid bypassing validation unintentionally. Alternatively, redesign the validation to account for the workflow’s changes, or replace the workflow with before-save Flow updates so validation runs after those changes.