Platform App Builder
The Salesforce Certified Platform App Builder exam is designed for people who build and deploy custom applications on the Salesforce Platform using declarative, point-and-click tools. It covers the full lifecycle of an app: the data and object model, application security, business logic and process automation, the user interface, and deployment. Salesforce expects candidates to have 6 months to 1 year of experience building applications on the Customer 360 platform or a similar technology platform, along with an awareness of Salesforce license types and their implications. The certification suits experienced administrators, declarative app builders, business analysts, and architects, and it is also relevant to developers and analysts who work alongside them.
Key facts
This guide will explain everything that test takers need to think about how to become a Platform App Builder-certified and the core topics of the exam.
There are 5 areas of knowledge covered by the Salesforce Certified Platform App Builder certification.
Data table
| Objective | Weighting |
|---|---|
| App Deployment | 13% |
| User Interface | 17% |
| Data Modeling and Management | 20% |
| Salesforce Fundamentals | 18% |
| Business Logic and Process Automation | 32% |
Platform App Builder Weighting Chart
Platform App Builder certification contents
The following are the core topic areas of the Platform App Builder certification and what candidates are expected to know:
Salesforce fundamentals
This topic includes the following objectives:
Given a scenario, identify where declarative customization ends and programmatic customization is needed.
Every App Builder scenario starts with the same question: can this be built with clicks? Candidates need to recognize the point at which declarative tools run out, such as logic too complex for a formula or flow, a user interface that standard components cannot produce, or an integration that needs code. They should also weigh the trade-off, since declarative solutions are usually faster to build and easier to maintain through releases.
Identify common scenarios for extending an org using AgentExchange.
AgentExchange is the Salesforce marketplace for Agentforce, built on the same model as AppExchange. It offers partner-built actions, prompt templates, topics, and agent templates that can be installed and configured rather than built from scratch, and they can be browsed on the marketplace or from within Agent Builder. Candidates should recognize when an off-the-shelf component is the quicker route to a working agent.
Apply the features available to restrict and extend object, record, and field access.
Access in Salesforce is layered. Profiles and permission sets grant object and field permissions, organization-wide defaults set the baseline for record access, and the role hierarchy, sharing rules, and manual sharing open access up from there. Candidates should be able to follow a requirement through each layer and identify which setting solves it.
Given a set of business requirements, determine the right sharing solution.
Sharing questions reward the least permissive option that still meets the requirement. Candidates should be able to compare the role hierarchy, ownership-based and criteria-based sharing rules, manual sharing, and team access, and to predict how child records behave under master-detail and lookup relationships.
Identify the features available when creating reports, report types, and dashboards.
Reporting requirements shape the data model as much as the model shapes reporting. Candidates should know what standard and custom report types make available, how joined reports and features such as bucket fields and cross filters work, and how dashboard components draw on a source report and a running user.
Data modeling and management
This topic includes the following objectives:
Given a scenario, determine the appropriate data model.
Scenario questions describe a business need and expect the right mix of standard objects, custom objects, and fields. Candidates should know when a standard object fits, when a custom object is justified, and how the decision affects licensing, reporting, and the effort of future change.
Given a scenario, explain the capabilities of each relationship type and what each one means for record access, the user interface, and reporting.
Master-detail, lookup, hierarchical, and many-to-many relationships built through a junction object each behave differently. Master-detail ties ownership and sharing to the parent, supports roll-up summary fields, and cascades deletes. Lookups are looser and can be optional. Candidates should be able to predict the effect of each choice on access, page layouts, and what can be reported on.
Given a scenario, determine the considerations when selecting or changing a field data type.
Data type decisions are difficult to reverse. Candidates should know which conversions are allowed, what data is at risk when a type changes, and the knock-on effects on formulas, validation rules, page layouts, and integrations that reference the field. Picklists, text fields, and external IDs each carry their own constraints.
Given a scenario, determine the options and considerations for importing and exporting data, including the capabilities of external data sources.
Data can be loaded with the Data Import Wizard, Data Loader, or the API, each with its own limits on volume and supported objects. Candidates should also know when data does not need to be copied at all and can stay in an external system, surfaced through external objects and Salesforce Connect.
Business logic and process automation
This topic includes the following objectives:
Given a scenario, use formula fields to meet stated business requirements.
Formula fields calculate when a record is read and store no data. Candidates should be comfortable with common functions, cross-object formulas that reach up a relationship, and the limits, including where formula fields cannot be used and the size limits that long formulas run into.
Given a scenario, determine the capabilities, use cases, and implications of roll-up summary fields.
A roll-up summary counts child records or returns a sum, minimum, or maximum from a field on them, and it requires a master-detail relationship. Filters narrow which child records are included. Candidates should know when a roll-up is not available, such as across a lookup relationship, and which alternatives cover the gap.
Given a scenario, use validation rules to meet stated business requirements.
A validation rule blocks the save when its formula evaluates to true and returns an error at a field or at the top of the page. Candidates should be able to translate a requirement into a condition, account for record types and the context the record is saved in, and understand where validation sits in the order of execution alongside other automation.
Create and configure flows using Flow Builder.
Flow Builder is the automation tool the exam concentrates on, following the retirement of Workflow Rules and Process Builder. Candidates should be comfortable with variables, assignments, decisions, loops, the elements that get, create, update, and delete records, screens, and the entry conditions and settings that control when a flow runs.
Describe the capabilities and use cases for Flow approval processes.
Approvals route a record for review, lock it while it waits, and trigger actions on approval, rejection, or recall. The exam guide now refers to approvals in the context of Flow, in line with the move of approvals into Flow Builder. Candidates should know how submission criteria, approvers and delegated approvers, record locking, and step actions fit together.
Given a scenario, determine the appropriate flow type for the stated business requirement.
Flow types differ by how they start and the context they run in. Screen flows guide a user through a task. Record-triggered flows run before or after a record is saved, and the before-save option is the lighter choice for updating the same record. Scheduled flows process batches of records, autolaunched flows are called from elsewhere, and platform event-triggered flows respond to integrations.
Maintain, monitor, and troubleshoot flows.
Flows need attention after go-live. Candidates should know how to debug a flow in Flow Builder, interpret flow error emails, review paused and failed interviews, manage versions and activation, and use flow tests to confirm behavior before a change is released.
Describe the capabilities and use cases for using Agentforce to automate business processes.
An Agentforce agent works from topics, instructions, and actions, and those actions can include flows, prompt templates, and Apex. Candidates should be able to say when an agent is a better fit than a traditional automation and how an existing flow becomes an action an agent can call.
User interface
This topic includes the following objectives:
Describe the user interface customization options.
Lightning App Builder assembles record pages, home pages, and app pages from standard and custom components. Around it sit page layouts, compact layouts, record types, dynamic forms and dynamic actions, list views, and custom apps. Candidates should be able to match a requirement to the simplest option that delivers it.
Demonstrate the capabilities and use cases for custom buttons, links, and actions.
Quick actions create records, update fields, log a call, or launch a flow, and they come in global and object-specific forms. Custom buttons and links can open a URL or a Visualforce page. Candidates should know where each one can be placed, and which options are available in Lightning Experience and in the mobile app.
Given a scenario, determine the declarative options for including Lightning components in an application.
Admins add standard and custom components to Lightning pages in App Builder, set component visibility rules so a component appears only in the right conditions, and assign pages by app, record type, or profile. Candidates should know what can be achieved through configuration alone.
Describe the programmatic customizations available for including custom Lightning components in an application.
Where the standard component library falls short, a developer builds a Lightning Web Component or an Aura component. App Builders are not expected to write them, but they should know what makes a component available in App Builder, Experience Builder, or a quick action, and be able to scope that work with a developer.
Given a set of requirements, determine the appropriate global actions, object-specific actions, and layouts for the Salesforce mobile experience.
Global actions are available from anywhere and are not tied to a record. Object-specific actions run in the context of a record and can pre-populate fields from it. Compact layouts control the fields shown in the record highlights on a phone. Candidates should be able to assemble these into a mobile experience that keeps the most useful actions within reach.
App deployment
This topic includes the following objectives:
Given a set of business requirements, recommend a solution for managing the application lifecycle, including sandbox types.
Developer, Developer Pro, Partial Copy, and Full sandboxes differ in storage, refresh interval, and how much data they copy. Candidates should match the sandbox to the purpose, such as a Full sandbox for user acceptance testing with production-like data, and know the refresh limits that shape a release schedule.
Given a use case, demonstrate knowledge, viability, and troubleshooting when using change sets.
Change sets move metadata between connected orgs. Candidates should know the outbound and inbound steps, the deployment connection that has to be in place first, the dependent components that must travel with a change, the fact that change sets cannot delete components, and how a validation deployment followed by a quick deploy reduces risk.
Describe the use cases and considerations when using unmanaged and managed packages.
An unmanaged package delivers a copy of components that the subscriber owns and can edit, with no upgrade path. A managed package stays under the publisher’s control, uses a namespace, and can be upgraded in place. Candidates should know which fits distribution by an ISV and which fits a one-time transfer of components.
Given a scenario, determine the appropriate deployment plan.
A deployment plan is more than a tool choice. It covers what moves first, which settings have to be configured by hand in the target org, how the release is tested, and what happens if it has to be rolled back. Candidates should be able to weigh change sets, packages, and metadata-based tooling against the size and risk of the release.
