The Salesforce Certified Platform App Builder proves something narrower and deeper than the Administrator credential: that you can design, build, and deploy custom applications on the Salesforce Lightning Platform using declarative tools, clicks not code. Where the Administrator runs an org day to day, the App Builder extends it, modelling data, automating business processes with Flow, assembling Lightning apps and pages, and moving that work safely from a sandbox to production. The exam is practical in spirit and concentrated on building. This guide is a full, self-study course. It walks through all five domains in the proportion the exam tests them, teaches data modelling and Flow automation in depth because they carry the most weight, and turns everything into a study plan and an exam-day routine. It is original teaching material and study guidance only. It contains no real or simulated exam questions, and you should confirm the current domains, weights, and pass mark on the official Platform App Builder exam guide before you book, because Salesforce restructures its exams from time to time.
Chapter 1: Exam overview and how to use this guide
What the exam measures, and the five domains
The Platform App Builder exam measures whether you can build custom apps declaratively across the full workflow: model the data, add the logic, build the interface, and deploy. Salesforce organises it into five domains with official weightings, and those weightings are the most important planning fact in this guide. They are: Salesforce Fundamentals (23%), Data Modeling and Management (22%), Business Logic and Process Automation (28%), User Interface (17%), and App Deployment (10%). The single largest domain is Business Logic and Process Automation at 28%, which is dominated by Flow, followed closely by Fundamentals and Data Modeling. Together, data modelling and business logic, the data layer and the logic that acts on it, make up half the exam, so that is where the depth of your study belongs.
A restructure you must know about
One change matters before you study. Salesforce restructured this exam in December 2025, consolidating an earlier nine-section outline (which separately covered areas such as security, social, mobile, and reporting) into the current five weighted sections listed above. The practical consequence is that older nine-section study material is out of date; the grouping and the weightings have changed, so you must work from the current five-domain exam guide. If a resource still splits the exam into eight or nine areas, it predates this update.
Format and how certifications stay current
The exam runs 105 minutes and contains 60 scored questions plus 5 unscored questions (65 in total), in multiple-choice and multiple-select formats, proctored through Pearson VUE at a test centre or online. The pass mark is 63%; only the 60 scored questions count toward your result, and the 5 unscored ones do not. As with other Salesforce credentials, there is no fixed expiry date: you keep this one active by completing the free Trailhead maintenance module Salesforce releases with each platform update, and missing the deadline can make the credential inactive, so watch your Trailhead dashboard.
How to use this course, and the habit that matters most
Read the chapters in order; the data model in Chapter 3 is assumed by the automation in Chapter 4, and deployment in Chapter 6 only makes sense once you have something to deploy. The bold terms are your checklist. The single most valuable study habit is to build everything in a free Developer Edition org: create custom objects and relationships, write formula and roll-up summary fields, build several flows, assemble a Lightning app, and run a change set. Doing the work matters far more than reading about it for this exam, because the questions are about building. A short worked example appears where an idea is easy to misread, but none of these are exam questions. They are teaching illustrations. One framing runs through the whole guide: App Builder is the clicks-not-code credential, so when a scenario could be solved declaratively, the declarative answer is almost always the intended one; Apex and Lightning Web Components belong to the Platform Developer track, not here.
Chapter 2: Salesforce Fundamentals (23%)
This domain sets the platform context and, crucially, the recurring judgement that runs through the whole exam: when to solve a requirement with configuration and when it genuinely needs code.
The platform and the multi-tenant model
The exam expects a working understanding of the Lightning Platform as a low-code platform for building apps, and of the multi-tenant model, the idea that many customers (“tenants”) share the same underlying Salesforce infrastructure while their data and configuration stay isolated from one another. The practical consequence a builder must respect is that the platform enforces limits and shared-resource boundaries, which is part of why declarative tools and governor limits exist. You do not need deep architecture knowledge, but you should grasp that you are building on a shared, managed platform rather than a server you control outright.
Apps, tabs, and the AppExchange
The building blocks of what users navigate are apps (collections of tabs and items grouped for a set of users) and tabs (navigation entries that expose an object, page, or web content). The exam also covers the AppExchange, Salesforce’s marketplace of installable apps and components, and expects you to know that you can extend an org by installing a packaged solution rather than building everything yourself. Build a simple custom app with tabs in a Developer Edition org so these concepts are concrete.
Declarative versus programmatic, the exam’s central judgement
The most important idea in this domain, and a theme the exam returns to across every other domain, is the choice between declarative (point-and-click configuration) and programmatic (code: Apex, Lightning Web Components) solutions. The App Builder philosophy, and the answer the exam rewards, is to solve with declarative tools wherever they can do the job, reaching for code only when a requirement genuinely exceeds what configuration can achieve. As a teaching example of the judgement: a requirement to validate data on save, calculate a value from other fields, or automate a record update when something changes is declarative work (validation rule, formula field, Flow); a requirement for complex transaction logic across many records with custom error handling may need Apex. Recognising which side of that line a requirement falls on is exactly what these questions test, and the default lean is declarative.
Chapter 3: Data Modeling and Management (22%)
This domain is the data layer, and it is where careful, correct design is rewarded. Half the exam rests on data modelling and the logic built on top of it, so this chapter deserves real attention and hands-on practice.
Objects, fields, and field types
A data model is built from standard objects (built-in, such as Account, Contact, Opportunity) and custom objects (which you create for business-specific data), each holding fields whose field type determines what they can store (text, number, date, picklist, and so on). The exam expects you to choose appropriate field types and to design a sensible schema, an object structure that reflects the real-world things and relationships a business needs to track.
Relationships: lookup, master-detail, and junction
The heart of this domain is relationships, and the distinctions are tested precisely. A lookup relationship is a loose link between two objects: the child can exist without the parent, and deleting the parent does not delete the child. A master-detail relationship is a tight parent-child link: the detail record is owned by the master, deleting the master cascades to delete the details, the detail inherits sharing and security from the master, and, importantly, only master-detail enables roll-up summary fields on the parent. A junction object is a custom object with two master-detail relationships, and it is how you model a many-to-many relationship (for example, linking students to classes, where each student has many classes and each class has many students). The exam probes lookup versus master-detail constantly, so anchor it: master-detail gives cascade delete, inherited sharing, and roll-up summaries; lookup gives none of those, and a junction object is two master-details combined.
Formula fields and roll-up summary fields
Two calculated field types are essential and frequently confused. A formula field is read-only and calculated per record at read time from other fields on (or related to) that record, for example combining a first and last name, or flagging a record based on a condition. A roll-up summary field sits on a master-detail parent and aggregates child records using COUNT, SUM, MIN, or MAX, for example totalling the value of all line items on an order. The distinction the exam tests: a formula works within a single record’s data, while a roll-up summary aggregates many child records up to a parent, and crucially requires a master-detail relationship. As a teaching example: calculating an order’s grand total from its line items is a roll-up summary (parent aggregating children over a master-detail link); calculating a single contact’s full name from two fields is a formula field. Build both yourself so the difference is muscle memory rather than something you reason out under pressure.
Chapter 4: Business Logic and Process Automation (28%)
This is the largest domain, and Flow has the steepest learning curve of anything on the exam, so it deserves the most study time and the most hands-on building. It covers declarative business logic and process automation.
Validation rules and declarative business logic
At the simplest level, business logic includes validation rules, which enforce data quality by blocking a save when data does not meet a condition, for example requiring a reason field whenever a record is set to a certain status. Validation rules are declarative logic at the point of data entry, and the exam expects you to know when one is the right tool: when you need to guarantee data meets a rule before it is saved.
Flow and its types
The dominant tool in this domain is Flow, Salesforce’s declarative automation engine, and the exam tests recognising the flow types and matching each to a requirement. A screen flow guides a user through input screens to collect or display data, used when a person must interact, such as a guided wizard. A record-triggered flow runs automatically when a record is created, updated, or deleted, used for behind-the-scenes automation such as updating related records. A scheduled flow runs on a set schedule, used for recurring batch work. An autolaunched flow has no user interface and is started by another process, such as being called from another flow, used as a reusable building block. The judgement the exam tests most heavily is picking the right flow type for a stated requirement: a guided data-entry screen is a screen flow; automatic action when a record changes is a record-triggered flow; a nightly job is a scheduled flow; a reusable, UI-less subprocess is an autolaunched flow.
Choosing the right automation tool
Because the largest share of the exam lives here, a recurring theme is choosing the right automation tool and Flow type for a given requirement, within Salesforce’s current, Flow-centred toolset. The practical study guidance is to learn Flow thoroughly and build several flows of different types yourself, then practise reading a requirement and deciding, first, whether it is declarative at all (it almost always is on this exam), and second, exactly which tool and flow type fits. Being fluent in that decision is the difference between guessing and knowing on more than a quarter of the exam.
Chapter 5: User Interface (17%)
This domain covers what users actually see and use, assembled, like everything else on this exam, declaratively. It is moderate in weight but easy to under-practise, so build the pieces yourself.
The Lightning App Builder and page types
The central tool is the Lightning App Builder, the drag-and-drop builder for assembling pages from components without code. The exam expects you to know the page types you build with it: an app page (a custom page within an app), a home page (the landing page users see), and a record page (the layout of a single record’s details and related components). Building a record page in a Developer Edition org, dragging components onto it, and activating it for the right users, makes this domain concrete.
Page layouts, list views, and declarative components
Beyond Lightning pages, the exam covers familiar interface elements. A page layout controls the arrangement of fields, sections, and related lists on a record. A list view is a saved, filtered list of records for an object, letting users see a focused subset. Declarative components are the building blocks dropped onto Lightning pages. The exam also expects you to understand assembling a Lightning app and its navigation, tying the interface together into something a defined group of users can work in. The thread through this domain is that the interface, like the data model and the logic, is configured with clicks, and a good App Builder shapes a clear, usable interface without writing front-end code.
Chapter 6: App Deployment (10%)
This is the smallest domain, but it earns easy marks once you have moved metadata yourself, because the concepts are concrete the moment you run one change set. It covers moving work safely from development to production.
Sandboxes and the path to production
You do not build directly in the live production org, the org users work in day to day. Instead you build and test in a sandbox, a copy of an org used to develop and test safely without affecting real users and data. The exam expects you to understand that the standard path runs from a sandbox, through testing, to production, so that changes are validated before users ever see them.
Change sets, packages, and the AppExchange
Two mechanisms move metadata between orgs. A change set packages metadata (such as objects, fields, and flows) and moves it between related orgs, for example from a sandbox to its production org. A package bundles metadata for distribution, and the exam distinguishes two kinds: a managed package is versioned and upgradeable, typically distributed through the AppExchange (this is how commercial and reusable apps are delivered and updated), while an unmanaged package is a one-time bundle that the recipient then owns and can edit, with no upgrade path. The teaching point the exam tests: change sets move work between your own related orgs; packages (especially managed ones via the AppExchange) distribute work more broadly and, when managed, can be upgraded. Run one change set between a sandbox and a developer org so the deployment path is something you have done, not just read about.
Chapter 7: Study plan and timeline
With the five domains understood, the remaining work is pacing your study so the heaviest and hardest domains, data modelling and Flow, get the time they need, and so you are working from the current five-domain material.
A six-week plan, weighted to the core
A realistic plan for a working Salesforce admin runs about six weeks at roughly eight hours a week, with a free Developer Edition org open throughout. A sensible shape is: week one on Salesforce Fundamentals (platform model, apps, tabs, AppExchange, and the declarative-versus-code judgement); week two on data modelling (custom objects, field types, and lookup versus master-detail versus junction) until you can build a correct model including a many-to-many; week three on formula fields, roll-up summary fields, and validation rules; week four on Flow (screen, record-triggered, scheduled, and autolaunched), the largest and hardest domain; week five on the user interface (Lightning App Builder and pages) and deployment (sandbox, change sets, packages); and week six on full-length timed practice and review. If you are new to building on Salesforce, extend this toward eight weeks. Business Logic and Process Automation (week four) is the largest domain and Flow has the steepest curve, so give it the most time; the App Deployment domain is small and quick once you have run one change set. To turn this into dated study days for your own start date, use the free study-plan generator.
Practise by building, and use current material
The most effective preparation is building everything yourself in a Developer Edition org: create objects and relationships (including a junction object), write formulas and roll-up summaries, build flows of each type, assemble a Lightning app, and run a change set. That hands-on work is what makes the heavy domains stick and what the scenario questions reward. Use the free Trailhead trails and the official exam guide as your scope, and make sure your material is the current five-domain version, since older nine-section content is out of date. Avoid any site claiming to sell the actual questions; it breaches Salesforce policy and the exam agreement, and it will not teach you to build. If you have not yet taken it, the Salesforce Administrator credential covers the core platform skills employers usually ask for first, and many people pair the two to cover both running and extending an org.
Readiness check
Because the pass mark is 63%, your readiness signal is consistently scoring comfortably above that on fresh questions across all five domains, with particular confidence in data modelling and Flow. If your weak spots are in those two domains, do not book yet; they are half the exam, and they reward genuine building practice over recognition.
Chapter 8: Final preparation, exam day, and format
Final preparation
In your last session, do a focused pass over the highest-yield material: the lookup-versus-master-detail-versus-junction distinctions and what each enables, the formula-versus-roll-up-summary distinction (and that roll-ups need master-detail), the Flow types and which requirement each fits, and the change-set-versus-package distinction in deployment. These cluster in the data-modelling and business-logic domains that together make up half the exam, so they are where final revision pays off most. Re-read your own notes from building these in a Developer Edition org, since recalling something you built is far more reliable than recalling something you only read.
Exam day and format
On the day, the exam is 60 scored questions plus 5 unscored (65 total) in 105 minutes, in multiple-choice and multiple-select formats, proctored through Pearson VUE at a test centre or online. You need 63% to pass, and only the scored questions count. Read each scenario for what it is really asking, often which relationship type, which calculated field, which flow type, or which deployment mechanism fits, and remember the central lean of this credential: when a requirement can be met declaratively, the declarative answer is almost always intended, because Apex and Lightning Web Components are Platform Developer territory, not App Builder. Where two options seem plausible, prefer the one that reflects how the platform actually works (master-detail for roll-ups, the right flow type for the trigger, change sets between related orgs).
Keeping the credential active
After you pass, remember there is no fixed expiry, but the credential stays active only if you complete the free Trailhead maintenance module Salesforce releases with each platform update; diarise those deadlines so it does not lapse. Because Salesforce restructures and updates this exam over time, as the December 2025 move from nine sections to five shows, confirm the current domains, weights, pass mark, and format on the official exam guide before you book, since those are the details most likely to have shifted since this guide was written.