Reviewed 10 October 2026 against the linked published scope. Current published weighting: setup 15%, objects/UI 15%, sales 10%, service 10%, productivity 10%, data/analytics 17%, automation 15%, Agentforce 8%.
Memory hook: License permits the feature; permissions permit the action; sharing permits the record.
Read the essentials, cover the answers and explain the decision aloud. Open the topic summaries below whenever a distinction is unclear.
Setup, data model and access
- Company settings establish locale, fiscal, currency and business-time behavior. A user license sets available capabilities; feature/permission-set licenses enable eligible additions. Users are deactivated rather than deleted; freezing blocks login without completing the deactivation/ownership cleanup process.
- Object permissions govern operations, field-level security governs fields and record access governs individual records. Page layouts and Lightning visibility organize UI; they are not substitutes for field/data security.
- Profiles provide baseline settings/permissions; permission sets add access. Groups combine permission sets and may mute contributions within that group; muting does not remove access granted elsewhere.
- Organization-wide defaults set baseline sharing. Hierarchies, teams, sharing rules and manual sharing can open access under their rules; ordinary sharing rules do not subtract permissions. View All/Modify All capabilities can bypass ordinary sharing boundaries.
- Login hours, IP settings, MFA/federation and session controls affect entry/session behavior. Diagnose identity, license, object/field permission and record access separately. Setup Audit Trail tracks configuration changes; login history helps investigate sign-ins.
- Lookup relationships are loosely coupled; master-detail gives the parent stronger control, supports eligible roll-up summaries and affects ownership/deletion. A junction object with two master-detail relationships models many-to-many. Deleting/changing fields can affect automation, formulas and stored data.
- Record types select processes/picklist choices and participate in layout assignment. Page layouts arrange record editing/detail; Lightning pages arrange components; dynamic visibility alters presentation. None automatically grants record access.
Sales, service and collaboration
- Lead conversion can produce or associate account/contact and optionally opportunity records. Opportunities track deals/stages; campaigns track marketing engagement and members. Assignment rules route eligible leads/cases when invoked by supported entry paths.
- Cases use status/priority/ownership, queues and support processes. Auto-response acknowledges; escalation acts on defined timing/criteria; Omni-Channel routes eligible work by configured capacity/availability/skills. These are different responsibilities.
- Tasks are to-do work; events reserve time. Chatter supports collaboration with membership/access boundaries. Mobile navigation, actions and supported page behavior need testing in the mobile context.
- AppExchange/AgentExchange offer packages and supported reusable components. Review publisher, permissions, license, dependencies and upgrade behavior before production installation. A marketplace listing does not prove suitability.
Data, analytics, automation and Agentforce
- Choose Import Wizard or Data Loader by supported objects, operation, volume and automation needs. Insert creates; update matches existing IDs; upsert can match supported external IDs. Reconcile successes/errors and relationship keys; back up before mass changes.
- Matching rules identify possible duplicates; duplicate rules define the reaction. Validation rules reject inappropriate data according to formulas; they do not automatically repair historical records.
- Report types define available object relationships/fields. Tabular lists, summary groups, matrix groups in two dimensions and joined combines supported blocks. Filters, grouping and date/currency context affect totals.
- Folder access controls analytical assets; underlying data permissions and running-user context govern displayed results. Dynamic dashboards use viewer context under supported rules; a dashboard can expose more than expected if its running user is overprivileged.
- Screen flows guide interaction; before-save record-triggered flows efficiently change the triggering record; after-save flows support related-record/actions use cases; autolaunched flows have no screens. Avoid database operations inside loops; handle faults and test bulk execution.
- Execution context depends on flow type/invocation/settings. Approval processes use entry criteria, approvers and approval/rejection actions; consider locking. Do not choose older automation solely because an old study guide does.
- Agentforce combines instructions, grounding and permitted actions. Trusted retrieval does not guarantee correct output; inspect data/action permissions, user context and connected Flow/Apex behavior. Test conversations and denied-access cases before releasing an agent change.
Exam traps
- Hidden on a page does not mean inaccessible through APIs/reports.
- A license enables eligibility; permissions and sharing still decide effective access.
- The current eight-domain outline includes Agentforce despite the older release line retained on the official guide.
Final active recall
1. A field is hidden on a page layout. Is it secure?
Not necessarily. Enforce field-level security and appropriate access controls.
2. Can a sharing rule make the baseline more restrictive?
Ordinary sharing rules extend access; they do not subtract it.
3. Matching rule versus duplicate rule?
Identification logic versus configured response to a possible duplicate.
4. Which flow is suited to updating only fields on the triggering record efficiently?
A suitable before-save record-triggered flow.
5. An agent cannot perform an action. What boundaries do you inspect?
Agent/user identity, data and object/field/record access, action permissions, execution context and the underlying Flow/Apex integration.
Sources and further practice
- Official exam scope
- Objective-to-topic coverage map. Each full topic links to its supporting primary technical documentation.
Every topic at a glance
Open any topic to revisit its essential facts, decisions and exam traps. Use the full topic for active recall and supporting references.
01 · Org Settings, Users and Login Controls
Memory hook: A license opens the product; permissions open the work.
Must remember
Company settings establish organizational defaults such as fiscal year, business hours, locale and currency behavior. User locale/time zone can affect presentation independently of company defaults. Business hours influence supported service timing; a fiscal-year change can affect reporting and should not be treated as a cosmetic label.
A user license sets the available product capabilities; feature/permission-set licenses enable eligible additional features. Profiles and permission sets then grant supported permissions within those entitlements. Adding a permission cannot bypass a missing license. Usernames must satisfy Salesforce uniqueness requirements and need not equal the person's working email address.
Freeze a user to block login promptly when appropriate; deactivate to remove active access and release the relevant user license under the platform's rules. Users are normally deactivated rather than deleted so ownership/history remains attributable. Transfer or review owned records, automation, schedules and integration dependencies before deactivation. Freezing alone does not free the license.
Login hours, IP restrictions, identity verification, MFA/federated login and session settings address different boundaries. A trusted network setting is not identical to a profile IP restriction. Test the actual login method and user context, including integrations and agent identities, before concluding access is blocked correctly.
Setup Audit Trail records configuration changes; login history helps diagnose authentication attempts. Neither is a complete history of every data-record change. Select evidence for the question, retain appropriate administrative records and limit powerful setup permissions.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Temporarily stop a user logging in | Freeze, while resolving deactivation dependencies. |
| Feature unavailable despite assigned permissions | Check user and feature license entitlements. |
| Investigate who changed setup | Setup Audit Trail. |
Traps
- Freezing a user does not release the license.
- User locale and org defaults are not always identical.
02 · Object, Field and Record Access
Memory hook: Can use the object, can see the field, can reach the record.
Must remember
Object permissions control operations such as read/create/edit/delete. Field-level security controls field visibility/editability. Record sharing determines which records an otherwise authorized user can access. A page layout hides or arranges UI elements; it is not a substitute for field security across APIs and reports.
Profiles provide baseline settings/permissions; permission sets add access. Permission-set groups bundle permissions, and muting removes selected permissions from that group's contribution. Muting does not globally revoke the same permission granted by another source. Prefer understandable least-privilege assignments over many broad overlapping grants.
Organization-wide defaults establish baseline record access. Role hierarchy, sharing rules, teams and manual sharing can open access under supported object rules. Sharing rules generally extend access rather than restrict it. Public groups collect users/roles/groups for sharing; a role is primarily related to record visibility, not the same as a profile's object permissions.
View All/Modify All object permissions and broader administrative permissions can bypass ordinary sharing restrictions. Inspect these when a user sees unexpectedly broad data. Restriction rules, where supported, have a different filtering purpose from sharing rules; do not assume every object supports the same mechanisms.
Reports/dashboard folders control access to those analytical assets, while underlying data and running-user rules control results. Test as a representative user with all actual grants, not only by reading one profile. A user may see a record but not a sensitive field, or see a report definition with fewer rows than its author.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Hide salary through UI, reports and API | Field-level security, not merely layout removal. |
| Open records to a cross-functional group | Appropriate sharing to a public group/team. |
| Grant a small extra capability | A scoped permission set. |
Traps
- Sharing does not grant object CRUD by itself.
- Muting one group does not revoke a permission granted elsewhere.
03 · Relationships, Fields and Lightning Pages
Memory hook: Data structure, business process and screen layout are different layers.
Must remember
Standard objects model common CRM entities; custom objects represent additional business data. Records are rows and fields store attributes/relationships. Lookup relationships provide flexible links; master-detail relationships give tighter lifecycle/ownership behavior, including supported roll-up summaries and cascade implications. A junction object commonly represents many-to-many relationships.
Formula fields calculate derived values; cross-object formulas can reference supported parent relationships. Roll-up summaries aggregate eligible detail records under supported relationships. A formula is not a stored manual input, and a lookup alone does not provide every native master-detail roll-up behavior. Dependent picklists constrain choices using a controlling field.
Record types select available business processes/picklist values and participate in page-layout assignment. A sales/support process defines permitted stages/statuses for its use case. Page layouts arrange fields/actions; Lightning App Builder composes pages and component visibility. Dynamic visibility improves experience but does not replace field/record security.
Object-specific quick actions operate in a record context; global actions can be offered without that specific context. List views provide saved filters and selected columns; sharing a view does not automatically grant access to its underlying records. Schema Builder visualizes objects and relationships but does not validate every business modeling decision.
Before deleting/changing a field, inspect formulas, automation, reports, integrations and stored values. Data-type conversion or relationship changes can lose information or invalidate dependencies. Test in a suitable nonproduction environment and preserve a recovery path before structural changes.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Aggregate detail amounts on a parent | Eligible roll-up summary/master-detail design. |
| Different stage choices for business processes | Record types plus the appropriate process/picklist configuration. |
| Different page composition by context | Lightning App Builder with deliberate activation/visibility. |
Traps
- Record type is not a replacement for access control.
- A page-layout change does not change every API/data behavior.
04 · Leads, Opportunities and Campaigns
Memory hook: A lead is potential; an opportunity is a tracked deal.
Must remember
Leads represent prospects before qualification/conversion. Conversion can create or associate the relevant account/contact and optionally an opportunity according to the supported process. Map custom fields and inspect duplicate rules; conversion is not simply changing a label on the original record.
Opportunities track deals through stages with amount, close date and probability/forecast context. Sales processes and record types constrain stage choices. Path provides guidance and key fields; it does not independently guarantee data quality or prevent every invalid transition.
Lead assignment rules route eligible incoming leads to users/queues when invoked through the supported creation/import path. Check active rule entries, order and default ownership. Campaigns organize marketing efforts, and campaign members represent lead/contact participation with status. A member status is different from an opportunity stage.
Sales productivity tools include activities, dashboards, opportunity teams, forecasting and territory features where available. Forecasts summarize eligible pipeline under configured categories/hierarchy; they are not simply all opportunities added together. Territory management organizes supported account/sales coverage and access, distinct from merely changing a user's role.
Einstein lead/opportunity scoring and related AI features provide signals for prioritization, subject to data, feature and licensing requirements. A high score is not a guaranteed sale. Compare signal quality with actual outcomes and keep required business checks in the process.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Track a qualified sales deal | Opportunity. |
| Route new leads automatically | Lead assignment rules invoked by the relevant entry path. |
| Track a webinar audience and response | Campaign and campaign-member statuses. |
Traps
- Path guidance is not an enforcement rule by itself.
- A forecast category and an opportunity stage serve related but different purposes.
05 · Cases, Queues and Service Automation
Memory hook: Assign the work, acknowledge the customer, escalate the delay.
Must remember
Cases track support issues with status, priority, owner and related customer information. Queues hold supported records for a group to work; assignment rules route cases to the appropriate user/queue. A queue owner does not guarantee a specific agent has accepted or resolved the case.
Support processes define available case statuses, used with record types and layouts to fit different workflows. Capture accurate origin, customer and category data so routing and reporting remain meaningful. Email-to-Case and Web-to-Case are entry channels with their own setup and processing behavior.
Auto-response rules send suitable acknowledgments; escalation rules react to defined timing/criteria and can reassign or notify. These solve different needs from assignment. Business hours and timing choices affect escalation behavior; test weekends, holidays and status transitions rather than assuming elapsed wall-clock time.
Omni-Channel can route eligible work using configured queues/skills, capacity and availability. A service console brings relevant records/tools into an efficient workspace. Knowledge supplies governed reusable answers; article visibility and publication state still matter.
Einstein for Service and Agentforce can assist with classification, recommendations or supported actions, depending on enabled features. Validate permissions, data quality and the fallback to a human. Automation should not silently close a case merely because it generated a plausible response. Measure correct resolution and customer outcome, not just deflection volume.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Send an immediate acknowledgment | Auto-response rule. |
| Route a newly created case | Case assignment rule. |
| Unresolved high-priority case exceeds its threshold | Escalation with correct timing/business hours. |
Traps
- Assignment and auto-response are different rules.
- A queue is not proof that an individual accepted the work.
06 · Activities, Collaboration, Mobile and Packages
Memory hook: Make work visible without widening data access accidentally.
Must remember
Tasks represent to-do work; events reserve a time interval, often with attendees. Activities link to relevant people and business records under their relationship/visibility rules. Ownership, due date, status and shared calendar settings influence how users find work; a missing activity may be a filter or permission issue.
Chatter supports feeds, mentions and groups for collaboration. Public, private and supported external/customer group access differ. Group membership does not automatically override all record permissions. Review audience before posting files or sensitive record details, especially where external users participate.
The Salesforce mobile experience uses configured navigation, supported pages/actions and visibility. Lightning page activation and device/form-factor behavior affect what a user sees. Test with the actual mobile user and permissions rather than assuming the desktop app's entire layout transfers unchanged. Branding changes appearance, not authorization.
AppExchange and AgentExchange help discover eligible packaged applications, components and AI-related offerings. Managed packages support a publisher-controlled lifecycle and upgrades; unmanaged packages generally copy editable components without the same managed upgrade path. Review publisher, installation permissions, dependencies, license and requested access before installation.
Installing a package, prompt or flow does not prove it fits the business process. Test in a suitable environment, review its data/action permissions and establish ownership for updates/removal. Publishing follows the platform's publisher and review requirements; it is not equivalent to exporting arbitrary org metadata publicly.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| A follow-up due next week | Task. |
| A scheduled customer meeting | Event. |
| Adopt vendor-maintained functionality | Evaluate a managed package and its upgrade/access implications. |
Traps
- A private collaboration group does not replace record security.
- A package installation can introduce automation and access that need review.
07 · Imports, Duplicates and Recoverable Data Changes
Memory hook: Match first, validate next, load in a recoverable batch.
Must remember
Choose Data Import Wizard or Data Loader according to supported objects, operation, volume and automation needs. Import Wizard provides guided supported imports; Data Loader supports broader bulk operations and mappings. Confirm current limits rather than assuming one memorized row count applies to every tool/edition.
Insert creates records; update changes matched records; upsert combines those behaviors using a supported match key such as an external ID. Validate key uniqueness, parent references and operation order. A wrong match key can create duplicates or update the wrong customer. Test a small batch and inspect success/error output before a full load.
Matching rules identify potential duplicates; duplicate rules decide the configured response, such as alerting or blocking. Validation rules reject data when their formula evaluates to true. Check how imports/API operations invoke automation and enforcement; bypass assumptions often cause bulk-load surprises.
Plan ownership transfers, mass deletion and archiving with related records and reporting needs in mind. Export/back up before consequential changes and verify that the recovery process includes relationships, metadata needs and a realistic restore procedure. A CSV export is not automatically a complete point-in-time org restoration.
Use consistent date/time, locale and currency handling. Protect exported personal/customer data and restrict access to error files that contain rejected record values. Reconcile counts, totals and sampled relationships after the operation. A successful job status can coexist with partially failed rows.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Create new or update existing external records | Upsert with a validated external identifier. |
| Detect likely duplicate customers | Matching rule plus an appropriate duplicate-rule response. |
| Prevent an invalid business value | Validation rule with tested error behavior. |
Traps
- Validation rules block when the error condition is true.
- Bulk job completion does not mean every record succeeded.
08 · Reports, Dashboards and Analytical Visibility
Memory hook: The report defines the rows; the viewer context defines access.
Must remember
A report type defines available objects, relationships and fields. An object relationship configured as with or without related records changes which parent rows can appear. Report filters, cross filters, groupings and field permissions then shape the result. A missing field can arise from report-type configuration or security, not only the page layout.
Tabular reports list rows; summary reports group; matrix reports group on rows and columns; joined reports combine supported report blocks. Row-level and summary formulas operate at different grains. Buckets group values without changing source records. Charts require appropriate report structure, and hiding details changes presentation rather than necessarily changing totals.
Folders control access to reports/dashboards. Underlying record and field permissions still affect reports. A dashboard's running-user configuration matters: a fixed running user can expose summarized results from that identity's access, while a dynamic dashboard runs in the viewing user's context under supported rules. Review this before sharing sensitive metrics.
Dashboard components use source reports and suitable chart/table/metric forms. Filters apply only where compatible fields/configuration support them. Refresh and subscription behavior, schedules and dynamic-dashboard limits depend on edition/configuration. A dashboard is not automatically live after source data changes.
When totals differ, check source freshness, report type, filters, date ranges, grouping, currency and user context. Distinguish unique records from duplicated related-detail rows. Validate representative users and known records before using a report as a business decision or AI grounding source.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Need parents even without child records | A suitable with-or-without report-type relationship. |
| Each viewer should see their own authorized dashboard results | A supported dynamic dashboard design. |
| Group values without editing source data | Bucket field. |
Traps
- Folder access does not grant all underlying data permissions.
- A fixed running user can make dashboard results broader than a viewer’s ordinary report access.
09 · Flow, Approvals and Automation Choice
Memory hook: Choose the trigger, context and transaction before drawing the flow.
Must remember
Screen flows guide users through interaction; record-triggered flows respond to record changes; autolaunched flows run without screens through supported invocation. Scheduled mechanisms address time-based work. Choose the simplest supported automation matching the requirement, including specialized assignment/escalation rules where appropriate.
Before-save record-triggered flows suit efficient updates to the triggering record under supported operations. After-save flows can perform broader related work/actions. Entry criteria and when-to-run settings limit unnecessary execution. Order of execution determines interactions with validation, other automation and record updates; a flow that re-updates its own trigger can cause recursion or repeated effects.
Use Get Records, decisions, assignments, collections and loops deliberately. Avoid database operations inside large loops when a collection operation can do the work, and account for transaction limits. Fault paths should capture useful nonsecret context and route failures to an owner. Debugging one successful record is not a bulk or security test.
Flow execution context affects sharing/object/field enforcement; inspect the flow type, launch mechanism and configured context rather than assuming every flow always behaves like the clicking user. The default automation user and agent/integration identities matter for background actions and ownership.
Approval processes route submissions according to entry criteria and approver selection, with approval/rejection actions and record-locking implications. A notification is not an approval decision. Test rejection, recall/resubmission and missing approver cases. Version, test and activate changes deliberately; creating a new draft does not make it the active production flow.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Guide a user through several inputs | Screen flow. |
| Set fields on the triggering record efficiently | An eligible before-save record-triggered flow. |
| Require a manager’s decision before final action | Approval process with clear criteria and outcomes. |
Traps
- A draft flow version is not automatically active.
- A screen does not guarantee every downstream action runs with the user’s exact permissions.
10 · Agentforce, Grounding and Permission Troubleshooting
Memory hook: The agent can only be useful if its data and actions are trustworthy.
Must remember
Agentforce supports AI agents that interpret requests, use configured subagents/instructions (called topics in older material) and invoke allowed actions. Good use cases have a clear outcome, reliable accessible data, bounded actions and a human fallback. A deterministic calculation or approval rule may be better handled by ordinary automation than an open-ended language-model decision.
Grounding supplies relevant trusted business context. Poor or inaccessible records can produce weak answers even with a well-written prompt. Separate an agent's instructions from data it reads; customer text or documents can contain misleading instructions and must not override authorized behavior.
Actions can depend on Flow, Apex or other supported integrations, with their own permissions and execution context. Troubleshoot the complete chain: user/agent identity, license/feature access, subagent/action availability, object/field/record access, flow permission/context and external connection. Broad administrator access may hide the original defect and create unnecessary risk.
Agent Builder supports maintaining instructions/prompts and testing conversations in the available experience. Preview ordinary, ambiguous, unauthorized and failure scenarios in a sandbox: testing can execute actions and consume usage credits. Check the actual records/actions used and the resulting side effects, not only the wording of the response. A plausible sentence saying an update succeeded is not proof that it did.
Version and test changes before deployment, including installed reusable prompts/actions from trusted sources. Define handoff and approval for consequential operations. Monitor quality, incorrect responses, denied actions and unexpected data access. AI suitability depends on business risk and evidence, not on whether a feature can be enabled with a toggle.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Fixed field calculation with exact behavior | Formula/Flow rather than unnecessary generative reasoning. |
| Agent cannot update a record | Inspect its identity and the entire action/data permission chain. |
| Change agent instructions | Version, preview representative conversations and verify actual outcomes. |
Traps
- A good prompt cannot grant missing data access.
- A confident response is not evidence that an action completed.