Salesforce Certified Platform App Builder Study Guide¶

Independent AI-assisted resource — SOURCES + OBJECTIVES CHECKED; HUMAN REVIEW PENDING. The September 29, 2026 deep review maps 26 retained objective statements, answers 40 prompts and adds 28 executed local checks. Eight Salesforce org activities remain proposed.

Study guide at a glance

Start here

Report an issue with SALESFORCE-PLATFORM-APP-BUILDER

Blueprint checked2026-10-29

Review stateSources + objectives checked — human review pending

Guide-only active reading45 min–1 hr

Prerequisites: No formal prerequisite is published; Salesforce says candidates generally have six to twelve months building applications. Practice the complete declarative lifecycle from requirements, access and data model through bulk-safe Flow, persona-specific UI, deployment evidence, monitoring and rollback in an authorized disposable org.

Exam essentialsRead the objective map, key distinctions, and readiness checklist.

Deep understandingWork through every domain, including decisions, failure modes, and related items.

Hands-on labsBegin with Use the first hands-on exercise in the guide, then use the remaining labs to produce evidence you can inspect and explain.

Official objective domains

See the objective map in this guide

The active-reading range uses 90–130 words per minute for technical material. Labs, troubleshooting, note-taking, spaced review, and prerequisite gaps add time; it is not a total preparation promise.

CURRENT BLUEPRINT: The canonical Help guide retains Summer ’26 scope and the five weights below. Its complete browser-rendered outline matches the substantive content of the 26 saved objectives; one sentence adds the article “the” before AgentExchange. The automated fetch returns a loading page and requires manual review. Baseline files were retained, with the editorial difference recorded; this is not a successful automated hash comparison.

VERIFY CURRENT — exam details: The guide lists 60 multiple-choice questions plus up to five unscored, 105 minutes, a 73% passing score, USD 200 registration and USD 100 retake plus taxes, and no prerequisite. Six to twelve months of relevant experience describes the intended audience. Recheck the actual booking terms and regional availability.

Refresh and upcoming changes: The August 27, 2026 Salesforce Admins interview confirms the refreshed emphasis on building, maintaining and troubleshooting Flow, with foundational Agentforce use. The Salesforce Certification Change Management lead announced on August 24 that the update launched August 21, 2026; the current exam guide now shows Summer ’26 alignment. No later blueprint or retirement announcement was found in the checked sources. Current product features do not by themselves announce an exam refresh.

VERIFY CURRENT — maintenance discrepancy: The exam article says three maintenance badges per year, but the dedicated maintenance policy and schedule specify one annual badge and place App Builder in the Winter cycle. Their English bodies were readable through German-locale routes. The schedule lists Winter ’26 availability December 11, 2025 and due date December 4, 2026, in Pacific time; dates may change. Use the requirement assigned in your credential profile and the dedicated schedule. The conflicting exam-page sentence remains recorded for clarification.

How to use this guide¶

Work from requirement to evidence: business process → data model → access model → declarative logic → user experience → deployment → monitoring and rollback. Platform App Builder is broader than assembling screens. Every decision can affect ownership, sharing, automation, reporting, integrations, limits, and later change.

Use only an authorized Trailhead Playground, Developer Edition, or sandbox. The original scenarios and checks below teach decisions; they are not recalled exam items. Do not use dumps, copied live questions, or shared superbadge solutions.

About related items: A Related item: callout adds prerequisite, architectural, release, or operational context. It supports the topic but does not assert that Salesforce uses that wording in the public blueprint.

Blueprint map¶

Domain	Weight	Evidence to produce
Salesforce Fundamentals	18%	Declarative/programmatic boundary, least-privilege and extension review
Data Modeling and Management	20%	Entity/relationship model, field choices and controlled data movement
Business Logic and Process Automation	32%	Tested Flow/formula/validation/approval behavior with failure evidence
User Interface	17%	Persona/form-factor experience and activation matrix
App Deployment	13%	Versioned dependency-aware promotion and rollback record

1. Salesforce Fundamentals — 18%¶

Declarative customization uses platform metadata and builders; programmatic customization uses Apex, Lightning Web Components, APIs, or other code when requirements exceed declarative boundaries. “Clicks before code” is a starting preference, not an absolute rule. Compare maintainability, transaction behavior, scale, testability, security context, portability, UI needs, team skills, and limits.

Map access in layers: user license and feature licenses; profile/permission sets for object, field, app, system, and feature permissions; organization-wide defaults; hierarchy, sharing rules, teams, territories, queues, and manual or programmatic sharing for records. Sharing opens record access but cannot supply missing object CRUD. Lightning component visibility and page layouts improve experience but do not secure data.

Report types determine record/relationship availability; filters, groupings, formulas, and buckets shape a report; folders and underlying data permissions shape its audience. Dashboards depend on source reports and a running-user model. Always validate analytical output as the target persona.

AgentExchange/AppExchange packages can add apps, agents, flows, components, permissions, and integrations. Assess publisher trust, package type, licenses, data access, external endpoints, upgrade/uninstall path, support, and sandbox results before installation.

Related item: A declarative solution is still software. Give it ownership, version control, tests, deployment evidence, monitoring, and a retirement path.

PRACTICAL DEPTH — permission composition: A muting permission set limits its own permission set group. Other groups, profiles or direct assignments can still grant the permission. Include dependent permissions and every assignment source when reviewing effective access.

2. Data Modeling and Management — 20%¶

Start with durable business entities and cardinality. Reuse standard objects when their lifecycle and behavior fit; create custom objects when the concept is distinct. A lookup can be optional and typically preserves independent ownership; master-detail makes the child dependent, inherits important access behavior, supports native roll-ups, and can cascade delete. Many-to-many models use a junction object, commonly with two master-detail relationships, when that dependency is appropriate.

Field design affects validation, storage, reporting, integrations, and later migration. Consider type, precision, length, requiredness, uniqueness, case sensitivity, defaults, picklist governance, external IDs, encryption, history, and help text. Before changing a field type, inventory existing data, formulas, flows, validation, reports, code, integrations, packages, and information loss.

Formula fields derive a value at read time. Roll-up summaries aggregate eligible child records on the parent in supported master-detail contexts. Cross-object formulas expose related values without copying them. Choose based on ownership of truth, freshness, aggregation, security, performance, and reporting needs.

Data Import Wizard offers guided bounded imports; Data Loader supports API-based insert, update, upsert, delete, and export at larger scale. External objects expose data held outside Salesforce through supported connectivity and have different transaction, relationship, search, reporting, and availability considerations. Rehearse mapping, automation, duplicates, failures, reconciliation, and rollback with synthetic data.

Related item: Schema Builder visualizes and can edit metadata, but a convenient canvas does not replace a reviewed data dictionary, ownership model, or migration plan.

PRACTICAL DEPTH — data visibility: Cross-object formulas can expose a referenced parent's value through a visible child formula even when the reader lacks access to the parent record. Similarly, roll-up summaries can include detail-field values hidden from the reader. Review the resulting formula/summary field's audience; source-field or parent-record restrictions alone are insufficient. Keep every copied or derived output in the access review.

PRACTICAL DEPTH — relationship and aggregate boundaries: The relationship lesson explains the different lifecycles of lookup and master-detail records. Choose and test deletion behavior explicitly. Native roll-ups have supported relationships, fields and calculation types; conversion to lookup can be blocked while a roll-up exists. An ordinary SQL join across two child collections can multiply amounts. The local workbook demonstrates that reporting error, not Salesforce's native roll-up engine, currency conversion, recalculation timing or Recycle Bin behavior.

3. Business Logic and Process Automation — 32%¶

This is the largest domain. Translate each rule into trigger, criteria, inputs, actor/security context, reads/writes, outputs, side effects, bulk volume, fault behavior, observability, and recovery.

Formula fields calculate values; validation rules reject writes that violate a condition; flows orchestrate screens, records, schedules, events, or background work; Flow Approval processes coordinate reviewed decisions. Do not use automation merely because it can express a rule—select the narrowest mechanism with the correct transaction and user experience.

Choose Flow types deliberately:

record-triggered flows react to record change; before-save fits efficient same-record updates and after-save fits many related actions;
screen flows guide user interaction and validation;
autolaunched flows expose reusable background logic;
scheduled and schedule-triggered patterns handle time-based populations;
platform-event and other specialized starts decouple event producers and consumers where supported.

Flow design must be bulk-safe. Operate on collections, avoid queries or writes inside unbounded loops, constrain entry criteria, avoid recursion, make retryable effects idempotent, and use fault connectors or platform error handling. Debug with representative users and datasets. Inspect Flow Interviews/errors, record history, logs or other supported evidence before changing logic.

Flow Approval design includes entry, submitter, approver routing, lock behavior, approval/rejection/recall actions, delegation, timeouts/escalation where supported, and what happens when data changes. Version and activate deliberately.

Agentforce can initiate or assist business processes. Bound its topics/actions, instructions, grounding, permissions, verification, side effects, and escalation. Generative text must not silently become trusted transaction input.

Related item: Order of execution connects validation, flows, assignment, duplicates, Apex, workflow-era behavior, and commit. Troubleshoot the whole transaction, not only the visible flow.

PRACTICAL DEPTH — transaction evidence: A handled Flow fault does not automatically undo preceding changes. Screen flows can use Roll Back Records before displaying an error screen; record-triggered flows can use Custom Error. These concern the current transaction. A later error cannot roll back work already committed before a screen boundary. Record a before/after value and transaction boundary, not just a displayed error.

PRACTICAL DEPTH — approval locking: In Flow Approval processes, a record supports one approval lock. Concurrent steps that each attempt to lock it can fail. Coordinate locking at the stage or process level, make parallel steps depend on the lock step, and coordinate completion before unlocking. Consider rejection and failure recovery, permitted approver edits, administrator edits and another process submitted for the same record. A locked record is not an immutable copy of the data being reviewed; preserve the business evidence needed to understand the approval.

VERIFY CURRENT — execution context: The API 68 change introduces User Context–Enforces User Permissions for eligible screen/autolaunched flows at API 68.0+. Ordinary user context can inherit an elevated caller's access. Check version, run option and identity. For Service agents, a verified contact can still act through the dedicated agent user; trusted customer identification must constrain action queries. Supported authenticated-site configurations have different identity behavior. No release-specific option substitutes for checking the actual caller and data scope.

4. User Interface — 17%¶

Choose the surface by task and persona. Page layouts arrange fields, related lists, buttons, and actions and participate in record-type/profile assignment. Lightning App Builder composes app, home, and record pages from components. Dynamic Forms places fields/sections as components and supports conditional visibility. Compact layouts, highlights, tabs, list views, utility items, and actions serve different interaction needs.

Custom buttons and links navigate or invoke supported behavior; quick actions can be global or object-specific, with different record context. Screen flows can be embedded or launched from actions. Lightning components may be standard, managed, or custom; declarative builders place and configure them, while programmatic LWC/Apex work belongs to developers when behavior exceeds declarative capabilities.

Design an activation matrix: app × record type × profile/persona × desktop/phone → expected page, layout, fields, components, and actions. Test accessibility, required/read-only behavior, visibility, empty/error states, and performance. Mobile needs deliberate navigation, action, form-factor, offline/connectivity, and component-support review.

Related item: Conditional visibility reduces clutter; it does not enforce object, field, record, or action authorization.

5. App Deployment — 13%¶

Application lifecycle management includes intake and acceptance criteria, architecture/security review, development environment, source/version record, testing, release approval, deployment, verification, monitoring, rollback, and retirement. Choose sandbox types based on metadata/data fidelity, capacity, refresh behavior, privacy, integration isolation, test objective, and cost—not by name alone.

Change sets move supported metadata between related orgs. They do not provide a complete universal deployment solution. Identify dependencies, profiles/permission changes, data/configuration steps, destructive changes, tests, manual post-deployment work, and ordering. Validate inbound change sets before deploying, record results, and test as intended personas afterward.

Unmanaged packages are editable snapshots without an upgrade path controlled like managed packages. Managed packages support namespace/protection and provider upgrades for distributed applications. Unlocked packages and Salesforce DX/source-driven approaches support modular internal development. Know the use case and boundaries; confirm current feature behavior in official documentation.

A deployment plan names owner, window, target, artifact/version, prerequisites, test results, backup/recovery, communication, steps, validation queries/user journeys, monitoring, rollback threshold, and evidence location.

Related item: Metadata deployment does not automatically migrate business data, secrets, endpoint authorization, certificates, or every org-specific setting.

PRACTICAL DEPTH — deployment evidence: The deployment monitor distinguishes validation from deployment. Validation does not save the components. A quick deployment requires a qualifying recent validation for the target, successful tests and applicable coverage; another deployment, including a package installation, invalidates prior quick-deploy eligibility. A “Succeeded” section can also contain a partially successful nonproduction deployment when rollbackOnError is false. Inspect the exact status and component results, then verify user journeys. A dependency graph passing locally is only preparation for that process.

Integrated scenarios¶

Scenario 1: Partner onboarding application¶

Design partner applications, review steps, contacts, and required documents. Produce an entity/relationship model, least-privilege matrix, persona-specific pages, validation/formulas, approval Flow, notification/fault behavior, reports, and a sandbox-to-production plan. Explain which requirement would cross into Apex/LWC and why. Check whether a visible formula reveals a restricted parent value; test its output as the intended user. Distinguish approval work-item decisions from locks and underlying record edits.

Scenario 2: Equipment inspection process¶

Users complete a mobile screen flow, attach evidence, and create follow-up work for failed checks. Model equipment, inspection, findings, and work; handle master-detail/lookup tradeoffs, offline/poor connection behavior, bulk updates, duplicate prevention, accessible screens, dashboard grain, and recovery after partial downstream failure. Three inspection costs of 100, 100 and 50 cents total 250, even if two attachments produce six rows in a joined report. Decide which transaction owns follow-up work and show what persists after failure.

Scenario 3: Governed service automation¶

An Agentforce agent may gather a request and invoke an approved Flow. Define topics/actions, verification, field access, transaction input validation, deterministic branches, human approval, sandbox tests, audit evidence, deployment order, monitoring, and immediate disable/rollback. Record both the authenticated actor and trusted customer identity; a nonempty identity variable must not enable retrieval of another customer. Keep previously committed business data separate from metadata rollback.

Hands-on evidence labs¶

PRACTICAL DEPTH: These eight org activities are proposed, not executed here. Use an authorized disposable org and synthetic records; keep outbound actions controlled. Preserve expected/actual results and restore the exercise configuration afterward. Durations are planning estimates.

Activity	Procedure and acceptance evidence
1. Requirements boundary, 45–75 min	Classify ten requirements by configuration, Flow, package or code. Explain a limit, security context and maintenance consequence for each choice.
2. Relationships, 75–120 min	Build three related objects and a roll-up. Test independent/cascading deletion, required parents, equal-value details and parent validation. Review the audience of derived fields.
3. Least privilege, 60–90 min	Test two personas at object, field and record layers. Include a group mute overridden by another grant and a formula referencing a restricted parent.
4. Data operation, 60–90 min	Rehearse external-ID import/upsert with creates, updates, duplicates and rejects. Reconcile saved rows and automation effects; demonstrate the selected recovery method.
5. Flow lifecycle, 120–180 min	Create, bulk-test and version a record-triggered flow and reusable flow. Inject a downstream failure; compare handled faults and explicit rollback, including a screen transaction boundary where applicable.
6. User experience, 75–120 min	Build record types, layouts, actions and Lightning pages. Verify desktop/phone activation, accessible error states, requiredness and actual data permissions.
7. Approvals and agent, 75–120 min	Rehearse sequential and parallel approval paths with coordinated locking, rejection and recovery. Where licensed, test verified-customer action scope; otherwise submit a design only.
8. Deployment, 90–150 min	Inventory dependencies, validate a change set, inspect test/component results and verify the deployed app as its users. Rehearse an explicit recovery threshold and distinguish data recovery from metadata rollback.

Executed local workbook¶

This original program passed 28 checks using Python 3.13.14, standard-library SQLite and graphlib. Save it as app_builder_workbook.py and run python app_builder_workbook.py. It uses fixed synthetic data in memory and makes no Salesforce or network calls.

It executes real foreign-key constraints, two chosen deletion policies, aggregation and transaction rollback. A required detail cascades; an optional note retains its row and clears its key. These are explicit local design choices, not an implementation of every Salesforce relationship rule. A local parent-budget check is application logic. Native roll-up recalculation, sharing, validation order, currency, Recycle Bin, Flow and approval locking were not run.

The dependency graph uses an original simplified manifest. An “available” dependency is a supplied assumption, not verified target-org metadata. Sorting neither discovers metadata dependencies nor establishes deployability, licenses, tests, permissions or rollback. The workbook tests missing dependencies and cycles; it does not perform a deployment. Transactions use one SQLite connection at a time, with no concurrency or crash-recovery claim.

import json
import sqlite3
from graphlib import CycleError, TopologicalSorter

checks = []


def check(name, condition):
    if not condition:
        raise AssertionError(name)
    checks.append(name)


def database():
    db = sqlite3.connect(':memory:')
    db.execute('PRAGMA foreign_keys = ON')
    db.executescript('''
        CREATE TABLE request (
            id TEXT PRIMARY KEY, status TEXT NOT NULL,
            budget INTEGER NOT NULL CHECK(budget >= 0));
        CREATE TABLE line (
            id TEXT PRIMARY KEY,
            request_id TEXT NOT NULL REFERENCES request(id) ON DELETE CASCADE,
            cents INTEGER NOT NULL CHECK(cents >= 0));
        CREATE TABLE note (
            id TEXT PRIMARY KEY,
            request_id TEXT REFERENCES request(id) ON DELETE SET NULL);
        INSERT INTO request VALUES ('Q1', 'Draft', 250), ('Q2', 'Draft', 0);
        INSERT INTO line VALUES ('L1','Q1',100), ('L2','Q1',100), ('L3','Q1',50);
        INSERT INTO note VALUES ('N1','Q1'), ('N2','Q1');
    ''')
    return db


def state(db):
    return {table: db.execute('SELECT * FROM ' + table + ' ORDER BY id').fetchall()
            for table in ('request', 'line', 'note')}


db = database()
check('foreign keys enabled', db.execute('PRAGMA foreign_keys').fetchone()[0] == 1)
check('three detail rows total 250 cents', db.execute('SELECT COUNT(*), SUM(cents) FROM line').fetchone() == (3, 250))
naive = db.execute('SELECT COUNT(*), SUM(l.cents), SUM(DISTINCT l.cents) '
                   'FROM line l JOIN note n ON n.request_id=l.request_id').fetchone()
check('joining independent children multiplies rows', naive[0] == 6)
check('naive joined sum doubles the amount', naive[1] == 500)
check('distinct amounts lose separate equal-value lines', naive[2] == 150)
totals = db.execute('''SELECT r.id, COALESCE(x.total,0)
    FROM request r LEFT JOIN
      (SELECT request_id, SUM(cents) total FROM line GROUP BY request_id) x
    ON r.id=x.request_id ORDER BY r.id''').fetchall()
check('aggregate by parent before combining other details', totals == [('Q1',250),('Q2',0)])
original = state(db)
for description, sql, args in [
    ('orphan detail rejected', 'INSERT INTO line VALUES (?,?,?)', ('L4','absent',10)),
    ('required parent enforced', 'INSERT INTO line VALUES (?,?,?)', ('L4',None,10)),
    ('negative detail rejected', 'INSERT INTO line VALUES (?,?,?)', ('L4','Q1',-1)),
]:
    try:
        with db:
            db.execute(sql,args)
    except sqlite3.IntegrityError:
        check(description,state(db)==original)
    else:
        raise AssertionError(description)

try:
    with db:
        db.execute('INSERT INTO line VALUES (?,?,?)', ('L4','Q1',1))
        total = db.execute('SELECT SUM(cents) FROM line WHERE request_id=?',('Q1',)).fetchone()[0]
        budget = db.execute('SELECT budget FROM request WHERE id=?',('Q1',)).fetchone()[0]
        if total > budget:
            raise ValueError('local parent-budget rule')
except ValueError:
    check('parent-budget failure rolls back child change',state(db)==original)
else:
    raise AssertionError('over-budget change accepted')

with db:
    db.execute('DELETE FROM line WHERE id=?',('L3',))
check('deleting one detail keeps parent', db.execute('SELECT COUNT(*) FROM request WHERE id=?',('Q1',)).fetchone()[0] == 1)
check('detail deletion changes computed total', db.execute('SELECT SUM(cents) FROM line').fetchone()[0] == 200)
with db:
    db.execute('DELETE FROM request WHERE id=?',('Q1',))
check('chosen cascading relationship removes remaining details',db.execute('SELECT COUNT(*) FROM line').fetchone()[0] == 0)
check('chosen nullable relationship keeps notes',db.execute('SELECT COUNT(*) FROM note').fetchone()[0] == 2)
check('retained notes lose the removed parent key',db.execute('SELECT request_id FROM note').fetchall() == [(None,),(None,)])
check('unrelated parent remains',db.execute('SELECT id FROM request').fetchall() == [('Q2',)])
db.close()


def failure_path(mode):
    connection = database()
    connection.execute('UPDATE request SET status=? WHERE id=?',('Reviewed','Q1'))
    if mode == 'earlier_commit':
        connection.commit()
    try:
        connection.execute('INSERT INTO line VALUES (?,?,?)',('L4','Q1',-1))
    except sqlite3.IntegrityError:
        if mode == 'handled_commit':
            connection.commit()
        else:
            connection.rollback()
    result = state(connection)
    check(mode + ' ends transaction',not connection.in_transaction)
    connection.close()
    return result


handled = failure_path('handled_commit')
rolled = failure_path('explicit_rollback')
earlier = failure_path('earlier_commit')
check('handled failure can preserve previous update',handled['request'][0][1] == 'Reviewed')
check('explicit rollback restores same-transaction update',rolled['request'][0][1] == 'Draft')
check('later rollback does not undo an earlier commit',earlier['request'][0][1] == 'Reviewed')
check('all three paths reject invalid detail',len(handled['line']) == len(rolled['line']) == len(earlier['line']) == 3)


def deployment_order(dependencies, available=()):
    available = set(available)
    missing = set().union(*dependencies.values()) - set(dependencies) - available
    if missing:
        raise ValueError('undeclared dependency: ' + ','.join(sorted(missing)))
    graph = {key:set(value)-available for key,value in dependencies.items()}
    return list(TopologicalSorter(graph).static_order())


plan = {'object':set(), 'field':{'object'}, 'flow':{'field'},
        'page':{'flow'}, 'permissions':{'object','field','flow'}}
order = deployment_order(plan)
check('all planned components included once',len(order) == len(set(order)) == 5)
check('every prerequisite precedes its dependent',all(order.index(p) < order.index(k) for k,parents in plan.items() for p in parents))
check('known existing dependency can be outside artifact',deployment_order({'page':{'flow'}},{'flow'}) == ['page'])
try:
    deployment_order({'page':{'missing_flow'}})
except ValueError:
    check('missing dependency rejected',True)
else:
    raise AssertionError('missing dependency accepted')
try:
    deployment_order({'flow':{'subflow'},'subflow':{'flow'}})
except CycleError:
    check('cycle rejected',True)
else:
    raise AssertionError('cycle accepted')

print(json.dumps({'passed':len(checks),'checks':checks,'correct_cents':250,
                  'naive_cents':500,'distinct_cents':150,'deployment_order':order},sort_keys=True))

Explain the evidence: three detail rows sum to 250 cents; joining two independent notes doubles the sum to 500. SUM(DISTINCT cents) loses one of the equal-value details and yields 150. Aggregation at the request grain preserves the correct amount. A caught failure followed by commit preserves the earlier update; explicit rollback restores it only when it is still in the same transaction. Translate these questions into a real org test before treating any design as validated there.

Readiness checks¶

Original prompts and answer notes for explanation and demonstration, not live exam content.

Which facts decide declarative versus programmatic implementation? Compare transaction behavior, limits, security, user experience, integrations, testability and available team skills. Choose the simplest maintainable mechanism that actually meets the requirement.
Why is “clicks before code” not the whole architecture decision? A point-and-click implementation still has execution context, lifecycle and scale limits. The choice requires evidence, not a rule that forbids code.
How do licenses, object CRUD, field security, and record sharing combine? License eligibility comes first; then evaluate object and field permissions, record sharing and the actual execution mode. A record share cannot supply missing object access.
Why can component visibility not secure a field? The same field may remain available through reports, APIs or another page. Use field permissions and inspect derived fields that can disclose related values.
What trust and lifecycle questions precede AgentExchange installation? Inspect publisher, data use, external connections, requested permissions, licensing, updates and removal/recovery. Validate dependencies and behavior before installation.
How do report type, data access, folder, and running user affect analytics? Report types define available relationships, filters and formulas define calculations, folders control access to reports, and the data/running-user model controls the audience. Test known records as each persona.
When should a standard object be preferred over a custom object? Use it when the business meaning and lifecycle fit and supported capabilities solve the requirement. Do not create a custom copy solely to avoid understanding existing behavior.
Which ownership, delete, sharing, and roll-up effects distinguish relationship types? Master-detail makes the detail dependent and can cascade deletion; lookup usually supports independent lifecycle with configurable deletion behavior. Native roll-ups require supported relationships and fields.
How does a junction object implement many-to-many? The junction stores associations between two entity sets. Decide whether two master-detail relationships fit the intended ownership and deletion consequences; the label alone supplies no duplicate policy.
What dependencies must be inventoried before a field-type change? Inspect stored values, formulas, validation, flows, reports, integrations, Apex/components and packages. Rehearse conversion and data loss/recovery before changing production metadata.
When do formula, cross-object formula, and roll-up summary fit? Formula fields derive values; cross-object formulas reference related records; roll-ups aggregate supported details. Review the resulting field audience because source-field/record restrictions need not hide the derived result.
What makes an external object different from imported Salesforce data? It exposes data managed outside Salesforce rather than copying it into ordinary records. Connectivity, availability and supported operations affect the design.
Which signals choose Import Wizard versus Data Loader? Compare object support, volume, mapping, scheduling, API requirements, error outputs and transaction/recovery options. Rehearse a representative sample.
How do external IDs support a controlled upsert? A stable external key identifies a target, but conflicting input and duplicate targets still need policy and validation. An unchanged stored value does not prove that automation side effects are idempotent.
What is the difference between validation and duplicate control? Validation enforces business conditions on writes; matching and duplicate rules address suspected duplicate records. Both need exceptions and error evidence appropriate to the integration/user.
Which Flow start fits same-record, related-record, guided, scheduled, and event work? Use suitable before-save record-triggered logic for same-record changes, after-save for related actions, screen flows for interaction, schedule-triggered for populations and event-triggered for supported event sources.
Why is before-save often efficient for same-record updates? It can change the triggering record before persistence without a separate update step. Confirm that the action is supported and does not require after-save context.
Which collection practices make Flow bulk-safe? Build collections, constrain queries and perform grouped reads/writes rather than unbounded per-item database calls. Test representative bulk data and mixed valid/invalid cases.
How do entry criteria and idempotency control repeat effects? Entry criteria limit relevant transitions; stable business keys and explicit retry handling prevent repeated effects. Check external notifications and actions separately.
What evidence should a fault path preserve? Preserve the failing operation, affected work and useful diagnostic identifier without unnecessary private data. Decide whether earlier work persists; an error screen is not rollback.
How do you diagnose a failed Flow without guessing? Reproduce with the relevant actor, version, inputs and data volume, then inspect supported debug/interview evidence and committed values. Change one evidenced cause and retest.
Which choices define a Flow Approval lifecycle? Define entry, submission, routing, sequential/parallel steps, lock ownership, allowed edits, decisions, rejection/recall and failure recovery. Coordinate a single lock for concurrent steps.
What happens to automation when record data changes during approval? Do not assume the record is immutable: administrators and explicitly allowed approvers can edit in documented cases. Decide whether material changes require new review and preserve enough evidence to explain the decision.
Why must order of execution be tested end to end? Validations, automation and side effects interact across boundaries. Confirm whether the fault is handled and which transaction can still be rolled back.
Which Agentforce boundaries make an invoked Flow safe? Constrain trusted inputs, verified identity, query scope, effective actor permissions and side effects. An agent-user action needs customer-specific filtering in addition to broad record access.
How are page layout, Lightning page, and Dynamic Forms responsibilities different? Layouts arrange record details/actions; Lightning pages compose components and activation; Dynamic Forms places fields/sections with conditional experience. None replaces authorization.
When is an action global versus object-specific? Object-specific actions have record context; global actions support broader entry points. Match inputs and resulting relationships to the chosen action surface.
When does a requested component require programmatic work? Use programmatic components when required interaction, data access or integration behavior exceeds available declarative components. Document the code/security/testing contract.
What belongs in a page activation matrix? Map app, record type, persona/profile and form factor to the expected page, actions and fields. Include inaccessible/empty/error states.
Which tests expose mobile/form-factor failure? Check supported components, action navigation, screen size, accessibility and actual network conditions. A desktop preview alone is insufficient.
How do managed, unmanaged, and unlocked package purposes differ? Managed packages support provider distribution/upgrades and protections; unmanaged packages are editable snapshots; unlocked packages support source-driven modular development. Verify specific package capabilities and dependencies.
Which sandbox properties matter to each test objective? Choose by metadata/data fidelity, capacity, refresh, privacy, integrations, availability and test purpose. A sandbox name does not prove representative data or safe outbound configuration.
What can a change set move, and what remains manual or separate? Change sets move supported metadata between related orgs. Inventory omitted dependencies, data, secrets, connections, destructive changes and manual post-deployment work separately.
How do you discover missing metadata dependencies? Trace references through fields, flows, pages, permissions and packages, then validate against the actual target. A local topological order only checks declared dependencies.
Which validations run immediately after deployment? Inspect exact deployment/test/component status and then verify required journeys, audience permissions, reports and automation. Validation success does not itself deploy anything.
What objective rollback threshold makes a release safer? Use an agreed failure signal, such as failed critical journey or incorrect access, tied to an owner and recovery artifact. Distinguish configuration reversion from committed-data repair.
What changed in the current Summer ’26 baseline? The current Summer ’26 outline emphasizes practical Flow creation, monitoring and troubleshooting, introduces foundational Agentforce and uses 18/20/32/17/13 weights. The earlier exact August 21 launch claim was not reverified.
Which current domain deserves the most practice and why? Business Logic and Process Automation is 32%. Prioritize demonstrating Flow behavior, errors and recovery while maintaining coverage of the other domains.
What annual action keeps the credential current? The dedicated policy specifies an annual Winter maintenance badge; the exam page says three per year. Use your assigned requirement and current schedule, keeping the conflict visible.
Which authoritative pages will you recheck before scheduling? Read the canonical exam guide, current credential/preparation trail, dedicated maintenance policy/schedule and actual booking terms. Do not substitute commercial course metadata.

October 29, 2026 current-source update¶

The currently published Summer ’26 exam guide states 60 multiple-choice items plus up to five unscored, 105 minutes, 73% passing, no prerequisite, and objective weights of Fundamentals 18%, Data Modeling 20%, Business Logic and Process Automation 32%, User Interface 17%, and App Deployment 13%. Its updated tasks explicitly include AgentExchange, external data sources, Agentforce business-process automation, and flow maintenance/troubleshooting. Align practice to that current outline. The official Platform App Builder preparation trailmix is a broader curated route; the indexed Spanish equivalent lists about 39 hr 20 min, while English-path duration was not confirmed. Use only the current exam guide to decide scope, and verify locale/access and the credential-assigned maintenance requirement.

Places to learn¶

This is not a complete list. Select resources by the gaps you can demonstrate. Current scope is 18/20/32/17/13; reconcile any older course map. Public metadata does not establish paid lesson quality or complete blueprint coverage. “Planning” times are our estimates.

Resource	Access	Estimated time
Official exam guide and credential page — canonical scope, identity and current contract	Public; Help required browser rendering here	20–30 min planning
Salesforce Admins certification-team interview — August 27, 2026 article/transcript on the refresh and practical skills	Public; transcript reviewed, audio not played	35–55 min reading/study planning; not a measured audio runtime
Current App Builder preparation trail — five topic groups plus overview, including AgentExchange and Agentforce material	Free Trailhead; account/org for completion	Listed 39 hr 20 min; actual practice varies
Winter ’26 maintenance module and introductory unit — release context and list-view activity; check assigned requirement	Free Trailhead; completion not performed	Listed 30 min: 5-min introduction plus 25-min activity
Relationships and Flow rollback — technical lessons supporting original exercises	Public lessons; account/org for activities	Listed 15 + 30 min; allow additional practice
Mike Wheeler App Builder course — HTTP403; prior update/coverage details not reverified	Purchase/subscription; verify terms	Earlier 23 hr 35 min figure unverified
O’Reilly App Builder video training — HTTP403; prior edition/date claims unverified	Subscription	Earlier 12 hr 3 min figure unverified
O’Reilly App Builder bootcamp — public outline with Michaela Grofčík; current booking date not exposed	Subscription/live event; interior not accessed	Eight timed sections total 5 hr, excluding untimed breaks
Salesforce Ben overview — title visible; video/date not verified in this review	Public YouTube; video not played	Title says “5 Minute”; actual runtime unverified
Focus on Force catalog — general resource listing, current App Builder product details not evaluated	Commercial; verify current terms	10–25 hr selected-study planning only
Earlier ForceAcademy change-summary link — currently exposes only a title; not evidence for current exam facts	Public commercial site; article unreadable here	No verified reading time

The preparation trail totals 20 minutes of overview plus 9 hr 25 min fundamentals, 4 hr 50 min data, 10 hr 45 min logic, 11 hr 20 min UI and 2 hr 40 min deployment. These are public planning estimates, not evidence that every badge interior was reviewed. The live bootcamp's 300 timed minutes include its 10-minute wrap-up; they exclude breaks and do not establish an upcoming event date. No paid lessons, practice answers, purchases or trial registrations were accessed. Use the official exam and maintenance sources for requirements.