Salesforce Advanced Administrator Mock Exam: Key Concepts by Domain
Before you sit a timed Salesforce Advanced Administrator (Platform Administrator II) mock exam, you need to know what's actually being tested. Below is every domain from the official exam blueprint, broken down into the concrete concepts that show up again and again across our 130-question practice bank, so you can study with intent instead of rereading documentation at random.
Key concepts to know, domain by domain
Each domain below lists the concepts that come up most often in our practice question bank, the same questions you'll see in the timed mock exam.
Security and Access
Advanced sharing solutions (territories, teams, manual shares), restriction rules, permission set groups, and diagnosing exactly who can see what and why.
1. Permission Sets, Groups & Delegated Admin
Layer Access, Do Not Edit Profiles: When a handful of users across different profiles need more (View All on an object, View All Data, Read on every lead), create one permission set and assign it rather than editing several profiles or cloning one for a single user. Permission set groups bundle the sets a persona needs, and a muting permission set removes specific permissions inside a group without touching the underlying sets.
Delegated Administration: A delegated group lets a non-administrator create and edit users in specified roles, reset their passwords, assign the permission sets and groups the group lists, and customize the custom objects assigned to it. Delegates cannot create or edit permission sets, sharing rules, or organization-wide defaults, which stay with the full administrator.
Field-Level Security Lives on Profiles and Permission Sets: Field visibility is granted or hidden per profile and permission set, and it applies everywhere: record pages, list views, reports, and the API. Record types and page layouts never secure a field, so when only the record page should differ while reports stay complete, use Dynamic Forms visibility rules instead of field-level security.
2. Sharing Model & Record Access
OWD, Role Hierarchy & Sharing Rules: Start from the organization-wide default, then open access upward through the role hierarchy (Grant Access Using Hierarchies gives directors their managers' records with no extra setup) and sideways through sharing rules. An owner-based rule from a role to that same role lets peers edit and transfer each other's records while the default stays Private; criteria-based rules share on field values.
Teams, Manual Shares & Troubleshooting: Account Teams and Opportunity Teams grant a named colleague access to one record; team members can be added by the record owner, by users above the owner in the hierarchy, or by administrators. When two users with identical profile and role see different records, the difference is record-level sharing such as a manual share, because defaults and hierarchy apply uniformly.
Controlled by Parent & Junction Objects: A Contact set to Controlled by Parent is editable by the account owner and everyone above them in the hierarchy. A junction object's records are visible only to users who can read both master records, and the Sharing Setting on each master-detail field (Read Only or Read/Write) defines the minimum access on the master needed to create or edit detail records.
Restriction and Scoping Rules: Restriction rules filter the records a user can see down to those matching a criterion (for example only tasks they own) on top of everything sharing already grants; they never add access and are available on custom objects and a set of standard objects such as tasks, events, and contracts. Scoping rules only set a default filter the user can clear. Record type assignment on a profile controls creation choices and never record access.
3. Authentication, Sessions & Security Posture
MFA Verification Methods: Salesforce accepts authenticator apps (Salesforce Authenticator or any TOTP app), WebAuthn/FIDO2 security keys, and built-in authenticators such as Touch ID or Windows Hello. Codes sent by email or SMS are excluded, and the API security token is for integration logins, not interactive verification.
Session Settings & High Assurance: Clear Disable session timeout warning popup so users can save work before an idle session expires; Force logout on session timeout sends them straight to the login page. A session security level policy can require a high-assurance session for sensitive actions such as exporting reports, which is why users are prompted for identity verification on Export.
Health Check, Data Classification & External Access: Security Health Check scores session, password, clickjack, XSS, and content sniffing settings against the Salesforce baseline. Data Classification fields (Data Owner, Field Usage, Data Sensitivity Level, Compliance Categorization) build a queryable inventory of sensitive fields, and the Sharing Settings page lists each object's Default External Access next to its internal default.
Offboarding, Merges & Encrypted Fields: Freeze a departing user first (users cannot be deleted), then reassign records and email alert recipients before deactivating. Merging records requires the Delete permission because the duplicates are deleted. Classic encrypted fields can still be checked by validation rules (LEN and REGEX), while mask types only control display.
Objects and Applications
Advanced object architecture, record types and page assignments at scale, and app designs that stay maintainable as the org grows.
1. Relationships & Data Model
Lookup vs Master-Detail: Master-detail children inherit the parent's sharing, are deleted with it, and enable roll-up summaries; a lookup gives the child its own organization-wide default and survives parent deletion, which is what retention rules and restricted-audience records need. A lookup converts to master-detail only once every child has a parent, and master-detail converts back to lookup only after every roll-up summary on the master is deleted.
Junction Objects: A junction object carries two master-detail relationships. Deleting one master sends the junction records to the Recycle Bin and restoring that master brings them back; if the second master is also deleted, the junction records are permanently deleted. Setting the relationship's Sharing Setting to Read Only lets anyone who can view the master create the link.
Roll-Up Summaries, Formulas & Validation: Roll-up summary fields sit on the master side, support COUNT, SUM, MIN, and MAX (no AVG), accept filter criteria such as Status equals Scheduled, and recalculate as part of the detail record save. Formula fields cannot aggregate child records. REGEX in a validation rule is the only declarative way to enforce an exact format such as a postal code or a 16-digit number.
External Objects & Lightning Object Creator: Salesforce Connect external objects expose data that stays in an outside system in related lists, lookups, and reports without copying it. Lightning Object Creator builds a custom object, its fields, and the records from a spreadsheet in one guided step. An object whose Deployment Status is In Development is invisible to users without Customize Application, including through Data Loader.
2. Record Types, Layouts & Page Design
Record Types at Scale: One record type per team or division gives each its own sales or support process (stage values), picklist values, and page layout while keeping every deal on one object for pipeline reporting. Page layouts are assigned by profile and record type, never by role; a user's record type assignment only governs which types they can create.
Dynamic Forms & Visibility Rules: Dynamic Forms breaks the record detail into fields and Field Sections that each accept visibility rules on record values (Market equals Commercial), the viewing user's profile, or a custom permission. It changes display only, so reports keep every field, which is exactly where field-level security would overreach. The standard Record Detail component just renders the assigned page layout.
Dynamic Actions & Component Visibility: Dynamic actions are enabled on the Highlights Panel, where each action takes a visibility filter such as Stage equals Negotiation or Hazardous equals true. Component visibility filters on any Lightning page component evaluate record fields (Billing Country equals Mexico for a temporary Rich Text warning) or the viewing user's role and profile (a chart only Sales Managers see).
Quick Actions & Mobile Productivity: An object-specific Update a Record quick action with predefined field values gives field reps a one-tap Closed Won in the mobile app; global actions have no record context and cannot update the current record. Prefer these declarative tools over custom components for small productivity needs.
3. Person Accounts & App Design
Person Accounts: Use Person Accounts when the individual consumer is the customer (business-to-consumer), not when a company has a primary contact. Enabling them is irreversible, requires the Contact organization-wide default to be Controlled by Parent, consumes storage for an account plus a hidden contact, and a lead converts into a person account only when its Company field is blank.
Maintainable App Design: Favor one object per business entity and solve display differences with Dynamic Forms, dynamic actions, and visibility rules before adding record types, page layouts, profiles, or custom objects. Each extra artifact is another thing to deploy and secure, and a split object fragments reporting and forecasting.
Auditing and Monitoring
Setup Audit Trail, login forensics, field history, and the monitoring tools that diagnose org changes and issues.
1. Audit Trails & Change History
Setup Audit Trail: Setup Audit Trail keeps 180 days of configuration changes with the acting user, date, and description, downloadable as CSV. It answers who changed a user's profile, who configured directly in production, and what drifted in production since a sandbox refresh so a deployment now fails. Field history tracking is not available on the User object.
Field History vs Trend Reporting: Field history tracking records changes to up to 20 fields per object and retains them for 18 months in the org (24 months through the API); Field Audit Trail extends retention up to ten years. Historical Trend Reporting and reporting snapshots capture business data over time, never configuration changes.
2. Login & Identity Forensics
Login History & Identity Verification History: To measure MFA adoption, filter Identity Verification History on the Method column (as a Setup list view or a custom report type) or export Login History and filter the Authentication Method Reference column. Login Access Policies only controls whether support staff can log in as users; Session Settings is configuration with no usage data.
Login Forensics & Event Monitoring: Login Forensics, part of Event Monitoring, aggregates login events to surface anomalies such as a burst of failed logins per user or IP address, the signature of a brute-force attempt. Event Manager configures event streaming rather than analysis, and Connected Apps OAuth Usage shows which apps users have authorized.
3. Debugging Automation & Performance
Debug Logs & Trace Flags: Set a trace flag on the user, raise the Workflow category to FINER or FINEST to see every flow element, and read FLOW_ event types (FLOW_START_INTERVIEW, FLOW_ELEMENT_ERROR) in the log. Platform event subscribers run as the Automated Process user, so they appear only in a debug log whose traced entity is Automated Process.
Page Performance Analysis: Click Analyze in Lightning App Builder to get a predicted load time and component-level recommendations for a slow record page, and use the Lightning Usage App to trend experienced page time across the org. Debug logs cover server-side execution, not client-side rendering.
Email Logs & Delivery Limits: When flow email alerts stop arriving because the daily workflow and flow email allocation is exhausted, request Email Logs in Setup: they list every email sent in a window with sender, recipients, and status, so the automations consuming the allocation can be identified. The HTML Email Status report only tracks opens of user-sent emails.
Cloud Applications
Advanced Sales Cloud and Service Cloud features: collaborative forecasting, territories, entitlements, and Salesforce Knowledge.
1. Sales Cloud: Forecasting, Territories & Products
Collaborative Forecasts: A rep appears in the forecast rollup only when Allow Forecasting is enabled on their user record; the forecast hierarchy follows the role hierarchy (or the territory hierarchy). Owner and manager adjustments change amounts, and Override Forecasts belongs to the retired Customizable Forecasting.
Enterprise Territory Management: Territories assign accounts (and their opportunities) by rules or manually and grant access to territory members independently of the role hierarchy, with access levels set per object in the territory model. Use it when geography or segment-based access overlays the reporting hierarchy.
Price Books & Products: Reps can add a product only when it has an active price book entry in the price book selected on the opportunity. A separate price book serves a new market with local prices or a pre-approved promotional bundle that must bypass a discount approval; a product start date is informational only.
Quotes & Opportunity Products: An opportunity can hold many quotes but only one is synced, so each configuration gets its own quote and the most likely one syncs to drive the pipeline amount. Data that belongs to each line sold (plan start and end dates) lives on Opportunity Product, where a validation rule can require it by product family.
2. Service Cloud: Entitlements, Routing & Knowledge
Entitlements & Milestones: An entitlement process defines milestones with time limits (first response in four hours, resolution in two business days) and the milestone tracker shows agents the time remaining. Milestones live inside the entitlement process, not directly on Service Contract records.
Case Routing & Escalation: Assignment rules route a case once at creation, auto-response rules send the acknowledgment, and escalation rules monitor case age to reassign and notify when a limit approaches. Omni-Channel with skills-based routing sends each case to an available agent with the matching skills; macros are agent shortcuts, not routing.
Knowledge & Data Categories: Data categories classify articles by product line so agents filter results instead of wading through every article, and category group visibility controls which categories each role or profile sees. Einstein Search improves relevance ranking but does not provide category filtering.
3. Account & Contact Relationships
Contacts to Multiple Accounts: With Contacts to Multiple Accounts enabled, the Related Contacts related list shows direct and indirect contacts together, and its Direct column marks whose primary account this is. Related Accounts belongs on the contact page.
Lead Conversion & Person Accounts: A lead converts into a person account only when Company is blank, otherwise the conversion offers business account record types only. Enforce the blank Company on consumer lead record types with a validation rule rather than patching the record type after conversion.
Data and Analytics Management
Custom report types, joined reports and dashboards, data quality tooling, and large-data considerations from an admin's seat.
1. Loading & Importing Data
Pick the Right Tool: Data Import Wizard handles up to 50,000 records per job for accounts, contacts, leads, solutions, campaign members, person accounts, and custom objects; Campaign Members only appears when the Marketing User checkbox is set on the user. Data Loader loads up to five million records and, with the Bulk API enabled, processes large migrations in parallel batches.
Upsert With External IDs: Upsert matches rows on an External ID field, updates existing records, and inserts the rest in one run. Insert would duplicate the existing records and Update fails on rows with no match, so upsert is the answer whenever a file mixes new and existing records.
Data Export Size: A scheduled data export shrinks by exporting only the objects needed and by deselecting images, documents, and attachments plus Salesforce Files and CRM Content versions. Running it more often changes frequency, not file size.
2. Data Quality
Matching Rules & Duplicate Rules: A matching rule defines how records are compared (fields, exact or fuzzy); a duplicate rule decides what happens on a match (block, or allow with an alert and a report). To cut false alerts on common names, add Email to the matching rule rather than switching the duplicate rule to Report, which lets duplicates in.
Merging & Cleanup: Merging accounts, contacts, or leads keeps one master and deletes the rest, so the user needs Delete on the object. Mass Transfer changes ownership of existing records and Lightning Object Creator loads a spreadsheet into a new object; neither replaces a deduplicated source file.
3. Reporting & Dashboards
Summary Formulas: PREVGROUPVAL returns the summary of the previous grouping at the same level, which computes year-over-year change or percentage change; PARENTGROUPVAL references the parent grouping for share-of-total. Row-level formulas see a single record and cannot compare rows.
Cross Filters: Cross filters restrict parent records by conditions on related children (Accounts with Opportunities closed this year, Accounts without Assets where Product Name equals CK-200) while keeping only parent rows in the output. Filter logic combines field filters only; a joined report would display the child details instead.
Unique Counts, Buckets & Custom Report Types: Show Unique Count on a column adds a distinct count (number of different accounts behind many opportunities) to groupings and the footer. Bucket columns group values without creating fields, and custom report types define which objects join (with or without related records) and which fields are available.
Dashboards: Place the Dashboard component on a Home page in Lightning App Builder so a team sees its pipeline at login. Dynamic dashboards run as the viewing user, subscriptions email a static snapshot on a schedule, and reporting snapshots store report results over time for trend reporting.
Environment Management and Deployment
Sandbox types and their use cases, change sets and their gotchas, and a sane release strategy between environments.
1. Sandboxes
Sandbox Types & Refresh Intervals: Developer (200 MB, refresh daily) and Developer Pro (1 GB) copy metadata only; Partial Copy (5 GB, refresh every 5 days) adds sample data chosen by a sandbox template; Full (production-sized data, refresh every 29 days) is the one for user acceptance, performance testing, and rehearsing changes such as relationship conversions against real volumes.
Clone, Template & Refresh: Cloning copies another sandbox's metadata and data, so cloning one configured Developer sandbox ten times yields ten identical environments. Sandbox templates select objects for Partial Copy and Full sandboxes created from production, and a refresh replaces the sandbox with a fresh copy of production.
Data Mask: Before external testers work in a Full or Partial Copy sandbox, run Salesforce Data Mask to replace sensitive fields with fictitious values while keeping the data set realistic. Permission tweaks and manual deletion are error-prone and do not protect against anyone with broad sandbox access.
2. Change Sets & Release Strategy
Change Set Permissions & Mechanics: Create and Upload Change Sets is needed in the source org, Deploy Change Sets in the target. An uploaded change set cannot be edited, so clone it to add a forgotten component. View/Add Dependencies never pulls in profiles or permission sets, which must be added deliberately.
Profiles & Field-Level Security Travel Together: A profile in a change set carries settings only for components in that same change set, so field permissions deploy only when the new fields and the profiles ship together. Deploy a record type with its object, layouts, and picklist values, not alone.
Release Strategy & Drift: Validate the inbound change set in the target org, then Quick Deploy within ten days to commit during a short window. When a package that passed in a Full sandbox fails in production, read Setup Audit Trail for what changed since the refresh. Change sets move metadata from sandbox to production; unmanaged packages distribute to unrelated orgs; Lightning web components are edited in Visual Studio Code with the Salesforce Extension Pack, not the Developer Console.
Process Automation
Advanced Flow Builder: record-triggered and scheduled flows, subflows, error handling, and choosing an automation architecture that scales.
1. Record-Triggered Flows
Before-Save vs After-Save & Order of Execution: Before-save (fast field update) flows set fields on the triggering record with no DML; after-save flows create or update related records, send emails, and call actions. Assignment and auto-response rules run before after-save flows, so a value a rule depends on must be set in a before-save flow or the rule evaluates the old value.
Entry Conditions & Newly Qualifying Edits: Trigger on create or update and use the entry condition (or a Decision outcome) Only when a record is updated to meet the condition requirements to isolate actions that must run only when an edit newly qualifies the record, while everything else runs every time. A scheduled flow cannot tell a fresh edit from an unchanged record.
Trigger Order & Consolidation: Several record-triggered flows on the same object and trigger run in no guaranteed order unless each has a trigger order value (1 to 2,000). When one step depends on another (create an Inspection, then update it), put both in one flow; one flow per object per trigger type is the design guidance.
Delete Triggers, Alerts & Notifications: A flow that runs when a record is deleted executes before the deletion is committed, so it can read the record and the current user and send an email alert or custom notification about who deleted what. Email alerts can target a public group, which mixes users, roles, and groups per project team.
2. Scheduled Paths, Scheduled Flows & Subflows
Scheduled Paths: A scheduled path on a record-triggered flow runs actions minutes, hours, or days after the trigger or after a date field on the record (a follow-up reminder before a renewal), with a configurable batch size. It replaces time-dependent workflow actions and scheduled actions from Process Builder.
Scheduled Flows: A schedule-triggered flow runs once, daily, or weekly at a set time over every record matching its filter, so it suits nightly batch work rather than immediate reactions to edits. Interviews count against the daily limit of 250,000 (or 200 per user license, whichever is greater), so filter tightly.
Subflows & Reuse: Put logic that several flows share (address formatting, team lookup) in an autolaunched flow and call it as a subflow with input and output variables, so a rule changes in one place. Custom permissions let an Apex trigger check FeatureManagement.checkPermission and leave the audience to permission set assignments.
3. Screen Flows, Approvals & Error Handling
Screen Flows & Debugging: A screen flow guides users through qualification questions and writes the result (an account Tier) while the field stays read-only on the layout. Debug as another user to reproduce a permission or validation error, and remember the debugger runs data operations for real, including deletes, unless rollback mode is selected.
Fault Paths & Error Handling: Connect a fault connector from every Create, Update, Delete, Get, and Action element to a path that records $Flow.FaultMessage, notifies an owner by email alert or custom notification, and shows users a readable screen instead of an unhandled error. Unhandled faults go to the recipients set under Process Automation Settings (the flow's last modifier or the Apex exception email recipients).
Approval Processes: An approval process defines entry criteria, approver selection (a named user, a queue, a related user field, or the submitter's manager through the role hierarchy), and initial submission, approval, rejection, and recall actions; a flow can submit records with the Submit for Approval action. When a case is pre-approved by design (a promotional bundle), model it so the approval never fires rather than deactivating the process.
Automation Architecture: Flow is the only tool for new declarative automation: Workflow Rules and Process Builder are retired, existing ones still run but no new ones can be created, and the Migrate to Flow tool converts them. Reach for the simplest fit first: a formula field to compute (the later of two dates), a validation rule to enforce, assignment rules to route, roll-ups to count, and a record-triggered flow only for actions that must happen automatically.
Ready to test what you just read?
Take a free Advanced Administrator mock exam under real timed conditions, then see your score broken down by domain so you know exactly where to focus next.
Take the mock examMock Exam FAQ
Everything you need to know before you start your Advanced Administrator mock exam.