Salesforce-Platform-Administrator-II Practice Test Questions

Explanation:

In Salesforce, when Contacts to Multiple Accounts is enabled, contacts can have one primary (direct) account (populated in the standard AccountId field on the Contact) and multiple related accounts (via the AccountContactRelation junction object). To allow users to distinguish between primary/direct contacts and related contacts on the Account page layout:

Add the Related Contacts related list (from the AccountContactRelation object) to the Account page layout. This list displays all contacts associated with the account, including both direct and related ones.
To differentiate them, include the IsDirect field (a checkbox on AccountContactRelation) in the related list. When checked, it indicates the contact is the primary/direct contact for that account; when unchecked, it's a related contact.

This configuration provides a single, unified view where users can filter or visually distinguish the relationship types without needing separate lists. Salesforce recommends removing the standard Contacts related list (which only shows direct contacts) to avoid duplication and confusion.

Why Other Options Are Incorrect
A. Display both the contacts and the related contacts related lists.
This would create redundant lists: the standard Contacts list shows only direct contacts, while Related Contacts shows all (direct + related). Salesforce explicitly advises against this to prevent confusion and "deliberate duplication." Instead, use one list (Related Contacts) with the IsDirect field for distinction.
B. Display the related accounts related list on the page layout.
The Related Accounts related list is added to the Contact page layout (not Account) to show all accounts a contact is related to. It has no relevance for distinguishing contacts on the Account page.
D. Display the contacts related list and add the related field.
The standard Contacts related list only displays direct/primary contacts and cannot show related contacts (as they lack a direct AccountId match). There is no standard "related field" on this list to distinguish relationship types—related contacts require the AccountContactRelation object and its fields (like IsDirect).

References
Salesforce Help: Set Up Contacts to Multiple Accounts – Details the steps, including: "Add the Related Contacts related list to the account page layouts your reps use" and "Because the Related Contacts related list automatically includes all direct contacts, you can remove the Contacts related list on your account page layouts."
Salesforce Trailhead: Understand Account and Contact Relationships – Explains primary vs. related relationships and the use of fields like IsDirect for distinction.
Salesforce Ben: Salesforce Account Contact Relationship Fields – Recommends using one related list with IsDirect to avoid confusion (aligned with official guidance).

Explanation:

Why B is correct
Use an Accounts report and add two cross filters so the output is just the list of Account records:
Accounts WITH Opportunities → add a subfilter like Close Date = THIS YEAR.
Accounts WITH Activities → add subfilters to capture completed items in the LAST 30 DAYS (e.g., Status = Completed / Activity Date = LAST 30 DAYS, depending on your org’s activity fields).
Cross filters filter the parent object (Account) by conditions on related child records (Opportunities, Activities) and return only the parent rows—no opportunity detail rows are required.

Why the other options are incorrect
A. Joined Report – Overkill here and would typically surface details from multiple blocks. You don’t need separate report blocks; cross filters on a single Accounts report meet the requirement cleanly. (Help docs recommend cross filters specifically to include/exclude parents based on children.)
C. Summary Report – Summarization alone doesn’t let you filter Accounts by related Opportunity and Activity criteria. You still need cross-object filtering, which summary format does not provide by itself. Cross filters are the feature that filters parents by children.
D. Filter Logic – This just combines filters that are already on the report. It can’t by itself reference fields from related child objects (like Opportunity Close Date) when the primary report type is Accounts. You need cross filters for that.

References
Salesforce Help – Filter Across Objects with Cross Filters (what cross filters do; “show just accounts with cases” example).
Salesforce Help – Create a Cross Filter (how to add cross filters and subfilters).
Salesforce Help – Filter Reports by Values (notes using “Accounts with Opportunities” and adding subfilters).
Trailhead – Optimize Report Filtering Techniques (Use Cross Filters) (step-by-step example starting from an Accounts report and adding WITH Opportunities cross filter + subfilters).

Explanation:

In Salesforce, when the Contacts to Multiple Accounts feature is enabled, a contact can have one primary (direct) account (stored in the standard AccountId field on the Contact object) and multiple related (indirect) accounts (via the AccountContactRelation junction object). However, Salesforce requires that every contact must have a primary account at all times, regardless of whether the Account field is marked as required on the page layout. This is a system-level requirement enforced by Salesforce's data model for contacts.

Issue in the Scenario: The sales rep is trying to remove the primary account from a contact, but Salesforce prevents this because the AccountId field (primary account) cannot be set to null. Even if the administrator has updated the page layout to make the Account field not required, the underlying Salesforce platform still mandates a primary account for every contact record.
Why This Happens: The primary account relationship is integral to how Salesforce manages contact-account relationships, permissions, and visibility (e.g., in sharing rules or role-based access). Removing the primary account would break this structure, so Salesforce does not allow it.

To resolve this, the rep could:
Change the primary account to another account (by updating the AccountId field), but not remove it entirely.
Alternatively, delete the contact record if it no longer needs to exist.

Why Other Options Are Incorrect

B. The Contact has indirect relationships to other Accounts.
Indirect relationships (via AccountContactRelation) do not prevent the removal or reassignment of the primary account. The primary account (AccountId) is independent of indirect relationships, and Salesforce allows updating the primary account even if indirect relationships exist. This option is irrelevant to the issue.
C. The Account Contact relationship record needs to be deleted first in order to disassociate Contact from the Account.
The AccountContactRelation object manages indirect relationships, not the primary account relationship. The primary account is stored directly in the AccountId field on the Contact object, not in a junction record. Deleting AccountContactRelation records would only remove indirect relationships, not the primary account, so this option does not apply.
D. Private Contacts need to be enabled in Setup.
Private Contacts (related to the Contact Sharing settings or Organization-Wide Defaults) control visibility and access to contact records, not the ability to associate or disassociate a primary account. Enabling private contacts would not resolve the issue of removing the primary account, as the requirement for a primary account is universal regardless of sharing settings.

References
Salesforce Help: Set Up Contacts to Multiple Accounts – States: “Every contact must have a primary account, which is stored in the standard Account field on the contact record.”
Salesforce Help: Account and Contact Relationships – Explains that the primary account is mandatory and stored in the AccountId field, while indirect relationships are managed via AccountContactRelation.
Trailhead: Understand Account and Contact Relationships – Clarifies that “A contact must always be associated with a primary account,” even when Contacts to Multiple Accounts is enabled.

Explanation:

When creating a flow that processes and updates multiple records (like assigning accounts based on Annual Revenue), performance and scalability are critical.

C. Update record elements should be placed outside the flow loop.
Governor Limits: Salesforce imposes strict Governor Limits on the number of database operations (DML - Data Manipulation Language) a single transaction can execute. This limit is 150 DML operations.
Bulkification: If you place an Update Records element inside a loop, the flow attempts to execute a separate DML statement for each record in the loop. If the flow processes 151 accounts, it will immediately hit the limit and fail.
Best Practice: The solution is to use an Assignment element inside the loop to add the updated record (with the new owner) to a Record Collection Variable. The Update Records element is then placed outside the loop, performing a single, bulk DML operation on the entire collection of updated records. This keeps the transaction safe and efficient.

A. Use a Get Record component instead of hard coding record IDs
Hard Coding Issues: Hard-coding a Salesforce ID (like a User ID or Record Type ID) means putting the literal 15- or 18-character ID directly into the flow's logic.
Deployment Failure: IDs are unique to each environment (Sandbox, Production). When you deploy a flow from a sandbox to production, the hard-coded User ID or Account Record Type ID from the sandbox will not exist in production, causing the flow to fail immediately.
Best Practice: Use a Get Records element to look up the required ID dynamically based on a unique, consistent field. For example, to get a sales rep's ID, Get Records searches the User object where Username = ’salesrep@awcomputing.com’. This ensures the flow works correctly in any environment.

Why Other Options Are Incorrect

B. The running user of a flow is the user that last saved the flow.
This is incorrect. The user who last saved the flow has no bearing on the running user. In a record-triggered or scheduled flow (like this assignment flow), the flow runs in System Context, meaning the running user is the Automated Process User who has full permissions and bypasses field-level security and sharing rules.
D. Update Record elements should be placed inside the flow loop.
This is incorrect and the opposite of best practice. As explained above, placing DML inside a loop causes a flow to quickly hit Governor Limits (Too many DML statements: 151) and fail.

Explanation:

The goal is to reduce the file size of a full data export. A full export includes all of an organization's data.

Why A is Correct:
The most direct way to reduce the export size is to export fewer objects. If the business goal doesn't require a complete snapshot of every single object, excluding non-essential ones will significantly decrease the total data volume and speed up the export process.

Why C is Correct:
Files stored as attachments, documents, and in the Notes & Attachments related list are often the largest contributors to export size. Deselecting the "Include images, documents, and attachments" checkbox excludes this binary file data from the export, resulting in a much smaller and faster export that contains only the structured data (records and fields).

Why E is Correct:
In Salesforce, when a record is deleted, it is moved to the Recycle Bin and is still stored in the database. A full data export includes the contents of the Recycle Bin. Therefore, by regularly emptying the Recycle Bin (thus keeping deleted record counts to a minimum), you permanently remove that data, which will no longer be included in the export, reducing its size.

Why B is Incorrect:
The frequency of backups (e.g., every 5 days) does not affect the size of an individual export file. A more frequent export schedule creates more files over time, but each file's size is determined by the data in the org at that moment. This recommendation does not address the core problem of reducing the size of a single export.

Why D is Incorrect:
There is no "Unselect the recycle bin" checkbox in the Data Export service. The only options are to include or exclude files and to schedule the export. The Recycle Bin data is automatically included in a full export; the only way to exclude it is to empty it before the export (as stated in E).

Reference: Salesforce Help: "Export Data from Your Organization"
The documentation for the Data Export service clearly shows the option to "Include images, documents, and attachments," noting that selecting it will "increase the size of the downloaded file." It also explains that the export includes all data, which inherently includes records in the Recycle Bin until they are permanently deleted.

Explanation:

Salesforce does not offer native daily full data exports via the Data Export Service — it only supports weekly or monthly exports. For organizations like Cloud Kicks that require daily backups, the best solution is to use a third-party ETL (Extract, Transform, Load) tool such as:
MuleSoft
Talend
Informatica
Skyvia
Data Loader (with scripting)
These tools can be scheduled to:
Extract data from Salesforce daily
Transform it if needed
Push it to a secure target destination (e.g., cloud storage, data warehouse)
This approach ensures automation, reliability, and scalability for daily backups.

❌ Why Other Options Are Incorrect:
A. Set up Salesforce's Data Export Service and store the data in the target destination
🔻 Incorrect because: The Data Export Service only supports weekly or monthly exports — not daily. It’s also manual unless scheduled, and lacks flexibility for custom destinations.
B. Extract the data with the Import Wizard and push it to the target destination
🔻 Incorrect because: The Import Wizard is used for importing data into Salesforce, not extracting it. It’s not designed for backups or exports.
C. Schedule a report and have the data emailed to the admin to put in the target destination
🔻 Incorrect because: Reports only include limited data (not full object records or attachments), and manual emailing is not scalable or secure for daily backups.

📚 References:
Salesforce Help: Data Export Service
Salesforce Trailhead: Integrate with External Systems

Explanation:

The administrator needs to import a large amount of historical data (more than 100,000 records) from another system into Salesforce. Given the volume exceeds 100,000 records, the solution must handle large datasets efficiently, support automation, and ensure scalability. Salesforce Data Loader with Bulk API enabled is the most appropriate choice from the options provided. Here’s why:

Data Loader Overview: Salesforce Data Loader is a client application designed for bulk data imports, updates, deletes, and exports. It supports CSV files and can handle large datasets (up to millions of records).
Bulk API Advantage: Enabling the Bulk API in Data Loader optimizes performance for large data volumes by processing records in asynchronous batches (up to 10,000 records per batch). This reduces API call usage, minimizes processing time, and handles high record counts efficiently, making it ideal for importing over 100,000 records.
Why It Fits: Data Loader with Bulk API can process the large dataset in chunks, supports mapping fields from the external system to Salesforce objects, and handles complex operations like inserts or upserts. It’s a native Salesforce tool, free to use, and well-suited for one-time or recurring imports of historical data.

Implementation Steps
Prepare the data in CSV format, ensuring fields match Salesforce object fields.
Install and configure Data Loader, enabling Bulk API in settings (Settings > Use Bulk API).
Map the CSV columns to Salesforce fields using Data Loader’s mapping feature.
Run the import in batches, monitoring for errors in the success/error log files.
Verify the imported data in Salesforce.

Why Other Options Are Incorrect

A. SOAP based API with Developer Console
The SOAP API is designed for real-time, transactional operations and is not optimized for large-scale data imports (e.g., >100,000 records). It processes records synchronously, leading to longer processing times and higher API call consumption, risking governor limits. The Developer Console is primarily for debugging, executing Apex, or running SOQL queries, not for bulk data imports. Using SOAP API via Developer Console is impractical and inefficient for this use case.
Reference: Salesforce Developer: SOAP API Developer Guide – Notes that SOAP API is better for smaller, real-time operations, not bulk imports.

C. An AppExchange package
While some AppExchange packages (e.g., Jitterbit, Informatica) offer robust data integration capabilities, they are third-party tools that often require licensing costs and additional setup. For a one-time import of historical data, Data Loader with Bulk API is a native, free, and sufficient solution. AppExchange tools may be overkill unless ongoing integration or complex transformations are needed, which the question does not specify.
Reference: Salesforce AppExchange: Data Integration Tools – Describes third-party tools but does not prioritize them over native Data Loader for simple bulk imports.

D. Import Wizard with Add Only
The Data Import Wizard is a browser-based tool for importing data into standard objects (e.g., Accounts, Contacts, Leads) or simple custom objects, with a limit of 50,000 records per import. It cannot handle 100,000+ records in a single operation and lacks the scalability and automation of Data Loader. The “Add Only” option refers to inserting new records (not updating), but the record limit makes it unsuitable regardless.
Reference: Salesforce Help: Import Data with the Data Import Wizard – States the 50,000-record limit and its use for smaller imports.

References:
Salesforce Help: Data Loader Guide – Describes Data Loader’s capabilities for bulk imports and the option to enable Bulk API for large datasets.
Salesforce Developer: Bulk API Developer Guide – Explains Bulk API’s efficiency for processing large record volumes in batches.
Salesforce Help: Import Data with the Data Import Wizard – Confirms the 50,000-record limit, making it unsuitable for 100,000+ records.
Trailhead: Data Management – Recommends Data Loader with Bulk API for large-scale imports.
Salesforce Developer: SOAP API vs. Bulk API – Highlights Bulk API’s superiority for large data operations compared to SOAP API.

Additional Note:
For very complex scenarios (e.g., data transformations or ongoing integrations), an AppExchange tool might be considered, but for a straightforward import of historical data, Data Loader with Bulk API is the most efficient, cost-effective, and native solution. Ensure the administrator checks governor limits (e.g., API call limits) and validates data mappings to avoid errors during the import.

Explanation:

In a many-to-many relationship using a junction object, a user's access to a junction record is controlled by their access to both associated master records.

Here's a breakdown of how it works:

Junction Object Inheritance:
The junction object (in this case, the one connecting Docs and Solar Panels) inherits its sharing settings and security from its two master parent records (Doc and Solar Panel).
Dual Master Records:
To view a junction record and subsequently see the related Solar Panel records, the user must have at least Read access to both master objects involved in the relationship.
Access Requirements:
The question specifies that the users already have access to the Doc object and the junction object, but not the Solar Panel object. Therefore, to see the related Solar Panel records, they must be granted Read permission on the Solar Panel object.

Why other options are incorrect
B. Access permission is not required on either master record:
This is incorrect. Access to a junction record is dependent on access to both master records. Without access to both master records, a user cannot view the junction record or its related master records.
C. Create permission is required on both master records:
Create access is not necessary to simply view records. The request is only for users to be able to view the related Solar Panel records, which only requires Read access. Create access would only be necessary if they needed to create new junction records.
D. Read permission is required on at least one master record:
This is incorrect. In a many-to-many relationship, to view a junction record, a user must have at least read access to both master records. The security follows the more restrictive of the two parent objects' sharing settings.

References
Inherited Sharing for Junction Objects (Salesforce Help): Explains that junction objects inherit sharing settings from both master records. To view a junction record, a user must have at least Read access to both master records.
Object Permissions (Salesforce Security Guide): Provides details on how permissions like "Read" and "Create" work and how object-level access is determined.
Trailhead: Data Modeling: The Trailhead module on data modeling covers master-detail relationships and many-to-many relationships, explaining how security is handled in these scenarios.

Explanation:

Why this is correct:
Salesforce Data Mask (a Salesforce-managed tool) obfuscates or removes sensitive fields in Full (and Partial) sandboxes so testers can work with realistic data without seeing real confidential values. Masking is done in the sandbox and is irreversible—ideal for protecting distributor account details while preserving data shape for testing.

Why the others are wrong:

A. Refresh the sandbox — A refresh simply copies production data again; it doesn’t protect it. You’d still expose sensitive info unless you mask it. Salesforce
B. Assign the users a new permission set — Permissions help, but testers often need broad access to test. Permission changes alone don’t anonymize existing sensitive data in the sandbox. Data masking is the standard control here.
D. Delete the sensitive information — Deleting breaks test realism, relationships, and could impact test coverage. Data Mask lets you replace sensitive values while keeping schema and relationships intact.

References:
Salesforce Help: Secure Your Sandbox Data with Salesforce Data Mask (overview and irreversible masking).
Salesforce Help: Run a Data Mask Job (masking runs in sandboxes).
Trailhead Module: Salesforce Data Mask (purpose and capabilities).

Explanation:
You want Accounts that don’t yet have the new monitor recorded as an Asset. In a report based on Accounts, add a Cross Filter: Accounts WITHOUT Assets, then add a subfilter on Asset (e.g., Product Name = “Solar Panel Monitor vX”) to target the specific product. Cross filters are designed to include/exclude parent records based on child records—exactly this use case.

Why the others are wrong

A. PREVGROUPVAL() compares values between grouped rows (e.g., this month vs last month). It doesn’t find parents lacking related child records.
B. Role Hierarchy filter controls visibility by org hierarchy, not whether Accounts are missing certain Assets.
C. Bucket Columns categorize field values within the same record; they don’t evaluate relationships like “Accounts without Assets.”

How to build it (quick steps)
New Accounts (or “Accounts with Assets”) report → Filters
Add Cross Filter → Accounts WITHOUT Assets
Click Add Asset Filter → set criteria for the specific monitor model (e.g., Product Name equals the new monitor).

References:
Example: Use WITHOUT in Cross Filters (child-object exclusion).
Cross Filters: WITH and WITHOUT (multiple examples and subfilters).
Filter Report Data (overview of filters & cross filters).