Organization-Wide Defaults (OWD) are the foundation of the Salesforce record-level security model. They define the baseline level of access that users have to records they do not own, for each object. OWD settings are the most restrictive layer of sharing; every other sharing mechanism (role hierarchy, sharing rules, manual sharing, teams, Apex managed sharing) can only open up access beyond what OWD grants, never restrict it further. Common OWD values include Private (only the owner and users above them in the role hierarchy can see or edit), Public Read Only (everyone can view, only owners and those above can edit), Public Read/Write (everyone can view and edit), Public Read/Write/Transfer (available for Leads and Cases), and Controlled by Parent (child records inherit the parent's access, as with Contacts controlled by Accounts). Administrators should set OWD to the most restrictive level that still meets business needs, then use sharing tools to grant wider access selectively. The 'Grant Access Using Hierarchies' checkbox determines whether role hierarchy opens records upward; it can be disabled only for custom objects.

The External Sharing Model extends this concept by allowing separate OWD settings for internal users and external users (Experience Cloud/community users, portal users, guest users). When enabled in Sharing Settings, each object displays two columns: Default Internal Access and Default External Access. The external default must be equal to or more restrictive than the internal default. For example, Accounts might be Public Read Only internally but Private externally, so partners see only accounts shared to them. This model is critical for Administrator II candidates because it demonstrates the principle of least privilege for external audiences without compromising internal collaboration. Changes to OWD trigger sharing recalculation, which can take time in large orgs, and admins should preview the impact before deployment.

In Salesforce, the Role Hierarchy is a core component of the sharing model that controls record-level access. It is not an org chart, but a structure that determines how record visibility rolls up vertically. Users in a higher role automatically inherit view and edit access to records owned by, or shared with, users below them in the hierarchy, regardless of the organization-wide default (OWD) settings. For example, a Regional Sales Manager above Sales Reps can see and edit all Opportunities owned by those reps, even if the Opportunity OWD is Private. Access flows upward only; peers in the same role or branch do not see each other's records unless other sharing mechanisms apply.

The 'Grant Access Using Hierarchies' setting is found in Sharing Settings under Organization-Wide Defaults. For standard objects, this setting is always enabled and cannot be disabled; standard objects always respect the role hierarchy. For custom objects, administrators can uncheck this option. When disabled, users in higher roles no longer automatically gain access to records owned by subordinates for that custom object. This is useful for sensitive data, such as HR or compensation records, where managers should not see information simply because of their position in the hierarchy.

Key points for the Platform Administrator II exam: Role hierarchy only matters when OWD is more restrictive than Public Read/Write; it grants access to records, not object or field permissions (those come from profiles and permission sets); and disabling 'Grant Access Using Hierarchies' only affects the automatic rollup of access, not access granted via ownership, sharing rules, manual sharing, or Apex sharing. Also note that if a custom object is on the detail side of a master-detail relationship, it inherits sharing from the master and the setting is unavailable. Users without a role assigned sit outside the hierarchy, and system administrators or users with 'View All' or 'Modify All' bypass the hierarchy entirely.

In Salesforce, 'Controlled by Parent' is an organization-wide default (OWD) sharing setting that governs access to detail records in a master-detail relationship. When an object is the detail (child) side of a master-detail relationship, its sharing settings cannot be set independently; instead, access is automatically inherited from the master (parent) record. This means that a user's ability to view, edit, or delete a detail record is determined entirely by their access to the associated parent record. For example, if a custom object 'Invoice Line Item' is the detail of 'Invoice', a user who has read-only access to a specific Invoice will also have read-only access to all its Invoice Line Items. Likewise, if the user can edit the Invoice, they can edit its line items. Detail records in master-detail relationships do not have their own Owner field, so ownership-based sharing rules, manual sharing, and role hierarchy evaluations are applied at the parent level and cascade down. This simplifies security administration because administrators only need to manage sharing on the parent object, ensuring consistency and reducing the risk of misaligned permissions. Note that 'Controlled by Parent' can also be applied to certain standard objects such as Contacts, Orders, and Assets, where the OWD can optionally be set to inherit from the Account. In those cases, choosing 'Controlled by Parent' removes the ability to set an independent OWD or create sharing rules for that child object. For Platform Administrator II candidates, it is important to understand that while object-level permissions (CRUD) on the detail object's profile or permission set still apply, record-level visibility is dictated by the parent. If a user lacks access to the parent, they cannot access the child record even if their profile grants Read on the child object. This behavior is a key consideration when designing data models and sharing architectures that must balance security with usability.

In Salesforce, sharing rules extend record access beyond what the organization-wide defaults (OWD) allow. They are used when OWD for an object is set to Private or Public Read Only and you need to open up access to specific groups of users. Sharing rules can only grant access, never restrict it, and they apply to records owned by users (and, where configured, records owned by high-volume users for specific objects). There are two main types that every Platform Administrator II candidate should understand.

Owner-Based Sharing Rules share records based on who owns them. You define a source group (such as a public group, role, role and subordinates, or territory) whose records should be shared, and a target group that receives access. For example, you could share all Opportunities owned by users in the 'West Sales' role with members of the 'Sales Operations' public group, granting them Read Only or Read/Write access. These rules are ideal when access requirements align with the organizational hierarchy or ownership structure.

Criteria-Based Sharing Rules share records based on field values rather than ownership. You define criteria using fields on the record (for example, Industry equals 'Healthcare' or Region equals 'EMEA'), and any record matching those criteria is shared with the specified target group. These rules are useful when ownership does not reliably indicate who should see a record. Note that criteria-based rules can evaluate text, number, date, picklist, checkbox, and lookup fields but not formula fields in all cases, and some objects have limits on the number of criteria-based rules allowed.

Key exam points: sharing rules work alongside role hierarchy, manual sharing, and team sharing; they are automatically recalculated when criteria or ownership changes; you can define up to 300 sharing rules per object (with a maximum of 50 criteria-based); and recalculation can be deferred during large data loads to improve performance. Understanding when to use each type helps design a scalable, secure sharing model.

In Salesforce Security and Access, Account Teams, Opportunity Teams, and Manual Sharing are record-level sharing mechanisms that extend access beyond what the organization-wide defaults (OWD), role hierarchy, and sharing rules provide. They are user-driven, exception-based ways to grant access to specific records.

Account Teams allow a group of users to collaborate on an account. The team must be enabled by an administrator (Setup > Account Teams), and once enabled, the Account Team related list appears on the account page layout. Each team member is assigned a team role (e.g., Account Manager, Sales Rep) and specific access levels to the account, its related opportunities, cases, and contacts (Read Only or Read/Write). Users can define a default account team in their personal settings and automatically add it to accounts they own. Access granted through the account team is never less than the OWD; it can only widen access.

Opportunity Teams work similarly but are specific to opportunities. Enabled under Setup > Opportunity Team Settings, they let the opportunity owner add team members with roles and read-only or read/write access to the opportunity. Opportunity Teams integrate with Opportunity Splits, allowing revenue or overlay credit to be allocated among team members. Users can also define a default opportunity team.

Manual Sharing lets a record owner, a user above the owner in the role hierarchy, or a user with Modify All or Full Access share an individual record with another user, public group, role, or role and subordinates. It is available via the Sharing button (which appears only when the OWD for the object is Private or Public Read Only). Manual shares are stored in share tables (e.g., AccountShare) and are removed if record ownership changes.

Key exam points: all three only grant additional access, never restrict it; they require appropriate OWD settings to be meaningful; and they are maintained by users rather than automated rules, making them flexible but harder to audit at scale.

Restriction Rules and Scoping Rules are two record-access features in Salesforce that complement the standard sharing model (org-wide defaults, role hierarchy, sharing rules, manual sharing). Both are covered in the Platform Administrator II exam under Security and Access.

Restriction Rules let admins limit the records a specified group of users can see, even when the sharing model would otherwise grant them access. They act as a filter on top of existing access: a user sees only records that match the rule's record criteria (for example, Contracts where Region__c equals the user's Region__c). They are especially useful for custom objects, external objects, contracts, events, tasks, timesheets, and timesheet entries. Key traits: a user must be assigned by a user criteria (such as a profile, permission set, or user field), only one active restriction rule can apply to a user per object, record visibility is enforced in list views, reports, search, lookups, and APIs, and they cannot grant access—only restrict it. Up to two active rules per object are allowed (more with extra licensing in some editions). They are ideal when org-wide defaults are Public Read Only but a subset of users should see only their own slice of data.

Scoping Rules, by contrast, do not change security. They define a default scope of records a user sees, helping users focus on relevant records in list views, related lists, lookups, and search results. Users can still access out-of-scope records if the sharing model allows (for instance, by navigating to a direct URL or report). Scoping rules apply to standard and custom objects such as Account, Case, Contact, Event, Lead, Opportunity, and Task, and are configured with user criteria and record criteria, similar to restriction rules.

In summary: Restriction Rules enforce security by hiding records; Scoping Rules improve usability by filtering what users see by default without removing access. Both are configured via Object Manager, require Enterprise Edition or higher, and are evaluated after standard sharing calculations.

In Salesforce, reports and dashboards are stored in folders, and folder access controls who can view, edit, or manage them. Understanding this is essential for Platform Administrator II candidates because folder security determines how analytics are shared across an organization while protecting sensitive data.

Salesforce uses Enhanced Folder Sharing (the default in orgs created after Summer '13 and available for older orgs). Under this model, each folder can be shared with users, roles, roles and subordinates, public groups, or territories. There are three access levels: Viewer (can see and run reports/dashboards and view the folder), Editor (Viewer rights plus the ability to add, edit, move, and delete reports/dashboards within the folder), and Manager (Editor rights plus the ability to share the folder, rename it, delete it, and change access for others). Folder creators automatically receive Manager access.

Folders may also be organized hierarchically using subfolders. Subfolders inherit sharing from their parent folder, so permissions cascade downward; admins should plan the hierarchy carefully to avoid unintended exposure.

Several permissions govern folder behavior. 'Create Report Folders' and 'Create Dashboard Folders' allow users to make new folders. 'Manage Reports in Public Folders' and 'Manage Dashboards in Public Folders' grant broad control over public folders. 'View Reports in Public Folders' and 'View Dashboards in Public Folders' allow read access. Administrators with 'Modify All Data' can access all folders regardless of sharing.

Special folders include the Private Reports and Private Dashboards folders, visible only to the owner, and the Public Reports and Public Dashboards folders, accessible to all internal users.

Importantly, folder access controls visibility of the report or dashboard itself, not the underlying records. Report results still respect the running user's object permissions, field-level security, and sharing rules. For dashboards, data displayed depends on the running user configured (fixed or dynamic), so admins must align folder sharing with running user settings to prevent data leakage.

In Salesforce, email templates are organized into folders, and folder-level access controls determine who can view, use, and manage the templates inside them. This is a key Security and Access concept for Platform Administrator II because template visibility directly affects user productivity and data governance.

Classic Email Template Folders: Access is set per folder with three options: 'This folder is accessible by all users' (everyone can use the templates), 'This folder is hidden from all users' (only admins or users with 'Manage Public Templates' can access), and 'This folder is accessible only by the following users' where you share with specific public groups, roles, roles and subordinates, or territories. Users with the 'Manage Public Templates' permission can create and edit templates in public folders, while any user can create templates in their personal 'My Personal Email Templates' folder, which is private to them.

Lightning Email Templates: Templates live in Lightning folders, which use the enhanced folder sharing model similar to reports and dashboards. Folder access levels are Viewer (can see and use templates), Editor (can also create, edit, and delete templates in the folder), and Manager (can also share the folder and change its settings). Admins can grant access to users, roles, roles and subordinates, and public groups. Subfolders inherit sharing from parent folders. Users need the 'Manage Public Lightning Email Templates' permission to create public folders and templates, and 'Create Folders for Lightning Email Templates' to create folders. The 'Access Lightning Email Templates' permission (or 'Use Lightning Email Templates') controls whether users can see and use Lightning templates at all.

Best practices include organizing folders by department or process (Sales, Service, Marketing), using public groups for scalable sharing instead of individual users, restricting Editor and Manager access to template owners, and periodically auditing folder sharing to prevent unauthorized changes to customer-facing communications. Remember that folder access controls visibility, but merge field data shown in a sent email still respects the sending user's field-level security and record access.

Enterprise Territory Management (ETM) in Salesforce provides a way to organize and grant record access based on territories rather than solely on the role hierarchy. Territories are arranged in a territory model, which contains a territory hierarchy. Only one territory model can be active at a time, though you can build and test others in Planning state before activating. Each territory can have users assigned to it, and accounts can be assigned either manually or through assignment rules based on field criteria such as billing state or industry.

Record access in ETM works alongside the standard sharing model. When accounts are assigned to a territory, users in that territory automatically receive access to those accounts. The level of access is controlled at the territory model level through default access settings. Administrators define the default access for accounts (View or View and Edit), as well as for related opportunities, cases, and contacts (No Access, View, or View and Edit). These defaults can be overridden for individual territories to grant more or less access as needed, but they can never be more restrictive than the organization-wide defaults.

Territory access also respects the hierarchy: users assigned to a parent territory inherit access to records in child territories, similar to how the role hierarchy works with Grant Access Using Hierarchies. Opportunities can be assigned to territories using filter-based assignment, and the Territory field on an opportunity determines which territory's users gain access.

For the Platform Administrator II exam, remember that ETM must be enabled by Salesforce and requires a territory model to be active. Access granted through territories is additive, meaning it supplements rather than replaces access provided by roles, sharing rules, or manual sharing. Administrators should also understand that users can be assigned to multiple territories, and forecasting can be based on territories. ETM is ideal for organizations where sales structures do not align neatly with a single role hierarchy.

Troubleshooting record access in Salesforce requires understanding how the sharing model layers build on each other. Start with Organization-Wide Defaults (OWD), which set the baseline access for each object (Private, Public Read Only, Public Read/Write, or Controlled by Parent). From there, access is opened up through the role hierarchy, sharing rules, manual sharing, team sharing, and Apex managed sharing. Access is never restricted below the OWD level by these tools, so if a user has more access than expected, one of these layers is granting it.

The Sharing Hierarchy button (visible on a record when the object's OWD is more restrictive than Public Read/Write) is the primary troubleshooting tool. Clicking it displays a list of users who can access the record and, critically, the reason why: Owner, Role Hierarchy, Sharing Rule, Manual Sharing, Team, Territory, or Apex Sharing. Administrators can also click 'Why can I see this?' or use the Sharing button to expand details on a specific user.

When a user cannot see a record, follow a systematic approach: 1) Confirm the user has object-level Create/Read/Edit/Delete permissions via Profile or Permission Set—no sharing setting matters if object access is missing. 2) Check field-level security if specific fields are hidden. 3) Verify the OWD for the object. 4) Check whether 'Grant Access Using Hierarchies' is enabled (it is always on for standard objects but can be disabled for custom objects). 5) Review the user's role placement relative to the record owner. 6) Examine owner-based and criteria-based sharing rules, including public groups and queues the user belongs to. 7) Look for manual shares or account/opportunity/case team membership.

Also remember that implicit sharing grants parent account read access when a user has access to a child contact, opportunity, or case, and that View All/Modify All permissions bypass sharing entirely. Using the Sharing Hierarchy view together with this layered checklist allows administrators to quickly diagnose and resolve record visibility issues.

Field-Level Security (FLS) in Salesforce controls whether a user can see or edit a specific field on an object, regardless of the record's visibility or page layout configuration. It is a critical layer of the security model, sitting beneath object-level permissions and above page layouts. For the Platform Administrator II exam, understanding how FLS is granted through both Profiles and Permission Sets is essential.

Profiles define the baseline field access for a user. Each user has exactly one profile, and that profile specifies, for every field, whether the user has Read access, Edit access, or no access. Fields hidden via FLS on a profile are completely invisible to that user—in page layouts, list views, reports, search results, related lists, and API calls. Setting a field to Read-Only in FLS overrides any editable setting on a page layout.

Permission Sets extend access beyond the profile. They are additive only: a permission set can grant Read or Edit access to a field, but it can never remove access already granted by the profile or another permission set. A user can be assigned many permission sets, and Salesforce evaluates the union of all permissions. For example, if a Sales Rep profile grants no access to the Discount Percent field, assigning a permission set with Edit access on that field enables editing for that user without changing the profile for everyone else.

Permission Set Groups bundle multiple permission sets and support muting permission sets, which can suppress specific field permissions within the group—though muting never affects the underlying profile.

Best practice, aligned with Salesforce's direction, is to keep profiles minimal and manage FLS primarily through permission sets and groups. Administrators should also remember that FLS applies universally across the UI, Flow, Apex (when enforced with WITH SECURITY_ENFORCED or stripInaccessible), and the API, making it the authoritative control for field visibility and editability.

In Salesforce, custom profiles and permission sets are both tools for granting users access, but they serve distinct roles in a well-designed security model. A profile is mandatory: every user is assigned exactly one, and it defines the baseline of what that user can do. Custom profiles are created by cloning standard profiles and adjusting settings such as object permissions (create, read, edit, delete), field-level security, page layout assignments, record type access, tab visibility, app access, Apex class and Visualforce page access, login hours, login IP ranges, and system permissions. Because profiles are so comprehensive, organizations historically created many of them to accommodate slight variations in job roles, which led to administrative bloat and difficulty maintaining consistency.

Permission sets solve this problem. A permission set is a collection of settings and permissions that extends a user's access without changing their profile. Users can be assigned multiple permission sets, so administrators can grant additional capabilities such as access to a new object, a specific field, a custom app, or a system permission like 'Export Reports' to a subset of users who share a profile. Permission sets can only grant access, never remove it. Permission set groups bundle related permission sets together and can include muting permission sets to selectively remove permissions within the group.

The recommended approach is to keep profiles minimal, assigning the least privilege needed for the broadest group, and then layer permission sets on top for role-specific or temporary needs. Certain settings, such as login hours, IP ranges, default page layouts, and default record types, still live only on the profile, which is why profiles remain necessary. Salesforce is actively moving toward a permission set-centric model, so administrators should design security with permission sets as the primary mechanism for granting access and profiles as a lightweight foundation.

Permission Set Groups are a Salesforce feature that let administrators bundle multiple permission sets into a single, reusable container that can be assigned to users as one unit. Instead of assigning five or six individual permission sets to every user in a role (for example, Sales Operations), you create one Permission Set Group containing all of them and assign that group. The user receives the combined, cumulative permissions of every permission set in the group. This simplifies administration, reduces assignment errors, and aligns well with the principle of building permissions around job functions rather than profiles. Permission Set Groups also support the recommended shift away from heavily customized profiles toward a minimal-access profile plus permission sets and groups.

Muting Permission Sets solve a specific problem: sometimes a permission set you want to include in a group grants one or two permissions that a particular group of users should not have. Rather than cloning and editing the permission set (which creates maintenance overhead), you add a Muting Permission Set to the group. A muting permission set lets you selectively 'mute' or remove specific permissions—such as object permissions (Create, Read, Edit, Delete, View All, Modify All), field permissions, user permissions, custom permissions, or app permissions—within that group only. Muting never grants access; it only suppresses access that would otherwise be inherited from the group's permission sets, and it only affects users through that group, not the original permission sets elsewhere.

Key exam points: a Permission Set Group can contain only one Muting Permission Set; muting applies only within the group; after adding or changing permission sets, the group recalculates (status shows Updating then Updated); and users still require any licenses the underlying permission sets need. Permission Set Groups cannot be nested inside other groups. Also remember that permissions are additive overall—muting is the only subtractive mechanism, and it cannot remove access granted by the profile or by permission sets assigned directly outside the group.

Delegated Administration in Salesforce allows a system administrator to assign limited administrative privileges to selected non-administrator users without granting them the full 'Customize Application' or 'Manage Users' permissions. It is a key topic in the Platform Administrator II exam under Security and Access because it supports the principle of least privilege while decentralizing routine user management. Administrators create Delegated Groups in Setup (Delegated Administration), define which users belong to the group (the delegated administrators), and then specify exactly what those delegates can do. Delegated administrators can: (1) create and edit users in specified roles and all roles below them in the role hierarchy, including resetting passwords, unlocking users, and setting quotas; (2) assign users only to a predefined list of profiles and permission sets; (3) manage login access policies, such as granting login access to administrators; and (4) administer specified custom objects and their custom tabs, including creating fields, page layouts, record types, and validation rules, though they cannot modify sharing rules or relationships. Delegates cannot assign profiles or permission sets that include 'Modify All Data' or other permissions they lack themselves, preventing privilege escalation. The 'Enable Group for Login Access' option lets delegates log in as users in their roles if the org permits it. Common exam scenarios involve a regional manager who needs to create and maintain users for their department, or a department owner who needs to maintain picklist values on a departmental custom object, without receiving full administrative rights. Delegated Administration is distinct from Permission Sets or Profiles: it is a Setup feature scoped by role hierarchy and custom object, not a general permission grant. Best practices include auditing delegated groups regularly, keeping assignable profile lists minimal, and documenting the scope of each group to maintain security and compliance.

In Salesforce Security and Access, 'View All' and 'Modify All' are object-level permissions that override sharing settings for a specific object. When a user has 'View All' on an object (e.g., Accounts), they can see every record of that object regardless of organization-wide defaults (OWD), role hierarchy, sharing rules, or manual sharing. 'Modify All' grants the ability to read, edit, delete, transfer, and approve all records of that object, again bypassing the sharing model. These permissions are set on profiles or permission sets and are ideal for delegating broad data access to a specific team (such as a sales operations group) without granting full system-wide privileges. Because they ignore sharing, Salesforce recommends using them sparingly and auditing them regularly.

'View All Data' and 'Modify All Data' are administrative (system) permissions that apply across ALL objects in the org, including custom objects, and are far more powerful. 'View All Data' lets a user see every record in the system, while 'Modify All Data' allows reading, editing, deleting, and transferring any record, as well as running certain data operations like mass transfers and managing public reports or dashboards. These are typically reserved for System Administrators or integration users.

Other key administrative permissions include 'Customize Application' (modify setup, fields, page layouts, validation rules), 'Manage Users' (create/edit users, reset passwords, assign profiles and permission sets), 'Manage Sharing' (edit OWD and sharing rules), 'Manage Profiles and Permission Sets', 'Author Apex', 'View Setup and Configuration', and 'API Enabled'. Many of these are interdependent; for example, Modify All Data is often required before enabling other advanced permissions.

For the Platform Administrator II exam, remember the principle of least privilege: prefer object-level View All/Modify All (scoped) over the org-wide View All Data/Modify All Data, use permission sets rather than cloning profiles, and understand that object-level 'All' permissions override sharing but not field-level security. Field-level security still restricts visibility of individual fields even when a user has Modify All Data.

Single Sign-On (SSO) allows users to authenticate once with a trusted system and gain access to Salesforce without entering separate credentials. In the Platform Administrator II exam context, understanding SAML-based SSO and identity providers is essential for the Security and Access domain.

SAML (Security Assertion Markup Language) is an XML-based open standard for exchanging authentication and authorization data between two parties: the Identity Provider (IdP) and the Service Provider (SP). The IdP is the system that authenticates the user and vouches for their identity, such as Okta, Microsoft Entra ID (Azure AD), Ping Identity, or Active Directory Federation Services. The SP is the application the user wants to access, in this case Salesforce. Salesforce can also act as an IdP for other applications, enabling users to log in to Salesforce and then access connected apps seamlessly.

The flow works in two ways. In IdP-initiated SSO, the user logs in to the IdP portal, clicks a Salesforce link, and the IdP sends a signed SAML assertion to Salesforce. In SP-initiated SSO, the user goes to a Salesforce URL or My Domain, is redirected to the IdP for authentication, and is returned with the assertion. Salesforce validates the assertion using the IdP certificate and matches the user via Federation ID or Salesforce username, as configured in the SSO settings.

Key administrator tasks include enabling SAML under Single Sign-On Settings, uploading the IdP certificate, specifying Issuer and Entity ID, choosing the identity mapping (Federation ID is recommended), and configuring My Domain to enforce or allow SSO. Admins can enable Just-in-Time provisioning to create users automatically from assertions. Permissions like 'Is Single Sign-On Enabled' control delegated authentication, while SAML login can be restricted by profile. Troubleshooting uses the SAML Assertion Validator and Login History. Benefits include centralized password policies, reduced help desk tickets, stronger security through multi-factor authentication at the IdP, and faster deprovisioning when employees leave.

Multi-Factor Authentication (MFA) in Salesforce adds a critical layer of security by requiring users to verify their identity with two or more factors when logging in: something they know (username and password) plus something they have (a verification method). Since February 2022, Salesforce contractually requires MFA for all users accessing the platform through the user interface, making it an essential topic for Platform Administrator II candidates in the Security and Access domain.

Supported verification methods include the Salesforce Authenticator mobile app (which supports push notifications and location-based automation), third-party TOTP authenticator apps such as Google Authenticator or Microsoft Authenticator, physical security keys using FIDO2/WebAuthn or U2F standards (like YubiKey), and built-in authenticators such as Windows Hello or Touch ID. Email and SMS codes are not considered valid MFA methods under Salesforce's requirement.

Administrators enable MFA for UI logins by assigning the 'Multi-Factor Authentication for User Interface Logins' user permission through a profile or, preferably, a permission set. The separate 'Multi-Factor Authentication for API Logins' permission enforces MFA for API access, requiring a time-based token appended to the password. Alternatively, admins can enable MFA org-wide using the 'Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org' setting under Identity Verification in Session Settings.

When MFA is active, users register their verification method on first login. Admins manage users' methods from the user detail page, can disconnect a lost device, generate temporary verification codes (valid 1 to 24 hours) when a user is locked out, and monitor adoption using the Identity Verification History page and reports on the Identity Verification Events object.

MFA can also be enforced contextually through Login Flows, session security levels (High Assurance), and profile-based session settings, allowing admins to raise assurance for sensitive actions. Exemptions exist for certain integration users, test automation users, and single sign-on scenarios where the identity provider handles MFA, which admins should document carefully.

In Salesforce, Login Hours, Login IP Ranges, and Trusted IP Ranges are security controls that govern when and from where users can access the org. Login Hours are set on a Profile and define the days and times users assigned to that profile may log in. If a user tries to log in outside the allowed window, access is denied; if already logged in when the window closes, the user is logged out and can only view the current page until saving is blocked. Hours are based on the org's time zone by default. Login IP Ranges are also configured at the Profile level (or in Setup for each profile) and restrict logins to specific IP address ranges. If a user attempts to log in from outside the defined range, the login is completely rejected, regardless of whether the user can verify identity. By default, this applies to the UI and API, though there is an org-wide setting to enforce ranges on every request, not just login. Trusted IP Ranges are set at the organization level under Network Access. They do not block logins; instead, they identify known networks. When a user logs in from a Trusted IP Range, Salesforce skips identity verification (such as the emailed verification code or activation challenge) and does not require a security token for API access. Logins from outside trusted ranges trigger identity verification for unrecognized browsers or devices. The key distinction is that Login Hours and Login IP Ranges restrict access and can deny login entirely, while Trusted IP Ranges simply relax verification requirements for recognized locations. Administrators often combine these: using Profile Login IP Ranges to lock down sensitive profiles like System Administrator or integration users, Login Hours for shift-based workers, and Trusted IP Ranges for the corporate network to streamline user experience. For the Platform Administrator II exam, remember where each is configured (Profile versus Network Access) and the difference between denying access and bypassing verification.

Session Settings in Salesforce (Setup > Security > Session Settings) govern how user sessions behave after login, forming a core part of the Platform Administrator II Security and Access domain. Key controls include session timeout (how long of inactivity before a user is logged out, with optional warning popups and the ability to force logout), 'Lock sessions to the IP address from which they originated' and 'Lock sessions to the domain in which they were first used' (reducing session hijacking), 'Require secure connections (HTTPS)', clickjack protection, CSRF protection, caching controls, and identity verification options such as 'Let users use a security key (U2F)' or verification via Salesforce Authenticator, SMS, or email.

A critical concept here is Session Security Levels. Salesforce assigns every login method a level: Standard or High Assurance. By default, username/password, Lightning Login, and delegated authentication map to Standard, while two-factor authentication (multi-factor authentication) and certain SAML or OAuth flows can be mapped to High Assurance. Administrators configure these mappings in Session Settings under 'Session Security Levels' by dragging login methods between the two columns.

A High-Assurance Session is one where the user authenticated using a method mapped to High Assurance, typically involving MFA. Admins can then require this elevated level for sensitive resources: via Profile settings ('Session security level required at login'), Connected App policies, Reports and Dashboards access, or Permission Sets. If a user with only a Standard session tries to access such a resource, Salesforce prompts them to step up by completing identity verification, raising the session to High Assurance without a full re-login.

For the exam, remember: session settings apply org-wide but can be overridden per profile; High Assurance is enforced through policies, not just set globally; and step-up authentication is a key tool for protecting sensitive data while minimizing friction. Understanding these distinctions helps secure access while balancing user experience.

Connected App Access Policies in Salesforce control how external applications authenticate and interact with your org through OAuth, SAML, or OpenID Connect. A connected app is a framework that lets an external application (mobile app, integration tool, third-party service) connect to Salesforce using APIs. Access policies define who can use the app, how users authorize it, and what security constraints apply.

Key policy settings include:

1. Permitted Users: Admins choose between 'All users may self-authorize' (any user with login access can approve the app on first use) or 'Admin approved users are pre-authorized' (only users assigned via profiles or permission sets can access the app, with no consent prompt). Pre-authorization is the preferred approach for tighter security.

2. IP Relaxation: Determines whether the app must honor the org's login IP restrictions. Options are 'Enforce IP restrictions', 'Relax IP restrictions' (bypass them), or 'Relax IP restrictions with second factor', balancing usability for mobile users against security.

3. Refresh Token Policy: Controls how long users stay authenticated without re-entering credentials. Options include refresh token valid until revoked, immediate expiration, expiration after a set period, or expiration if not used for a specified time.

4. Session Policies: Timeout values for the app's session, which can override org-wide session settings. High assurance session requirements can also be enforced.

5. OAuth Scopes: Define what data and actions the app can access (e.g., api, refresh_token, full, web), applying the principle of least privilege.

6. Start URL and Mobile Integration: Configure where users land and whether PIN protection applies on mobile devices.

Admins manage these under Setup > Connected Apps > Manage Connected Apps, where they can also monitor usage, block an app, or revoke tokens. For Administrator II, understanding these policies is essential to securing integrations, enforcing MFA, and controlling third-party access without compromising user productivity.

Person Accounts are a Salesforce feature designed for business-to-consumer (B2C) scenarios where an individual customer is both the account and the contact. In a standard B2B data model, an Account represents a company and Contacts represent the people who work there. Person Accounts combine these two objects into a single record, so a sole individual—like a retail shopper, patient, or private banking client—can be managed without creating an artificial company account.

From an Administrator II perspective, you should know that Person Accounts are enabled by Salesforce Support, and the change is irreversible. Prerequisites include having at least one record type on Account, setting Contact organization-wide default sharing to 'Controlled by Parent' (or Account to Private with Contact as Controlled by Parent), and ensuring profiles that read Accounts also read Contacts. Once enabled, a special 'Person Account' record type appears, and the IsPersonAccount field distinguishes them from business accounts. Person Account fields are accessed with the 'Person' prefix in API names (e.g., PersonEmail, PersonMobilePhone), while contact fields appear directly on the account layout.

Security and Access implications are significant. Because the Person Account is technically an Account record with a hidden associated Contact, sharing is controlled entirely through the Account object. Contact sharing rules, manual sharing, and Contact role hierarchies do not apply independently. Field-level security must be configured on both Account and Contact fields, since Person Account layouts display fields from both objects. Validation rules, workflows, and Flows can reference merged fields, but admins must test carefully because record type and profile assignments determine whether a user can create a Person Account versus a Business Account.

Limitations include no account hierarchies for Person Accounts, inability to convert a Person Account back to a Business Account, and constraints with some features like Account Teams or certain AppExchange packages. Understanding these trade-offs is critical before enabling the feature.

Contacts to Multiple Accounts is a Salesforce feature that allows a single contact record to be related to more than one account, reflecting real-world relationships such as a consultant who works with several client companies, a board member who sits on multiple organizations, or a parent associated with several schools. By default, each contact has exactly one primary account (the Account lookup on the Contact object). When an administrator enables Contacts to Multiple Accounts under Setup > Account Settings, Salesforce introduces a junction object called Account Contact Relationship (ACR). Each ACR record links one contact to one account and can store relationship details such as Roles (a multi-select picklist, e.g., Decision Maker, Influencer), Start Date, End Date, Active status, and whether the relationship is Direct (the contact's primary account) or Indirect. The contact's primary account relationship is automatically represented as a direct ACR; additional accounts are indirect relationships. Administrators can customize the ACR object by adding custom fields, validation rules, and page layouts, and can add the Related Contacts related list to the Account page layout and the Related Accounts related list to the Contact page layout. From a security and access standpoint, ACR records inherit sharing from both the parent account and the contact: a user generally needs read access to the account and contact to view the relationship, and access to the ACR object is controlled through profiles and permission sets (object permissions and field-level security). Note that enabling this feature affects reporting—administrators can build reports using the 'Contacts with Related Accounts' or 'Accounts with Related Contacts' report types. Also, if a contact's primary account is changed or if the feature is later disabled, indirect relationships may be lost, so careful planning is important. For the Administrator II exam, understand when to recommend this feature versus duplicating contacts, how ACR differs from Contact Roles, and the setup and security implications.

In Salesforce, Account Hierarchies and Business Account Models define how organizational relationships between companies are represented and how that structure interacts with security and access, a key topic for Platform Administrator II candidates.

Business Account Model: Salesforce distinguishes between Business Accounts (B2B, representing companies) and Person Accounts (B2C, merging Account and Contact into one record). The standard business model uses Accounts as parent records with related Contacts, Opportunities, Cases, and Activities. Because the Account is the hub, sharing on child objects is often controlled through the account owner and the Organization-Wide Default (OWD) settings for Contact, Opportunity, and Case, which can be set to 'Controlled by Parent' or managed independently.

Account Hierarchies: The Parent Account field (a self-lookup on Account) links subsidiaries, divisions, or regional offices to a headquarters account. Users can click 'View Hierarchy' to see the tree structure, which is configurable via Account Hierarchy columns in Lightning. Hierarchies help with roll-up reporting, territory assignment, and understanding enterprise-wide relationships.

Security and Access implications: Importantly, the account hierarchy does NOT automatically grant record access. Owning a parent account does not give visibility to child accounts unless sharing rules, the role hierarchy, teams, or manual sharing provide it. Administrators often use Account Teams to grant collaborative access across the hierarchy, Account Sharing Rules (criteria- or owner-based), or Enterprise Territory Management to align access with hierarchical structures. Apex managed sharing can be used for complex hierarchical access requirements.

Additional considerations include Implicit Sharing: users with access to a child record (such as a Contact or Opportunity) receive read-only access to the parent Account, and account owners gain implicit access to child records based on OWD. Administrators must also consider Record Types, Page Layouts, and Field-Level Security that vary by account type.

Understanding these models allows administrators to design scalable data structures while ensuring the right users see the right accounts and related data.