Plat-Admn-202 Salesforce Certified Platform App Builder Exam Topics and Questions

This topic sets the boundaries of what you can build on the platform without code, and where you need to bring in developers or third-party solutions. Eighteen percent of the exam sits here, so weak coverage in security models or reporting will cost you marks early.

– Declarative versus programmatic customization

The exam tests your ability to recognise when clicks stop and code begins. You need to know what workflows, validation rules, formula fields and Flow can achieve, and when a requirement demands Apex or Lightning Web Components instead. The boundary is not always obvious: some scenarios look declarative but hide governor limits or complexity that force a programmatic route. AgentExchange extends the platform with pre-built solutions, and you must identify when an AppExchange package or agent solves the problem faster than building from scratch. The emphasis is on efficiency, not proving you can build everything yourself.

– Security and sharing architecture

Object permissions, field-level security, profiles, permission sets, and sharing rules form the access control layer. The exam expects you to apply these in combination, not in isolation. A user might have object access but no field visibility, or read access elevated by a sharing rule but blocked by a validation rule. You must also know when role hierarchy, manual sharing, or Apex-managed sharing is the right answer. The platform offers many ways to grant or restrict access, and choosing the wrong layer creates either a security gap or a maintenance problem. The weighting here is significant, so expect multiple items that layer permissions and test whether you understand the interaction.

– Reporting and dashboards

Custom report types, cross-filters, bucketing, and dashboard components are the tools you use to meet reporting requirements. The exam probes whether you know which report type to build when standard ones do not cover the relationships you need, and when a joined report or matrix format is appropriate. You also need to recognise the limits: what you cannot do without a custom report type, and when a dashboard component refresh schedule or running-user setting changes what the audience sees. The focus is on translating a business requirement into the correct report structure, not on explaining what a report is.

How Salesforce Fundamentals is tested

Items in this topic present a scenario with a mix of security layers or a requirement that sits near the declarative-programmatic boundary, then ask you to choose the solution that meets all constraints. You lose marks when you pick a sharing rule that does not account for role hierarchy, or recommend Flow when the logic exceeds what declarative tools can handle. The reporting items describe a data structure and ask which report type or component satisfies the need, and wrong answers often look plausible because they use familiar features in the wrong context. Eighteen percent means roughly one in six items, so gaps in permission set behaviour or report type design will surface multiple times. The exam assumes you have built these features in a working org, not just read about them.

One-fifth of the exam sits in this topic, the highest weighting after process automation. The data model you choose constrains everything built on top of it, so wrong decisions here cascade into record access problems, reporting gaps, and user interface complexity. The exam tests whether you can design a schema that supports the requirements without creating maintenance debt.

– Choosing and relating objects

Master-detail, lookup, hierarchical, and external lookup relationships each carry different implications for record ownership, roll-up summaries, deletion behaviour, and reporting. The exam expects you to know which relationship type fits a given scenario, and what you lose or gain by choosing one over another. A master-detail relationship gives you roll-ups and tight coupling, but it also forces child records to inherit sharing and prevents reparenting in some configurations. A lookup is more flexible but does not support roll-up fields without code. You must also recognise when a junction object is the right model for many-to-many relationships, and when a hierarchical lookup makes sense for self-referencing data like organisation charts.

– Field types and data import

Changing a field type after data exists can cause data loss or transformation issues, and the exam probes your awareness of what happens when you convert from text to picklist, number to currency, or checkbox to formula. You also need to know the constraints and capabilities of Data Import Wizard, Data Loader, and external data sources. Data Import Wizard handles up to fifty thousand records and supports matching by name or ID, but it does not handle all objects or complex relationships. Data Loader scales higher and works with all objects, but it requires more preparation. External objects let you surface data from outside Salesforce without importing it, and you must recognise when that trade-off makes sense given the limits on writes and relationships.

How Data Modeling and Management is tested

The exam describes a business requirement, then asks which relationship type, field type, or import method meets it without introducing problems downstream. You lose marks by choosing a lookup when a master-detail is needed for roll-up summaries, or recommending Data Import Wizard when the volume exceeds its limits. Field data type items focus on the consequences of a change: what happens to existing values, whether the change is reversible, and whether formulas or integrations break. Data import items layer in constraints like matching rules, duplicate management, or the need to load related records in sequence. Twenty percent of the exam means data modeling appears more often than any topic except process automation, so weak schema knowledge costs you multiple marks.

Nearly a third of the exam lives in this topic. Formula fields, validation rules, roll-up summaries, and Flow are the tools you use to enforce business logic without code, and the exam assumes you have built, debugged, and maintained all of them in production. Weak coverage here guarantees a failed attempt.

– Formulas, validation rules, and roll-up summaries

Formula fields calculate values from other fields, cross-object references, or functions, and the exam tests whether you know which return type to use, how to handle nulls, and when a formula hits a complexity or reference limit. Validation rules prevent saves when a condition is true, and you must understand the order of execution: when validation fires relative to workflow, Flow, and triggers. A common mistake is writing a rule that blocks legitimate saves or fails to catch the error it was meant to stop. Roll-up summary fields aggregate child records on master-detail relationships, and you need to know which operations are supported, what happens when filter criteria change, and why roll-ups do not work on lookup relationships without code. The exam gives you a requirement and asks which formula or rule meets it, often with wrong options that look correct but miss an edge case.

– Flow design and troubleshooting

Flow Builder is the primary automation tool, and the exam covers screen flows, record-triggered flows, scheduled flows, and autolaunched flows. You must know when to use each type, how to configure entry conditions and criteria, and how to handle loops, decisions, and assignments without hitting governor limits. The exam also tests your ability to maintain and debug flows: how to version them, activate or deactivate them, and interpret error messages when a flow fails. You need to recognise when a flow is the right choice and when a simpler tool like a validation rule or process would suffice. Approval processes have their own use cases, typically for routing records through a sequence of approvals with email alerts and reassignment, and you must know when they fit better than a flow with approval actions.

– Agentforce and automation use cases

Agentforce capabilities include automating routine tasks, surfacing recommendations, and orchestrating multi-step processes. The exam expects you to identify scenarios where Agentforce adds value, such as deflecting common requests or guiding users through a workflow. You do not need to configure agents in detail, but you must recognise when the use case suits agent-based automation rather than a standard flow or validation rule. The focus is on understanding the boundaries: what Agentforce can do, and when a traditional automation approach remains the better fit.

How Business Logic and Process Automation is tested

Items in this topic describe a business process and ask you to select the automation tool that meets the requirement with the least complexity and maintenance cost. You lose marks by choosing Flow when a validation rule would work, or by designing a flow that runs on every edit when it only needs to run on creation. The exam also tests troubleshooting: a flow fails, and you must identify the cause from the description, such as a missing null check, a criteria node that never evaluates true, or a loop that hits a governor limit. Thirty-two percent means roughly one in three items comes from this topic, so every gap in formula syntax, flow logic, or roll-up behaviour costs you multiple marks. The exam assumes you have debugged flows in a sandbox and understand what happens when execution order or bulkification goes wrong.

Seventeen percent of the exam focuses on how users interact with the platform, from page layouts and Lightning App Builder to custom buttons, actions, and mobile configuration. The exam tests whether you can translate a user experience requirement into the right combination of declarative and programmatic customisation, and whether you understand the constraints each option brings.

– Page layouts, actions, and Lightning components

Page layouts control field placement, related lists, and button visibility, but they do not give you dynamic rendering based on user behaviour. Lightning App Builder takes over when you need drag-and-drop component assembly, conditional visibility, or a custom home page. The exam expects you to know which tool to use, and when a standard component meets the need versus when you must bring in a custom Lightning Web Component or Aura component. Custom buttons and actions extend the interface with links, JavaScript, or Visualforce, and you must recognise when a quick action on a record page is better than a list button, or when a global action makes sense. The focus is on choosing the least complex solution that satisfies the requirement.

– Mobile configuration and programmatic customization

Salesforce mobile has its own navigation, compact layouts, and action configurations, and the exam tests whether you know how to optimize layouts and actions for a smaller screen and touch interface. You must also understand when programmatic customisation is required: a Lightning Web Component for a custom UI, or Apex for logic that exceeds what Flow or formulas can handle. The boundary between declarative and programmatic is a recurring theme across this topic, and wrong answers often suggest a programmatic solution when a declarative one exists, or vice versa.

How User Interface is tested

The exam describes a user experience requirement and asks which combination of layout, component, or action satisfies it. You lose marks by choosing Lightning App Builder when a page layout change would work, or by recommending a custom component when a standard one with conditional visibility meets the need. Mobile items focus on the differences between desktop and mobile configuration: which actions appear, how compact layouts render, and what happens when a user works offline. Seventeen percent means roughly one in six items, so gaps in Lightning App Builder or action configuration will surface multiple times. The exam assumes you have configured pages and tested them in both desktop and mobile contexts.

Thirteen percent of the exam covers moving customisations between environments, managing the application lifecycle, and choosing the right deployment method. The exam tests whether you understand sandbox types, change sets, packages, and deployment planning, and whether you can troubleshoot when a deployment fails or behaves differently in production than it did in the sandbox.

– Sandboxes and change sets

Developer, Developer Pro, Partial Copy, and Full sandboxes differ in data volume, storage, and refresh interval, and the exam expects you to recommend the right type for a given use case. A Developer sandbox is enough for building and testing configuration, but it does not include data for integration or user acceptance testing. A Full sandbox replicates production data and is used for final validation, but it is expensive and refreshes infrequently. Change sets move metadata between connected orgs, and you must know what they can and cannot deploy: they handle most declarative customisations, but they do not move record data, and some metadata types require manual steps or are excluded entirely. The exam also tests troubleshooting: a change set fails, and you must identify the missing dependency or unsupported component.

– Packages and deployment planning

Unmanaged packages bundle metadata for one-time distribution, with no upgrade path and no control over what the recipient changes. Managed packages support versioning, upgrades, and intellectual property protection, and they are used by AppExchange partners. You must recognise when each package type fits the scenario, and what happens when a package is installed or upgraded. Deployment planning involves sequencing changes, managing dependencies, and deciding whether to use change sets, packages, or a third-party tool. The exam gives you a scenario with multiple environments, a release schedule, and a set of customisations, then asks which deployment approach minimises risk and downtime.

How App Deployment is tested

Items in this topic describe a deployment scenario and ask which sandbox type, change set configuration, or package approach meets the requirement. You lose marks by recommending a Developer sandbox when the use case requires production data, or by attempting to deploy metadata that change sets do not support without identifying the manual step. Package items focus on the difference between managed and unmanaged, and when each is appropriate. Deployment planning items layer in constraints like dependent metadata, user training, or rollback requirements. Thirteen percent means roughly one in eight items, so weak knowledge of change set limitations or sandbox types will cost you marks late in the exam.