Salesforce Administrator Cheat Sheet.

Salesforce renamed this credential to Salesforce Certified Platform Administrator and rebuilt the outline effective December 15, 2025: Workflow/Process Automation became Automation, and an Agentforce section was added. Everything below reflects the current guide, aligned to Summer '25.

Exam at a glance

Item	Value
Credential	Salesforce Certified Platform Administrator
Questions	60 scored multiple-choice + up to 5 unscored (65 items)
Time	105 minutes
Passing score	68% (English) · 65% (Japanese)
Registration / retake	$200 / $100 USD, plus applicable taxes
Delivery	Proctored — onsite test center or online
Prerequisites	None. Salesforce recommends 6+ months of admin experience
Release alignment	Summer '25
Upkeep	Trailhead maintenance module; miss it and the credential goes inactive, not revoked

Exam outline and weights

Eight sections. The "questions" column is the weight applied to 60 scored items — use it to budget study time.

Section	Weight	≈ Questions
Data and Analytics Management	17%	10
Configuration and Setup	15%	9
Object Manager and Lightning App Builder	15%	9
Automation	15%	9
Sales and Marketing Applications	10%	6
Service and Support Applications	10%	6
Productivity and Collaboration	10%	6
Agentforce	8%	5

The Agentforce section covers capabilities and use cases: when applying AI is appropriate, agent security, and troubleshooting agent permissions. An agent acts through a user and is bound by that user's access.

Record access: the security model in order

This is the single most tested model on the exam. Access is evaluated bottom-up: Organization-Wide Defaults set the floor, and every layer above can only open access further. Salesforce states it plainly — other record access features "can't be used to restrict access to records beyond what was originally specified with the organization-wide sharing defaults." A user's effective access is the most permissive grant they receive.

#	Layer	What it does	Direction	Can it restrict?
1	Organization-Wide Defaults	Baseline access to records the user does not own. Setup → Sharing Settings	Sets the floor	Yes — the only layer that can
2	Role Hierarchy	Managers inherit access to records owned by users beneath them	Upward only	No
3	Sharing Rules	Automatic, rule-based grants to public groups, roles, or roles-and-subordinates. Owner-based or criteria-based; grants Read Only or Read/Write	Lateral	No
4	Manual Sharing	One record, one time, via the Sharing button. Only the owner, anyone above the owner in the hierarchy, or an admin can do it	Ad hoc	No
5	Teams	Named users added to one record with a role and an access level — Account, Opportunity and Case teams	Per record	No

• Manual sharing is only available when the OWD is more restrictive than Public Read/Write. It is dropped automatically when record ownership changes.
• Grant Access Using Hierarchies is permanently on for standard objects; you can switch it off for custom objects only.
• View All / Modify All (per object) and View All Data / Modify All Data (org-wide) bypass sharing entirely. They are object/user permissions, not sharing.
• Record-level sharing never overrides field-level security. If FLS hides a field, the record's sharing is irrelevant.

Organization-wide default values

Setting	Non-owners can	Where it applies
Private	Nothing — owner and role hierarchy above only	Most objects
Public Read Only	View and report	Most objects
Public Read/Write	View and edit	Most objects
Public Read/Write/Transfer	View, edit, change owner	Leads and Cases only
Controlled by Parent	Whatever the parent record allows	Master-detail children and standard child objects
Public Full Access	View, edit, transfer, delete, report	Campaigns
View Only / Use	See or use entries	Price Books

Profiles vs permission sets vs groups vs muting

Salesforce is moving to a permission-set-led model: keep profiles thin, grant everything else additively.

Tool	Per user	Grants	Revokes	Decision rule
Profile	Exactly one, required	Baseline access	Implicitly (by omission)	Use only for what lives nowhere else: Login Hours, Login IP Ranges, default app, password policies. Keep it minimal.
Permission Set	Many	Additional access on top of the profile	Never	Grant the exception. One capability per set, named for what it grants.
Permission Set Group	Many	A bundle of permission sets, assigned as one unit	Never	Model a job persona from reusable sets instead of one giant set.
Muting Permission Set	Lives inside one group	Nothing	Turns a permission off within that group only	Use when a persona needs most of a set but not one permission.

• Muting is scoped: users assigned the same permission set directly are unaffected, and permissions granted by the profile still stand.
• Muting cascades to dependents — muting Delete also mutes Modify All Records. But muting Modify All Data does not automatically mute object permissions.

Record types vs page layouts vs Lightning record pages

Artifact	Controls	Does NOT control	Assigned by
Record Type	Which picklist values are available, which business process applies (Sales / Support / Lead / Solution), and which layout the user gets	Field-level security; which fields exist	Profile or permission set
Page Layout	Field placement, layout-required and read-only, related lists, buttons and actions	Cannot override FLS — FLS always wins	Profile × record type
Lightning Record Page	The Lightning Experience page: components, tabs, regions, dynamic component visibility. Built in Lightning App Builder	Field-level security; picklist availability	Org default, app default, or app + record type + profile
Dynamic Forms	Breaks layout fields into individually placeable, conditionally visible fields and sections	FLS	On the Lightning record page
Compact Layout	Highlights-panel fields and the mobile card	Anything in the record body	Per record type

Layout-required is UI-only; a field marked Required in Object Manager is enforced everywhere, including the API.

Automation: what to build with what

Workflow Rules and Process Builder reached end of support on December 31, 2025. Existing ones may keep executing, but Salesforce provides no support or bug fixes. Build everything new in Flow, and use Setup → Migrate to Flow to convert what you have.

Flow type	Trigger	Use it for
Screen Flow	A user launches it — Lightning page, action, utility bar, Experience Cloud	Guided data entry, wizards, anything needing input
Record-Triggered, before save	Create/update, before the record is committed	Setting fields on the triggering record itself. Fastest; no DML needed
Record-Triggered, after save	Create/update, after commit, same transaction	Related records, other objects, emails, subflows, scheduled paths
Record-Triggered, delete	Record deletion	Cleanup and cross-object housekeeping
Scheduled-Triggered	Date, time and frequency, optionally over a filtered record set	Nightly batch updates, renewal sweeps
Platform Event-Triggered	A platform event message is published	Event-driven integrations
Autolaunched (no trigger)	Called by another flow, Apex, a button or the API	Reusable subflows

Order of execution matters on the exam: a before save flow runs before validation rules, so a field it sets can still fail validation.

Requirement	Build it with
Block a save with a message	Validation Rule
Update fields, create/update related records, send email, call a subflow	Flow (record-triggered)
Collect input from a user step by step	Screen Flow
Multi-step submit / approve / reject with a locked record, approver history and recall	Approval Process
Complex bulk logic, intricate callouts, anything declarative tools cannot express	Apex
Anything you would previously have built as a workflow or process	Flow

Data management

Import Wizard vs Data Loader

	Data Import Wizard	Data Loader
Where	In-browser, Setup → Data Import Wizard	Installed client app, plus a Windows command line
Volume	Up to 50,000 records at a time	50,000 to 150,000,000 records with Bulk API 2.0
Objects	Accounts, contacts, leads, solutions, campaign members, person accounts, custom objects	Nearly all standard and custom objects
Operations	insert, update, upsert	insert, update, upsert, delete, hard delete, export, export all
Duplicate matching	Yes — by Salesforce ID, name and site, email, or external ID	No built-in matching
Scheduling	No	Yes, via the command line

Pick the Wizard for a small, supported-object load that needs dedupe. Pick Data Loader for volume, unsupported objects, deletes, exports, or anything recurring.

Relationships and roll-ups

	Lookup	Master-Detail	Junction (many-to-many)
Structure	Loose link between two objects	Master controls the detail record	Custom object with two master-detail relationships
Required?	Optional by default	Always required on the detail layout	Both are required
Ownership	Child has its own Owner	Detail has no Owner field — it inherits the master's	Inherits the primary (first) master
Sharing	Independent	Detail inherits the master's sharing and security	Inherits the primary master
Delete the parent	Child survives	Cascade delete — details and subdetails go too	Deleting either master deletes the junction record
Roll-up summary	Not supported	Supported on the master	Supported on both masters
Reparenting	Allowed	Off by default; enable Allow reparenting	Same as master-detail

Official limit: each custom object can have up to two master-detail relationships and up to 40 total relationships. A junction object therefore uses both master-detail slots. The first master-detail you create is the primary, and it drives the junction record's ownership, sharing and look and feel. Roll-up summary fields support COUNT, SUM, MIN and MAX.

Reports and dashboards

Format	Grouping	Chart	Use for
Tabular	None	No	Flat lists and exports. Needs a row limit to feed a dashboard
Summary	Up to 3 row groupings	Yes	Subtotals by group — the everyday format
Matrix	Row groupings plus up to 2 column groupings	Yes	Two-dimensional pivot comparisons
Joined	Up to 5 blocks, each with its own report type, columns and filters	Yes	Side-by-side views across different report types

Report types decide which records are even eligible: a with report type returns only parent records that have related child records, while with or without returns parents either way. Dashboards run either as a specified user (everyone sees identical data) or as the logged-in user — a dynamic dashboard, where each viewer sees only what their own access allows.

Limit	Value
Rows displayed in a report	2,000
Joined report blocks / columns per block	5 / 100
Bucket fields per report	5 (up to 20 buckets, 20 values each)
Widgets per dashboard	25 — max 20 charts and tables, 3 images, 25 rich text
Filters per dashboard / values per filter	5 / 50

Night-before checklist

• Recite the sharing order — OWD → Role Hierarchy → Sharing Rules → Manual Sharing → Teams — and that only OWD restricts.
• Manual sharing requires an OWD tighter than Public Read/Write.
• Public Read/Write/Transfer = Leads and Cases. Public Full Access = Campaigns.
• Profile = one per user and the floor; permission sets and groups only add; muting subtracts inside one group.
• Record type drives picklist values and business process; page layout drives placement; FLS beats both.
• Workflow Rules and Process Builder are out of support — the answer is almost always Flow.
• before save for the triggering record, after save for anything else.
• Over 50,000 records, or a delete or export? Data Loader.
• Master-detail: required, cascade delete, inherited sharing, roll-ups, max two per object.
• "Without code" or "least amount of effort" in a scenario is choosing the declarative answer for you.