Home / crm-business-applications / Salesforce Certified Platform App Builder / Cheat Sheet
Salesforce Certified Platform App Builder

App Builder Cheat Sheet

Platform App Builder Tests the Least-Effort Declarative Fix — Not Code or Extra Layouts

For admins and builders designing apps without code. The August 2026 update pushed Business Logic and Process Automation to 32%, so precise Flow timing, formula limits and relationship rules now decide the result.

Check Your Readiness →
Among the harder certs
Avg: Not published by Salesforce
Pass: 750 / 1000
Most candidates understand Salesforce Certified Platform App Builder concepts — and still fail. This exam tests how you apply knowledge under pressure.

Platform App Builder Domain Map (Summer '26 guide)

Scenarios describe a business need and ask for the most appropriate or least-effort solution. Several options usually work, but only one is declarative, secure everywhere and maintainable. Weights changed from 23/22/28/17/10 to 18/20/32/17/13 when the Summer '26 update went live on 21 August 2026.

  1. 01
    Business Logic and Process Automation (32%) — formulas, roll-ups, validation rules, before-save vs after-save flows, Flow Approvals
  2. 02
    Data Modeling and Management (20%) — master-detail vs lookup, junction objects, record types, external IDs, import tools
  3. 03
    Salesforce Fundamentals (18%) — OWD, sharing rules, restriction rules, field-level security, report types, dashboards
  4. 04
    User Interface (17%) — Lightning App Builder, Dynamic Forms and Actions, quick actions, compact layouts, Path
  5. 05
    App Deployment (13%) — sandbox types and refresh intervals, change sets, managed vs unmanaged packages, DevOps Center

Wrong instinct vs correct approach

Extra fields must appear on an Opportunity record only when Stage reaches Negotiation
✕ Wrong instinct

Create a second page layout with those fields

✓ Correct approach

Layouts cannot react to a field value within the same record type. Dynamic Forms visibility rules show fields or sections conditionally on one Lightning record page, and Dynamic Actions do the same for buttons.

Reps log site visits from an Account and the visit must link to that account automatically
✕ Wrong instinct

Build a global action for logging visits

✓ Correct approach

An object-specific action on Account creates related records linked to the source record. Global actions create unrelated records. Add predefined field values to cut clicks and keep data consistent.

Management needs a report of accounts that have no opportunities
✕ Wrong instinct

Use the standard Accounts with Opportunities report type

✓ Correct approach

That standard type returns only accounts with opportunities. A custom report type with Accounts and the with or without related records option, then a filter for missing children, is needed; that choice cannot change after saving.

A migration must load 300,000 legacy records and support safe reruns
✕ Wrong instinct

Use the Data Import Wizard because it is simpler

✓ Correct approach

The wizard caps at 50,000 records. Data Loader handles up to 5 million and supports upsert matched on an external ID, so reruns update rather than duplicate. Mark the external ID unique if duplicates must be blocked.

Invalid discount values must never be saved, whether from the UI, imports or integrations
✕ Wrong instinct

Build a record-triggered flow that shows an error

✓ Correct approach

A validation rule blocks the save when its error condition is true and applies across UI, API and imports. Write the formula for the invalid state; PRIORVALUE and ISCHANGED detect changed values.

Know these cold

  • ▸ Detail records have no owner, inherit sharing and are deleted with their master
  • ▸ Junction object needs two master-detail fields; the first created is primary
  • ▸ Hierarchical relationships exist only on the User object
  • ▸ Formula fields are calculated on read and never trigger automation
  • ▸ Flow Trigger Explorer shows trigger order; same-object flows do not run in creation order
  • ▸ Lightning page assignment — ost specific app, record type and profile combination wins
  • ▸ Compact layout controls the highlights panel and mobile header, assigned per record type
  • ▸ Sandbox refresh — eveloper and Developer Pro daily, Partial Copy five days, Full 29 days
  • ▸ Managed packages are namespaced and upgradeable; unmanaged components belong to the subscriber
  • ▸ Workflow Rules and Process Builder answers are wrong; new automation belongs in Flow

Can you answer these without checking your notes?

In this scenario: "Extra fields must appear on an Opportunity record only when Stage reaches Negotiation" — what should you do first?
Layouts cannot react to a field value within the same record type. Dynamic Forms visibility rules show fields or sections conditionally on one Lightning record page, and Dynamic Actions do the same for buttons.
In this scenario: "Reps log site visits from an Account and the visit must link to that account automatically" — what should you do first?
An object-specific action on Account creates related records linked to the source record. Global actions create unrelated records. Add predefined field values to cut clicks and keep data consistent.
In this scenario: "Management needs a report of accounts that have no opportunities" — what should you do first?
That standard type returns only accounts with opportunities. A custom report type with Accounts and the with or without related records option, then a filter for missing children, is needed; that choice cannot change after saving.

Common Exam Mistakes — What candidates get wrong

Removing a field from the page layout to keep users from seeing it

Layouts only affect the record page. The value still appears in reports, list views, search and the API. Field-level security through profiles and permission sets hides it everywhere; Dynamic Forms visibility is also not security.

Planning a roll-up summary field over a lookup relationship

Native roll-up summaries (COUNT, SUM, MIN, MAX) need master-detail. Converting lookup to master-detail fails unless every child already has a parent. Formulas reach parents up to ten relationships away but never children.

Writing a sharing rule to take access away from a group

Sharing rules only open access above the org-wide default. Set OWD to the most restrictive level anyone needs, then open up with roles, sharing rules or teams. Restriction rules filter visibility down on supported objects.

Using an after-save flow to set a field on the triggering record

A before-save record-triggered flow performs fast field updates without an extra save. After-save is for creating or updating other records, sending email and calling actions. Add entry conditions so flows do not repeat on every edit.

Expecting a change set to delete a field or carry reference records

Change sets add or update metadata only, between orgs sharing the same production org, and lock once uploaded: clone to add a missing component. Deletions need destructive changes; records need data tools.

Resources to help you pass Salesforce Platform App Builder on your first attempt

With automation now at 32%, check whether your Flow and formula choices hold up.