Salesforce-Platform-Administrator-II Practice Test Questions

Explanation:

Before installing a managed package from AppExchange, administrators must evaluate several factors to ensure compatibility, resource impact, and operational feasibility.
Option A is key because managed packages often introduce custom objects and fields that consume your org's allocation limits (e.g., up to 2,000 custom objects per org), potentially leading to exceeded limits if not planned for.
Option C addresses edition-specific requirements, as many apps are designed for higher editions like Enterprise or Unlimited and may require enabling features such as API access or workflows.
Option D highlights integration needs, where apps relying on third-party services (e.g., APIs or webhooks) could introduce dependencies on external availability, security, and compliance considerations.

Why Other Options Are Incorrect:

B. Managed apps do not undergo a formal security review by Salesforce:
This is false; all managed packages listed on AppExchange must pass a rigorous security review by Salesforce's Product Security team to validate against threats like those in the OWASP Top 10, ensuring baseline protection before publication.
E. Apps must be installed in production before the app can be installed in a sandbox:
This is incorrect; managed packages can (and should) be installed directly in a sandbox for testing without any production prerequisite, allowing admins to validate functionality in a safe environment first.

References:
Salesforce Help: AppExchange Application Installation Best Practices – Outlines key pre-installation checks, including edition compatibility (C), custom object/tab limits (A), and external service dependencies (D).
Salesforce Help: Before You Install an AppExchange Package – Recommends reviewing limits, requirements, and testing options like Test Drive before installation.
Trailhead: Security Review Preparation & Tools – Details the mandatory security review process for managed packages, confirming they undergo formal vetting (refuting B).
Salesforce Help: Installing Consumer Goods Cloud Managed Packages – Advises installing in sandbox before production to test thoroughly (refuting E).

Explanation:

Unpredictable Execution Order:
For both before-save and after-save flows, if multiple record-triggered flows exist for the same object and are set to run under the same trigger conditions (e.g., all set to run before a record is saved), Salesforce does not guarantee the order of their execution.
Solution for controlling order:
While Salesforce does not guarantee a default execution order, it provides tools for administrators to define it. The Flow Trigger Explorer and the "Trigger Order" number field can be used to set a specific run order for multiple flows on the same object. However, if no explicit order is set, the execution is not guaranteed.

Why the other options are incorrect:

A. Assign the highest priority to the record-triggered flow which should execute first:
This is a method for controlling the execution order, but it's not a natural consideration. You must intentionally set a priority using the "Trigger Order" field within Flow Trigger Explorer. It is not an automatic process that happens by default. The premise of the question is about what the administrator must consider if they have not explicitly managed the order, and the answer is that the order is not guaranteed.
B. The flow with the longest execution time will execute first:
This statement is incorrect. The execution time of a flow is not a factor in determining its execution order. Salesforce's internal processes manage the execution queue, and run time has no bearing on which flow is executed first.
C. The flow with the shortest execution time will execute first:
This is also incorrect. Similar to option B, execution time is not a factor in determining which flow is executed first. There is no mechanism in Salesforce's execution engine that prioritizes flows based on performance metrics.

References:
Salesforce Help - Guidelines for Defining the Run Order of Record-Triggered Flows: Explains how the Flow Trigger Explorer can be used to manage the execution order of flows and notes that if the order isn't explicitly defined, it is not guaranteed.
Salesforce Developer Documentation - Triggers and Order of Execution: Explains the overall order of execution within Salesforce and confirms that if multiple Apex triggers are defined for the same object and event, their firing order is not guaranteed. This general principle also applies to record-triggered flows.

Explanation:

Schema Builder vs. Object Manager
Schema Builder is an excellent visual tool for quickly creating and viewing the data model (objects, fields, and relationships). However, its configuration options are limited primarily to creation and basic field properties. For deeper configuration that impacts business process, security, and auditing, the Object Manager must be used.

Why Option C is Correct
Enable Field History Tracking:
To enable history tracking for an object, you must go to the Object Manager settings for that object, select "Details," and check the box for "Track Field History" under Optional Features. After this, you go to the "Fields & Relationships" section and click the "Set History Tracking" button to select the individual fields. This level of granular setup is not available in the Schema Builder interface.

Why Other Options Are Incorrect

A. Add custom fields to the page layout.
Incorrect. Neither Schema Builder nor the standard Field/Object Wizards automatically place new fields on the page layout. After creation (in either tool), you must navigate to the Page Layout Editor (found within Object Manager) to drag the field onto the layout. This is a follow-up step for both tools, not a limitation unique to Object Manager.

B. Make available for Customer Portal.
Incorrect. This is generally handled during the initial creation of the custom object or field, or later by configuring Sharing Settings and Profile/Permission Set access. Schema Builder allows you to specify whether the object is deployed and available, which influences its initial visibility.

D. Allow Reports and Activities
Incorrect. These options are checkboxes found in the Optional Features section when creating or editing a custom object. Schema Builder's Object Settings dialog box includes these crucial checkboxes (Allow Reports, Allow Activities, Deployment Status), meaning you can configure them directly from the Schema Builder interface.

Explanation:

The requirement is a classic use case for the Role Hierarchy in a private sharing model. The business needs are:
Private Sharing Model: By default, users can only see records they own.
Manager Access: A sales rep's manager should be able to see the rep's sensitive records.
Peer Isolation: The rep's colleagues (who are at the same role level in the hierarchy) should not be able to see the records.

Why D is Correct:
The "Grant Access Using Hierarchies" option in the Organization-Wide Defaults (OWD) sharing settings is designed specifically for this. When enabled for an object, it automatically grants a user's manager (and their manager, all the way up the role hierarchy) access to view and edit the user's records. This happens automatically without any manual configuration for each manager. It perfectly enforces the rule: "Managers see their subordinates' data, but peers do not see each other's data."

Why the Other Options are Incorrect:

Why A is Incorrect:
Validation rules are used to prevent the saving of a record if certain data criteria are not met. They are a data integrity tool, not a data visibility tool. A validation rule cannot be used to hide records from a user's view; it can only stop them from saving a record that violates the rule.
Why B is Incorrect:
Granting "View All" data permission in a profile is an extremely powerful and broad setting. It would allow managers to see every record of that object in the org, regardless of who owns it. This violates the principle of confidentiality by giving managers far more access than they need (they should only see their team's data, not every team's data). This is a major security risk for sensitive credit information.
Why C is Incorrect:
While technically possible, creating a separate sharing rule for each manager is an administrative nightmare and not a scalable or recommended practice. It would require creating and maintaining a new rule every time a manager is hired, promoted, or has their team changed. The Role Hierarchy is the native, automated, and scalable way to handle this requirement.

References:

Salesforce Help: Grant Access Using Hierarchies
Relevance: This is the definitive documentation for the feature that solves this problem.
Key Quote: "The Grant Access Using Hierarchies option extends sharing access to a user's managers in the role hierarchy... If your organization-wide sharing default for an object is Private, the Grant Access Using Hierarchies option allows a user's manager to have the same level of access to the user's records."

Salesforce Help: Organization-Wide Sharing Defaults
Relevance: Explains the foundation of the sharing model, where the "Grant Access Using Hierarchies" setting is located.
Key Quote: "Use organization-wide sharing defaults to lock down your data to the most restrictive level, and then use the other sharing tools to open up the data to users who need it."

Trailhead Module: Control Access to the Recruiting App Using Hierarchies
Relevance: This module provides a practical example of using the role hierarchy to control record access, reinforcing the concept tested in the question.

Explanation:

This question tests whether you can separate Salesforce’s record access model (who can read/edit a record) from record type configuration (how the record looks and which picklist values/processes are available). Changing a record’s Record Type does not, by itself, change who can see or edit the record. It mainly changes the page layout and picklist availability that users experience when they interact with the record in the UI. Because the underlying sharing model and object-level permissions remain unchanged, the user’s record access remains the same after the flow runs.

Let’s unpack the scenario and the implications step by step.

1) What governs “record access” in Salesforce?
Record access—i.e., whether a user can read or edit a given record—is controlled by a combination of:
Object permissions on the user’s profile and permission sets (Read, Create, Edit, Delete).
Org-Wide Defaults (OWD) for the object, which set the baseline level of access across the org.
Ownership (the record owner typically has full access, subject to object permissions).
Role hierarchy (if “Grant Access Using Hierarchies” is enabled for the object, managers get access up the chain).
Sharing mechanisms, including criteria-based or owner-based sharing rules, manual sharing, team sharing (e.g., Account Teams), and territory sharing (if enabled).
Administrative overrides like View All or Edit All on the object, and Modify All Data (system-level).
None of the above items depends on the record’s Record Type value. If a user could read or edit a record before the Record Type change, they can still read or edit it after the change—unless some other element of the security model changes (ownership reassignment, a sharing rule update, removal from a team, etc.). In your scenario, none of those changes are described.

2) What does a Record Type control?
Record Types influence the UI configuration and data capture constraints, not who can see or edit a record. Specifically, Record Types control:
Page layout assignment (which fields are shown and in what sections; whether certain fields are read-only/required on the layout).
Picklist value availability for fields (different record types can expose different sets of picklist values).
Business processes (e.g., different sales stages on Opportunities, different support processes on Cases).
They also intersect with profile and permission set configuration in one important way: a profile (or perm set) must have access to a given record type in order for the user to create records of that type and, in many cases, to change the record to that type in the UI. But this is not the same as record access via sharing. It affects whether the user is allowed to select or work with that record type, not whether the user can see or edit the record at all.

3) The nuance that often confuses people
In your scenario, the Sales profile has the External Customers record type assigned. The screen flow changes a record’s Record Type on the user’s behalf (i.e., programmatically). Suppose the flow changes an Account from External Customers to Internal Customers—a type that the Sales profile doesn’t have assigned. What then?
The user’s ability to see the record is unchanged. Your OWD is Public Read Only, so everyone can read Account records regardless of type. The flow didn’t change OWD, ownership, or sharing, so read access is still there.
The user’s ability to edit the record in practice can be affected by record type availability—not by sharing. If the Sales profile isn’t allowed to use the Internal Customers record type, the UI may prevent the user from editing that record unless the record type is switched back or the profile/permission set is updated to include that record type. This may feel like “losing edit access,” but technically they didn’t lose access under the sharing model; they ran into a record-type availability restriction enforced by the UI. The underlying access (as in the right to edit a record they own or are shared to) is the same; the UI won’t proceed because the user doesn’t have permission to work with that record type.

This is precisely why option B (“Edit access will be lost to the record”) is misleading. It conflates record access with record-type availability. If the user had edit rights through sharing/ownership/object permissions prior to the change, they still have those rights. It’s just that the record type assignment on the profile may block editing actions in the UI until the admin grants access to that record type or switches the record back.

4) Why the other options are incorrect

A. Read access will be lost to the record.
Incorrect. With Public Read Only, the baseline read access is org-wide. Changing Record Type does not alter OWD or sharing rules. Therefore, read access persists.
B. Edit access will be lost to the record.
Incorrect for the reasons above. The user’s sharing-based edit rights don’t change just because the Record Type changes. Any edit friction is due to record-type availability, not a change in access.
D. A new record owner will be assigned.
Incorrect. Changing Record Type doesn’t change ownership. Ownership would only change if the flow explicitly reassigns the record or some other process updates the Owner field.

5) Practical admin guidance
If Sales users need to edit records regardless of whether they are Internal or External Customers after the flow runs, ensure that the Sales profile (or a permission set) includes both record types. That way, the UI won’t block the edit because of record-type availability.
If the purpose of the flow is to correct bad data entry, consider adding entry criteria to the flow so it only switches to a record type that the user’s profile can interact with—or add a subflow that checks the user’s record-type access and warns them (or routes the change to an admin) if they lack access.
Keep the OWD and sharing model stable unless there’s a business reason to change who should see or edit these records. Record Type is not the lever for confidentiality; sharing is.

Bottom line:
Changing the Record Type via the flow does not change the underlying sharing or permissions. The user’s record access remains the same—which makes C the correct answer.

Explanation:
In a large, division-based organization like Cloud Kicks, where high turnover in certain divisions necessitates localized user management, Salesforce's Delegated Administrator feature is the ideal solution. This allows division leaders (or designated admins) to perform user administration tasks—such as creating, editing, resetting passwords, assigning profiles, and managing licenses—exclusively for users within their division.
To implement, the administrator navigates to Setup > Delegated Administration > Delegated Administrators, creates a new Delegated Group, and assigns it to the division leaders' profiles or users. Within the group setup, under "User Administration," the admin specifies the exact roles (e.g., "Division A Sales") and all subordinate roles that the delegated admins can manage. This scopes their access to only users in those roles, preventing them from affecting users in other divisions.
Additional options include whitelisting specific permission sets for assignment and enabling "Log in as" for troubleshooting, all while maintaining full admin oversight via audit trails. This declarative approach scales efficiently for multiple divisions, reduces central admin workload, and ensures compliance by limiting overreach.

Why Other Options Are Incorrect:

B. Assign a flat territory role hierarchy for the divisions: Role hierarchies (including territory-based ones) primarily govern record-level data visibility and sharing (e.g., allowing managers to see subordinates' records). They do not grant or restrict user management permissions like creating or editing users; that's handled by profiles, permission sets, or delegated admins. A flat hierarchy might simplify data access but wouldn't address the turnover-driven need for division-specific user control.
C. Create a permission set group for the division leaders: Permission set groups bundle multiple permission sets to grant composite access (e.g., Manage Users + View Setup), which could empower leaders with user admin rights. However, this applies org-wide without inherent scoping to divisions—leaders could manage any user unless combined with other restrictions like roles, making it insufficient alone for the requirement.
D. Customize and assign profiles for the division teams: Profiles provide baseline object/field permissions, and customizing one per division (e.g., "Division A Sales Profile" with Manage Users) would allow team-level management but requires ongoing maintenance for turnover (e.g., profile cloning/updates). It's not scoped to only intra-division users and violates best practices by proliferating custom profiles, which can hit org limits (up to 2,000 total).

References:
Salesforce Help: Define Delegate Administrators – Details enabling delegated admins to manage users in specified roles and subordinates, ideal for division-based scoping.
Salesforce Help: Set Up a Delegated Administrator – Step-by-step guide to creating delegated groups, specifying roles, and assigning to leaders for targeted user management.
Salesforce Ben: How to Set Up a Delegate Administrator in Salesforce – Practical overview confirming role-based restrictions for user tasks in multi-division orgs.

Explanation:

Salesforce provides a powerful way to customize standard objects like Opportunity to meet the needs of different business units through:

Record Types: Allow you to define different business processes and picklist values.
Page Layouts: Control which fields and sections are visible to users based on the record type.
Sales Processes: Define the sequence of stages in the Opportunity lifecycle tailored to each team.

In this scenario, DreamHouse Realty has two distinct teams—Rental and Real Estate—each with different sales processes and client data requirements. By using separate record types, the administrator can:

Assign a Rental Opportunity record type to the Rental team and a Real Estate Opportunity record type to the Real Estate team.
Customize page layouts so each team sees only the fields relevant to their workflow.
Define sales processes that reflect the unique stages for rentals vs. real estate transactions.

This approach is scalable, maintainable, and aligns with Salesforce best practices.

📘 References:
Record Types Overview
Customize Page Layouts
Sales Processes in Salesforce

❌ Why the Other Options Are Incorrect

A. Leverage Opportunities for the Real Estate Team and create a new custom object for the Rental Team Opportunities
This is not recommended because it introduces unnecessary complexity. Both teams are working with sales-related data, so it’s better to use the standard Opportunity object and customize it with record types. Creating a new custom object would fragment reporting, automation, and scalability.

C. Create Opportunity Teams for the Rental and Real Estate Teams and make appropriate fields visible to only the necessary team
Opportunity Teams are used to assign multiple users to a single Opportunity for collaboration. They do not control field visibility or sales processes. Field visibility is managed through page layouts and profiles, not Opportunity Teams.

D. Add a section for Rental and a section for Real Estate on the Opportunity Master Record Type to keep the information separate
This approach would clutter the layout and expose irrelevant fields to both teams. It’s inefficient and confusing. Record types and page layouts are designed specifically to avoid this kind of overlap.

Explanation:

Why this is correct
In Salesforce, merging records (Accounts, Contacts, or Leads) requires the user to have Delete permission on that object. Even if the user is the owner of both Accounts and has Read/Write access, the merge action won’t proceed without Delete on Account. That’s because the merge process effectively deletes the losing record(s) and consolidates data into the master record—hence the need for Delete.

Why the others are wrong?

A. Only administrators have permission to merge records.
Not true. Non-admin users can merge records as long as they have the right object permissions (including Delete) and appropriate access to the records being merged.

B. The user is assigned to the wrong territory.
Territory assignment affects record access/visibility, not the ability to merge once the user already owns and can edit the records. Territory is irrelevant here.

C. The Account matching rules are not set.
Matching/duplicate rules help identify potential duplicates and control whether to allow/block saving duplicates. They are not required to perform a manual merge of two records the user already selected; lacking a matching rule doesn’t cause a merge error.

Key takeaway
To merge Accounts, the user must:
Have Read and Edit on Account (met),
Be able to access both records (met; user is owner), and
Have Delete on Account (missing → causes the error).
Grant the user Delete permission on Accounts (via profile or permission set), and the merge will work.

Explanation:

This question tests the understanding of a nuanced but critical aspect of Salesforce sharing: the interaction between the Organization-Wide Defaults (OWD) and record ownership. The key to solving this is to analyze the sharing rules layer by layer.

Let's break down the configuration:

Organization-Wide Default (OWD) for Contacts: "Controlled by Parent"
This is the most restrictive setting for Contacts. It means that a user's access to a Contact record is entirely determined by their access to the parent Account to which the Contact is related.
Since the Contact is new and the sales manager is missing information, it's highly likely this Contact is not related to an Account yet. A Contact without a parent Account is treated as a "private" record, accessible only by the owner, administrators, and users above the owner in the role hierarchy (if hierarchy is enabled for Contacts).

Organization-Wide Default (OWD) for Accounts: "Public Read Only"
This setting is largely irrelevant for this specific scenario because the Contact's access is "Controlled by Parent." The parent Account's OWD would only come into play if the Contact were attached to an Account.

Record Ownership
The sales manager created the record, so they are the owner. The owner of a record always has at least Read/Edit access to that record, unless a restriction like a Validation Rule prevents it.

Applying the Logic to the Scenario
Since the new Contact record has no parent Account, the "Controlled by Parent" rule cannot grant access to anyone based on Account access. Therefore, the record falls back to standard ownership-based access.
The Sales Manager (The Owner): As the record owner, they automatically have Full Access (Read/Edit/Delete/Share) to the record. They can edit it.
The System Administrator: A user with the "Modify All Data" or "Modify All" on the Contact object (standard for System Administrator profiles) can read and edit all records in the org, regardless of OWD, ownership, or sharing rules. They can edit it.
Users above the sales manager in the role hierarchy: The OWD for Contacts must have "Grant Access Using Hierarchies" enabled for users above the owner to gain access. The question does not state this is enabled. We must assume the default, which is that hierarchy is enabled for standard objects like Contacts. Let's verify this.

Official Clarification on Role Hierarchy for Contacts:
According to Salesforce documentation, "Grant Access Using Hierarchies" is enabled by default for standard objects and cannot be disabled for them. It is only for custom objects that you can disable it.
Therefore, because the role hierarchy is enabled for Contacts, the sales manager's manager (and anyone above them) would also have the same level of access as the sales manager. This means users above the sales manager in the role hierarchy would also be able to edit the record.
This presents a conflict, as both option B and option E seem plausible. However, the question asks for the most precise and definitive answer based on standard exam knowledge.

Why E is the Best and Most Defensible Answer:
While users above in the hierarchy would have access, the question's available answers force a choice. Option B ("Users above the sales manager...") excludes the owner and system administrator, which is incorrect because they definitely have access. Option E ("Sales manager and system administrator") is always true, regardless of the role hierarchy setting.
The owner always has access.
The system administrator always has access.
The exam often prioritizes the most certain, permission-based truth over the hierarchy-based one, especially when the hierarchy's status isn't explicitly modified in the scenario. Therefore, the safest and most correct choice is the one that is guaranteed without any assumptions: the owner and the system administrator.

Why the Other Options are Incorrect
A. Who will be able to edit this new contact record? This is not a valid answer choice; it's a repetition of the question stem.
B. Users above the sales manager in the role hierarchy: This is likely technically correct due to the default hierarchy setting for Contacts, but it is incomplete because it excludes the owner and the system administrator, who unequivocally have access.
C. All users in the organization: This is incorrect. The OWD for Contacts is "Controlled by Parent," which is the most restrictive setting. Without a parent Account, access is limited. "Public Read Only" on Accounts does not grant universal access to Contacts.
D. The owner and users below the owner in the role hierarchy: This is incorrect. The role hierarchy grants access downwards, not upwards. Users below the owner in the hierarchy do not automatically get access to the owner's records.

References
Salesforce Help: Organization-Wide Sharing Defaults
Relevance: Explains the "Controlled by Parent" setting.
Key Quote: "Controlled by Parent: Access to a contact or case is based on the sharing settings of its related account. If you don't want to maintain sharing for contacts or cases separately from accounts, choose this setting. Users can't manually share contacts or cases."

Salesforce Help: Grant Access Using Hierarchies
Relevance: Confirms that hierarchy is enabled by default for standard objects.
Key Quote: "The Grant Access Using Hierarchies option is selected by default for all standard objects... For standard objects, you can't disable the Grant Access Using Hierarchies option."

Salesforce Help: Record Ownership
Relevance: Establishes that the record owner always has access.
Key Concept: A record owner inherently has Full Access to their own records, which includes the ability to edit them. This is a foundational principle of the sharing model.

Explanation:

Execution Order is Not Guaranteed: When two or more after-save record-triggered flows are configured on the same object, Salesforce does not guarantee the order of their execution unless a trigger order is explicitly set.
Race Condition: In this scenario, a "race condition" is occurring. The first flow creates the child record. However, since the order is not guaranteed, the second flow, which is supposed to check for the child record and update it, might execute before the child record is fully created and committed to the database. When the second flow runs, it doesn't find the child record because it doesn't exist yet, so the update fails.
Single, Combined Flow: The most robust solution is to consolidate the two flows into a single after-save record-triggered flow. This eliminates the race condition and ensures the actions occur in the correct sequence. The combined flow would:
Have a decision element to check the initial criteria.
If the criteria are met, create the child record.
Immediately after creating the child record, perform the update on that new record.
Efficiency: Combining flows also aligns with the "one flow per object" best practice, which improves performance and makes future maintenance easier.

Why the other options are incorrect:

A. Make a new record-triggered flow on the child object to update the field on the parent record:
This reverses the logic and adds complexity. While a flow on the child object could update the parent, it doesn't solve the core issue of the parent object's original flows and the race condition. The child record is created, but a subsequent flow on the parent object is not the correct way to handle a race condition originating from two separate flows on the same parent object.

B. Have the record-triggered flows fire on create or edit to update the field:
The scenario implies the flows are already triggered on a create or update event. The problem is not with the trigger event itself, but with the timing and sequence of execution when multiple after-save flows are present on the same object. This action will not resolve the underlying race condition.

D. Combine the flows into scheduled flows and have them update the field:
A scheduled flow runs at a specified time and is used for batch jobs or time-based actions. Using scheduled flows would introduce a delay, meaning the field would not be updated immediately. The original requirement is to update the field in response to a record-triggered event, so this is an inefficient and incorrect solution.