Overview
Salesforce Fundamentals is the opening section of the Platform App Builder exam guide, and since the Summer '26 content update that went live on 21 August 2026 it carries 18% of the score, down from 23% in the previous guide. It has five objectives: knowing where declarative customization stops and code begins, spotting when an AgentExchange solution beats building your own, applying the features that restrict or extend object, record and field access, choosing a sharing solution, and using reports, report types and dashboards.
The common thread is judgment about the platform itself. An app builder is expected to reach for the standard feature first, know the security model well enough to open access without exposing data, and prove the app works by reporting on it. The mobile actions objective that used to sit here now belongs to User Interface, and the exam no longer has a separate Chatter objective.
How it's tested
Most questions are scenarios that describe a business need and ask for the most appropriate or least effort solution. Security items list several features that all sound like they control visibility, and only one acts at the right layer. Report items test which report format, report type or dashboard component fits a stated question.
-
Which layer controls this
A user can or cannot see an object, a field or a specific record, and you pick profile or permission set, field-level security, org-wide default or a sharing rule.
-
Build, buy or code
A requirement is described and you decide between standard configuration, an AgentExchange package, or programmatic work such as Apex or a Lightning web component.
-
Report the answer
A manager wants a grouped, filtered or cross-object view, and you choose report format, custom report type, bucket field, or dashboard component and running user.
A scenario says support agents can read all cases but must not see a Credit_Score__c field on Contact, and only finance users can edit it. Hiding the field from the page layout leaves it reachable through reports and list views, so it is the wrong control. Field-level security removes the field everywhere for agents, and a permission set grants edit access to finance, so that combination is correct.
Objectives 5
Official objectives from the Salesforce outline, in outline order.
1.1 Given a scenario, identify the boundaries of declarative customization and the use cases for programmatic customization.When clicks are enough and when Apex or Lightning web components are needed.
- What it means
- Declarative customization means building with Setup tools such as custom objects, formula fields, validation rules, Flow Builder and Lightning App Builder. Programmatic customization means Apex, Lightning web components, Visualforce and APIs. Salesforce recommends the declarative option whenever it fully meets the requirement, because admins can maintain it and it needs no test coverage.
- What to understand
- Know the edges that push you to code: complex logic that Flow cannot express cleanly, highly custom user interfaces, heavy integration patterns, and operations that would exceed flow limits on large data volumes. Know also that many old reasons for code have gone: roll-up summaries, record-triggered flows, screen flows and Dynamic Forms now cover requirements that once needed triggers or Visualforce.
- How it shows up
- Look for the phrase least amount of custom code or most maintainable; the right answer is the declarative tool that fully satisfies the requirement.
- Common confusion
- Picking Apex because it can do the job, when a flow or formula meets every stated requirement with less maintenance.
1.2 Identify common scenarios for extending an org using the AgentExchange.Using Salesforce's marketplace for apps, components and agents instead of building.
- What it means
- AgentExchange is the Salesforce marketplace for partner apps, Lightning components, flow solutions and Agentforce agents and actions. Installing a listing adds packaged metadata to your org, often as a managed package whose code the publisher maintains and upgrades. It is the build-versus-buy option in an app builder's toolkit.
- What to understand
- Recognize the scenarios where installing beats building: a common need such as e-signature, document generation or mapping, a short timeline, or a requirement for features the team lacks skills to build. Know the checks before installing: security review status, the editions and licenses the package needs, reviews, and testing in a sandbox first. Managed package components cannot be edited, though you can usually extend them with your own fields or flows.
- How it shows up
- A scenario describes a widely needed capability with a tight deadline; the expected answer is to evaluate and install an AgentExchange solution, tested in a sandbox.
- Common confusion
- Assuming an installed managed package can be modified freely like your own metadata.
1.3 Apply features and capabilities available to restrict and extend object, record, and field access.Profiles, permission sets, field-level security, org-wide defaults and record access tools.
- What it means
- Salesforce security is layered. Object permissions (create, read, edit, delete, view all, modify all) come from profiles, permission sets and permission set groups. Field-level security decides which fields a user can see or edit. Record access starts from org-wide defaults and is opened with the role hierarchy, sharing rules, teams and manual sharing. A user needs every layer to line up before they can work with a record.
- What to understand
- Know that org-wide defaults set the most restrictive baseline and everything else only opens access. Know that permission sets add permissions and that permission set groups bundle them, with muting permission sets able to remove permissions inside a group. Restriction rules can narrow which records a user sees even when sharing would allow more. Page layouts change what is displayed, not what is secured.
- How it shows up
- Questions describe who should see or edit what and ask which feature delivers it with the fewest changes, often contrasting profiles, permission sets and field-level security.
- Common confusion
- Removing a field from a page layout and calling it secure, when field-level security is the real control.
1.4 Given a set of business requirements, determine the appropriate sharing solution.Choosing between OWD, role hierarchy, sharing rules, teams and manual sharing.
- What it means
- Once the baseline is Private or Public Read Only, record access is extended with sharing tools. The role hierarchy gives managers access to their subordinates' records. Owner-based and criteria-based sharing rules open records to groups, roles or territories. Account, opportunity and case teams share individual records with collaborators, and manual sharing lets owners share one record at a time.
- What to understand
- Match the requirement to the scope: a whole group needs access to records meeting a condition, so use a criteria-based sharing rule; one deal needs a specialist, so use an opportunity team. Know that Grant Access Using Hierarchies can be turned off for custom objects only, and that sharing never takes away access granted elsewhere. Know where master-detail children inherit sharing and cannot have their own sharing rules.
- How it shows up
- A scenario sets the org-wide default and describes who else needs access; you choose the narrowest sharing tool that meets it.
- Common confusion
- Trying to use a sharing rule to restrict access below the org-wide default, which sharing cannot do.
1.5 Identify the features and capabilities available when creating reports, report types, and dashboards.Report formats, custom report types, bucket fields and dashboard components.
- What it means
- Reports come in tabular, summary, matrix and joined formats and draw their fields from a report type, which defines the primary object and related objects. Custom report types let you choose object relationships, including with or without related records. Dashboards display source reports through components such as charts, gauges, metrics and tables, run as a chosen user or as the viewer.
- What to understand
- Know which feature solves which problem: bucket fields group values without a formula field, row-level and summary formulas calculate inside a report, cross filters find records with or without related records, and a custom report type is needed when no standard type joins the objects you want. Know that a dashboard running as a fixed user shows that user's data to everyone, while dynamic dashboards show each viewer their own data.
- How it shows up
- Scenarios ask how to show records without related children, group values into ranges, or let each manager see only their team on one dashboard.
- Common confusion
- Building a new formula field on the object when a bucket field or report formula would answer the question inside the report.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Org-wide default (OWD)
The baseline record access for each object, such as Private, Public Read Only or Public Read/Write.
- Remember
- Set OWD to the most restrictive level any user needs, then open access with sharing.
- Tested as
- Almost every sharing scenario starts by checking the OWD.
- Trap
- Setting a permissive OWD and then trying to restrict some users with sharing rules.
-
Permission set group
A bundle of permission sets assigned together, optionally with a muting permission set.
- Remember
- Muting removes permissions only within that group, not from the user's profile.
- Tested as
- Shows up when access must be granted by job function rather than by profile.
- Trap
- Thinking muting can take away a permission the profile itself grants.
-
Field-level security
Visible and read-only settings per field, granted through profiles and permission sets.
- Remember
- It applies everywhere: pages, reports, list views, search and the API.
- Tested as
- The right answer whenever a field must be truly hidden or locked.
- Trap
- Using page layout read-only, which users can bypass through other channels.
-
Criteria-based sharing rule
Shares records whose field values match a condition with a group, role or territory.
- Remember
- It cannot use formula fields or reduce access below the OWD.
- Tested as
- Used when access depends on a record attribute, not on who owns it.
- Trap
- Choosing an owner-based rule when the scenario mentions a field value such as region or type.
-
Role hierarchy
Gives users access to records owned by people below them in the hierarchy.
- Remember
- It reflects reporting lines for data access, not the org chart literally.
- Tested as
- Questions about managers seeing their team's records point here.
- Trap
- Assuming the role hierarchy controls object or field permissions.
-
Restriction rule
Limits which records a user can see, even when sharing would grant access.
- Remember
- It filters visibility rather than adding access, and only certain objects support it.
- Tested as
- Appears when a team must see only a subset of records they would otherwise reach.
- Trap
- Confusing it with a sharing rule, which only ever opens access.
-
Custom report type
Defines a primary object, related objects and the with or without relationship used in reports.
- Remember
- Choose with or without related records at design time; you cannot change it later.
- Tested as
- Needed for reports such as accounts without opportunities or custom object combinations.
- Trap
- Trying to add an unrelated object to a standard report type.
-
Bucket field
Groups report values into categories or ranges without creating a field on the object.
- Remember
- It lives in the report only, and works on picklist, text and number fields.
- Tested as
- The low-effort answer for grouping values like deal size bands.
- Trap
- Creating a formula field on the object to achieve the same grouping.
-
Dynamic dashboard
A dashboard that runs as the logged-in viewer so each person sees their own data.
- Remember
- Editions cap how many dynamic dashboards you can have.
- Tested as
- Used when many managers need one dashboard showing only their records.
- Trap
- Cloning a dashboard per manager with a fixed running user.
-
AgentExchange
Salesforce's marketplace for apps, components and Agentforce agents.
- Remember
- Check security review, licensing and test in a sandbox before production.
- Tested as
- The build-or-buy objective now names AgentExchange explicitly.
- Trap
- Assuming managed package code can be edited after install.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Hiding data from users
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Object permissions | Create, read, edit and delete rights on a whole object. | Controls whether a user can use the object at all. | Trying to use them to hide specific records. |
| Field-level security | Visibility and edit rights on each field. | Secures the field in every channel, including reports and API. | Replacing it with a page layout change. |
| Page layout | Arrangement and required or read-only display of fields on a page. | Affects only the record page user interface, not data security. | Calling a layout change a security control. |
| Org-wide default | Baseline access to records you do not own. | Sets record-level, not field-level, visibility. | Using a public OWD and expecting sharing rules to restrict it. |
Extending record access
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Owner-based sharing rule | Shares records owned by one group with another group. | Based on who owns the record. | Using it when access depends on a field value. |
| Criteria-based sharing rule | Shares records that meet field criteria. | Based on record data, not owner. | Expecting it to evaluate formula fields. |
| Team (account, opportunity, case) | Adds named users with set access to one record. | Record by record, managed by owners or admins. | Using a sharing rule for a one-off collaborator. |
| Manual sharing | Owner shares a single record with a user or group. | Ad hoc and removed if ownership changes. | Relying on it for repeatable business rules. |
Report and dashboard choices
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Summary report | Groups rows with subtotals. | Needed for most chart components. | Expecting a tabular report to drive a grouped chart. |
| Matrix report | Groups by rows and columns. | Shows two dimensions at once. | Using it when a single grouping is enough. |
| Joined report | Combines blocks from different report types. | Lets you compare separate object views side by side. | Assuming blocks share filters automatically. |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Layout hides the field
- What candidates pick
- Remove the field from the page layout.
- Why it looks right
- It is quick and the user no longer sees it on the record.
- Why it's wrong
- The field is still visible in reports, list views, search and the API, so the data is not secured.
Clue to watch for The scenario says users must not be able to see the value anywhere.
-
Sharing rule to restrict
- What candidates pick
- Create a sharing rule that limits a group's access.
- Why it looks right
- Sharing rules sound like the general tool for record access.
- Why it's wrong
- Sharing rules only open access above the org-wide default; they never remove access already granted.
Clue to watch for Words like prevent or restrict combined with a Public Read/Write default.
-
New profile per tweak
- What candidates pick
- Clone a profile for a small group needing one extra permission.
- Why it looks right
- Profiles feel like the place permissions live.
- Why it's wrong
- A permission set or permission set group adds the permission without multiplying profiles to maintain.
Clue to watch for Only a subset of users with the same profile need extra access.
-
Code for a common need
- What candidates pick
- Build a custom e-signature integration in Apex.
- Why it looks right
- It gives full control over the feature.
- Why it's wrong
- An existing AgentExchange solution is usually faster and maintained by the publisher.
Clue to watch for The scenario stresses a short timeline and a widely available capability.
-
One dashboard per manager
- What candidates pick
- Clone the dashboard and set a different running user for each manager.
- Why it looks right
- It does show each manager their own team.
- Why it's wrong
- A dynamic dashboard running as the logged-in user does the same with one dashboard to maintain.
Clue to watch for Many managers need the same layout filtered to their own records.
-
Wrong report type
- What candidates pick
- Use the standard Accounts with Opportunities report type to find accounts with no opportunities.
- Why it looks right
- It already joins the two objects.
- Why it's wrong
- That standard type only returns accounts that have opportunities; a custom report type with or without, or a cross filter, is needed.
Clue to watch for The requirement says without related records.
Answer framework
Use this sequence for any access, build-or-buy, or reporting scenario in this section.
- Identify what is being asked about: a whole object, a field, a set of records, a marketplace solution, or a report output, because each maps to a different feature.
- Check the baseline first, such as the org-wide default or profile, and decide whether the requirement opens access or restricts it.
- For access, pick the narrowest tool that meets the need: permission set for permissions, field-level security for fields, sharing rule or team for records.
- For new capability, ask whether standard configuration or an AgentExchange listing meets it before considering Apex or custom components.
- For reporting, confirm a report type exposes the needed objects, then choose format, grouping, bucket or formula, and dashboard running user.
Practice question
Want more like this? The Platform App Builder practice test has questions for every domain.
Checklist
0 of 14
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with security because it carries the most questions in this section and the most traps. In a Developer Edition or Trailhead Playground, create two test users on the same profile, set a custom object to Private, then open access step by step: role hierarchy, an owner-based rule, a criteria-based rule, a team member, and a manual share. Log in as each user after every change. Then hide a field with field-level security and compare it with removing the field from the layout, checking a report and list view as the restricted user.
Next, spend an evening on reports. Build each of the four formats, a custom report type with and without related records, a bucket field and a cross filter, then put them on a dashboard and switch the running user. Finish by browsing AgentExchange listings to see how security review, editions and package types are described, and write three short notes on requirements that would genuinely need Apex or a Lightning web component. Re-read the five objectives at the end and answer each one aloud in two sentences without notes.
FAQ
How much of the Platform App Builder exam is Salesforce Fundamentals?
Salesforce Fundamentals is 18% of the exam under the Summer '26 guide, about 11 of the 60 scored questions. It was 23% before the August 2026 update.
Did the Summer '26 update change the passing score?
Yes. The current exam guide lists a 73% passing score. Older guides and many third-party pages still quote 63%, which no longer applies.
Is AgentExchange the same as AppExchange?
AgentExchange is the name the current exam guide uses for the Salesforce marketplace that offers apps, components and Agentforce agents and actions. Treat questions about extending an org with marketplace listings as this objective.
Are mobile actions still in Salesforce Fundamentals?
No. The objective on global and object-specific actions and mobile layouts now sits in the User Interface section of the current guide.
Do I need to know Apex for this section?
You need to recognize when a requirement calls for Apex or a Lightning web component, not to write code. Questions test the boundary between declarative and programmatic options.
Which security feature is tested most?
Expect frequent questions on org-wide defaults, sharing rules and field-level security, often comparing them with page layouts or profiles. Practice deciding which layer each requirement touches.
Are Chatter questions still on the exam?
The current guide does not list a Chatter objective. Spend that time on sharing, permission sets and reporting instead.
Other CRM & Business Applications certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
- HubSpot Inbound Marketing Certification Study guide
- Salesforce Certified Platform Developer I Study guide
- Google Ads Search Certification Study guide
- ServiceNow Certified System Administrator Study guide
- Salesforce Certified Platform Administrator Study guide
- ServiceNow Certified Application Developer Study guide
Test your Domain 1 knowledge
Try practice questions on sharing rules, field-level security, AgentExchange and report types to check that you can pick the right layer under time pressure.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the Platform App Builder AI tutor Get any concept explained your way