Free Salesforce Platform Administrator II Practice Test Questions

Explanation:

Salesforce Shield is a powerful suite of security tools that includes Shield Platform Encryption, Event Monitoring, and Field Audit Trail. When implementing Shield Platform Encryption, it's critical to understand how encryption interacts with Salesforce features — especially automation like Flows.

🔐 Why Option C Is Correct:
Paused Flows temporarily store data in the system while waiting for a user action or external event.
If the flow references encrypted fields, the data may be stored in an unencrypted state during the pause.
This poses a security risk, especially for sensitive data like PII, financial records, or health information.
Salesforce explicitly warns about this in Shield documentation — paused flows are not guaranteed to maintain encryption.

❌ Why the Other Options Are Incorrect:

A. Encrypted fields are able to be referenced in flows.
This statement is false.
Encrypted fields have limited support in Flows.
You cannot use encrypted fields in certain flow elements like decision logic, assignments, or formula fields.
They can be referenced in some cases, but with restrictions.

B. Einstein Lead Scoring is available on encrypted fields.
Einstein features do not support encrypted fields.
Encrypted data cannot be used in machine learning models, scoring, or analytics.
This is a known limitation of Shield Platform Encryption.

D. Shield Platform Encryption can be used with custom metadata types.
Custom metadata types are not supported by Shield Platform Encryption.
Encryption is available for standard and custom objects, but not for metadata.
This includes Custom Settings and Custom Metadata Types, which remain unencrypted.

📘References:
Shield Platform Encryption Considerations
Paused Flows and Encryption
Salesforce Shield Overview
These resources outline the limitations and risks associated with encryption in automation and metadata.

🎓 Exam Tip:
When a question involves encryption, always consider:
Feature compatibility (Flows, Reports, Einstein, Metadata)
Data lifecycle risks (Paused Flows, temporary storage)
Limitations on field types and usage
Shield is powerful, but not all features support encrypted data — and that’s a common exam trap.

Explanation:

This question tests your understanding of the Order of Execution. The key is to determine the sequence of events when a Case is created via an incoming email.

Here is the step-by-step logic:

Case Creation:
A new Case is created via an incoming email. At the moment of creation, the Case Source field is blank.
Process Builder Fires:
The Process Builder is triggered immediately upon record creation. It evaluates the criteria:
If Case is created using Email-to-Case... -> This condition is met.
The Process Builder then performs an immediate update to set the Case Source field to 'email'.
Auto-Response Rule Evaluates:
After the Process Builder has finished its update, the system evaluates auto-response rules. At this point, the Case record in the database already has Case Source = 'email' due to the Process Builder's action.
Rule Criteria Check: The auto-response rule checks its criteria:
Criteria 1: Case Source = 'email' -> This condition is now MET. It is associated with Template1.
Criteria 2: Case Source is blank -> This condition is NOT MET.
Result:
Since the first criterion is met (Case Source = 'email'), the auto-response rule sends an email using Template1.

Let's analyze why the other options are incorrect:

B. An email is sent out using Template and then Case Source updates to 'email'.
This is incorrect because it reverses the order. The Process Builder (which updates the field) runs before the auto-response rules are evaluated.

C. An email is sent out using Template and then Case Source updates to 'email'.
This is the same as option B and is incorrect for the same reason. It also vaguely references "Template" without specifying which one.

D. Case Source updates to 'email' and an email is sent out using Template1.
This is the correct sequence of events. The field updates first, then the email is sent using the template for the updated field value (Template1).

Key Concept:
This question tests the critical concept of the Salesforce Order of Execution. When a record is saved, automation tools run in a specific sequence. A key takeaway is that Process Builder and workflow rules execute their immediate actions before assignment rules, auto-response rules, and escalation rules are evaluated.

Reference:
Salesforce Help: Order of Execution
Specifically, note that steps 6-7 involve workflow rules and processes (which update the record), and step 9 involves assignment rules, auto-response rules, etc.

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:

Why these are correct:
To add members to an Opportunity Team, a user must (1) have Edit on Opportunity, and (2) be either the Opportunity owner or above the owner in the role hierarchy (or otherwise have Full Access). If a sales rep can’t update the record or its team, giving them the Opportunity ownership (A) will satisfy the “owner” requirement; alternatively, placing them above the owner in the role hierarchy (C) grants the necessary control to manage team members.

Why the other options are not correct

B. Edit on the Account object – Account permissions don’t control the ability to add Opportunity Team members. What matters is Opportunity edit access and ownership/role position for that specific Opportunity.

D. Transfer Account ownership – Changing who owns the Account doesn’t grant authority to manage the Opportunity Team. Team management rights are tied to the Opportunity (owner/role hierarchy), not the Account owner.

Exam tip
Remember the rule of thumb: Owner (or above owner in role hierarchy) + Edit on Opportunity = can add/update Opportunity Team. If a rep can’t add a teammate, fix Opportunity ownership/role position (not Account) and ensure they have Edit on Opportunity.

References
Salesforce Help: Add Teams to Your Opportunities — requirements include Read on Users, Edit on Opportunities, and being the Opportunity owner or above the owner in the role hierarchy.
Trailblazer Community (confirmed behavior): Adding Opportunity Team members requires owner or above-owner role position + appropriate permissions.
Salesforce Stack Exchange (consistent guidance): Only the opportunity owner or users above the owner in the role hierarchy can add/edit/delete Opportunity Team members.

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:

When an email is processed by Email-to-Case, the system creates the Case on behalf of the Automated Case User. This is a specific user license and user record used for system-generated actions.

For the Case to be created with the specified record type, the Automated Case User's Profile must have access to that record type. If the profile does not have the record type assigned, the system will default to the user's default record type, which is likely the one you are seeing instead of the intended one.

Let's analyze why the other options are incorrect:

A. The new Case Owner needs permissions to the new record type. The record type is assigned when the Case is created, which happens before ownership is assigned via assignment rules. The initial creation is done by the Automated Case User, not the final owner. The owner's permissions are irrelevant to the initial record type assignment.

C. A Case assignment rule is preventing the record type from being updated. Assignment rules control the Owner, Priority, and other fields after the Case is created. They do not have the ability to change the record type of a Case during the assignment process.

D. A validation rule is preventing the record type from being updated. A validation rule would cause the Case creation to fail entirely and result in a bounce-back email to the sender, not simply assign a different record type.

Key Concept:
This question tests the understanding of the Automated Case User's critical role in system-generated record creation. For any automation that creates records (like Email-to-Case, Web-to-Case, or Community), the user context under which the record is created must have the necessary object and record type permissions.

Reference:
Salesforce Help: Assign the Automated Case User
Salesforce Help: Troubleshoot Email-to-Case (Often points to record type permissions for the Automated Case User as a solution).

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:

A. Flow: This is the most appropriate automation tool.
Record-Triggered Flow: A record-triggered flow (after-save) can be initiated when a Property record's approval status changes to "Approved" (or a similar field update).
External Service Actions: Within the flow, the administrator can use an External Service action (or an Apex action if more complex integration is needed). External Services allow Salesforce to connect to external APIs declaratively, enabling the flow to send data (like the updated listing price) to the listing service's endpoint.
Versatility: Flows offer the necessary logic and integration capabilities to check the approval status, get the new price, and then send this information to the external system.

B. Platform Event: Platform Events are primarily used for publishing and subscribing to events within Salesforce or between Salesforce and external systems. While an external service could subscribe to a Platform Event published by Salesforce, the flow itself is the mechanism that would publish the event. The Platform Event is the message type, not the automation tool initiating the action based on the approval.

C. Process Builder: Process Builder is a legacy automation tool. While it could trigger on the record update, its capabilities for directly calling external services are limited compared to flows. Salesforce recommends using Flow Builder over Process Builder for new automation.

D. Email Alert: An Email Alert is used to send email notifications. It cannot be used to send a message to a specific external endpoint (an API).