Platform App Builder Interview Questions
25 expert-curated questions covering data modeling, Flow Builder, approval processes, Lightning App Builder, and app deployment.
Platform App Builder Interview Questions
Use standard objects when the built-in object (Account, Contact, Opportunity, Case, etc.) matches your business concept. Standard objects come with pre-built functionality (standard fields, list views, reports, AppExchange integrations, Sales Cloud and Service Cloud features). Extending a standard object with custom fields is always preferred over creating a parallel custom object.
Use custom objects when no standard object accurately represents the data entity (e.g., a Project, an Event, an Asset under management) or when overloading a standard object would create a confusing data model.
Key schema limits:
— 800 custom fields per object (varies by org edition)
— 25 relationship fields (lookup + master-detail combined) per object
— 2 master-detail relationships per object
— Maximum 200 custom objects per Salesforce org (Developer Edition), up to 2,000 in Enterprise/Unlimited
— 25 rollup summary fields per master-detail parent object
Use custom objects when no standard object accurately represents the data entity (e.g., a Project, an Event, an Asset under management) or when overloading a standard object would create a confusing data model.
Key schema limits:
— 800 custom fields per object (varies by org edition)
— 25 relationship fields (lookup + master-detail combined) per object
— 2 master-detail relationships per object
— Maximum 200 custom objects per Salesforce org (Developer Edition), up to 2,000 in Enterprise/Unlimited
— 25 rollup summary fields per master-detail parent object
Master-Detail:
— Tightly coupled: the child record's lifecycle, ownership, and sharing are controlled by the master.
— Cascade delete: deleting the master deletes all related detail records.
— The master field is required on the child — a detail cannot exist without a master.
— Supports Rollup Summary fields on the master (COUNT, SUM, MIN, MAX over child records).
— Maximum 2 per custom object.
Lookup:
— Loosely coupled: the child has its own OWD, owner, and sharing settings.
— Deleting the parent is configurable: clear the field, restrict the delete, or cascade.
— The lookup field is optional on the child.
— Does not support rollup summaries natively (use cross-object formulas for single values).
Junction object (Many-to-Many): A custom object with two master-detail relationships to two other objects. This is the correct data model for M:M relationships in Salesforce (e.g., Contact ↔ Campaign via CampaignMember).
— Tightly coupled: the child record's lifecycle, ownership, and sharing are controlled by the master.
— Cascade delete: deleting the master deletes all related detail records.
— The master field is required on the child — a detail cannot exist without a master.
— Supports Rollup Summary fields on the master (COUNT, SUM, MIN, MAX over child records).
— Maximum 2 per custom object.
Lookup:
— Loosely coupled: the child has its own OWD, owner, and sharing settings.
— Deleting the parent is configurable: clear the field, restrict the delete, or cascade.
— The lookup field is optional on the child.
— Does not support rollup summaries natively (use cross-object formulas for single values).
Junction object (Many-to-Many): A custom object with two master-detail relationships to two other objects. This is the correct data model for M:M relationships in Salesforce (e.g., Contact ↔ Campaign via CampaignMember).
Formula fields calculate a value dynamically at runtime using field values from the same record or related records. They are read-only and are not stored in the database.
Cross-object formulas: Reference fields on a related object via the relationship field name. Syntax:
Limitations:
— Cannot reference fields that could create circular dependencies (e.g., a formula that references another formula on the same object which references back).
— Cannot reference fields in child relationships (only parent via lookup/master-detail).
— Null handling: use
— Maximum formula length: 3,900 characters (compiled), 5,000 characters uncompiled.
— Formula field types: Text, Number, Currency, Percent, Date, Date/Time, Checkbox.
Cross-object formulas: Reference fields on a related object via the relationship field name. Syntax:
Account.BillingCity or via a lookup: Lookup_Field__r.FieldName__c. Cross-object formulas work up to 10 relationship levels deep.Limitations:
— Cannot reference fields that could create circular dependencies (e.g., a formula that references another formula on the same object which references back).
— Cannot reference fields in child relationships (only parent via lookup/master-detail).
— Null handling: use
ISBLANK() for text fields (ISNULL works on numbers only). Unchecked nulls can cause formula errors (e.g., division by zero).— Maximum formula length: 3,900 characters (compiled), 5,000 characters uncompiled.
— Formula field types: Text, Number, Currency, Percent, Date, Date/Time, Checkbox.
ISNEW() returns true when the record is being created (not on updates). Use it to enforce required-on-create conditions.
ISCHANGED(field) returns true if the field value changed during an update. Example: prevent changing the Status from "Closed" back to "Open":
PRIORVALUE(field) returns the previous value of a field before the current edit — only meaningful in update context. Combine with ISCHANGED for targeted change validation.
Cross-object validation: Reference parent record fields using the lookup relationship syntax in validation rules.
Bypassing for specific users:
— Use
— Error placement: set the error to a specific field for inline display, or "Top of Page" for a general message.
ISCHANGED(field) returns true if the field value changed during an update. Example: prevent changing the Status from "Closed" back to "Open":
ISCHANGED(Status__c) && PRIORVALUE(Status__c) = "Closed"PRIORVALUE(field) returns the previous value of a field before the current edit — only meaningful in update context. Combine with ISCHANGED for targeted change validation.
Cross-object validation: Reference parent record fields using the lookup relationship syntax in validation rules.
Bypassing for specific users:
— Use
$Profile.Name = "System Administrator" or a custom permission: $Permission.Bypass_Validation_Rules in the validation rule formula with a leading NOT(...) or as a condition to short-circuit evaluation.— Error placement: set the error to a specific field for inline display, or "Top of Page" for a general message.
Rollup Summary fields aggregate values from child records in a master-detail relationship up to the master record. Supported aggregate functions:
— COUNT: Number of child records matching the filter criteria.
— SUM: Sum of a numeric field across child records.
— MIN/MAX: Minimum or maximum value of a date, number, or currency field.
Limitations:
— Only available on the master object in a master-detail relationship (not lookup).
— Maximum 25 rollup summary fields per object.
— Cannot reference formula fields in the rollup calculation.
— Rollup summary recalculations can be resource-intensive on large datasets. Mass data operations that update many detail records may need to be broken into batches to avoid triggering excessive recalculations.
— Cannot be used in custom report types as a grouping field without limitations.
Alternative for lookups: Use cross-object formula for single-record reference (no aggregation), or Apex/Flow for aggregated rollups on lookup relationships.
— COUNT: Number of child records matching the filter criteria.
— SUM: Sum of a numeric field across child records.
— MIN/MAX: Minimum or maximum value of a date, number, or currency field.
Limitations:
— Only available on the master object in a master-detail relationship (not lookup).
— Maximum 25 rollup summary fields per object.
— Cannot reference formula fields in the rollup calculation.
— Rollup summary recalculations can be resource-intensive on large datasets. Mass data operations that update many detail records may need to be broken into batches to avoid triggering excessive recalculations.
— Cannot be used in custom report types as a grouping field without limitations.
Alternative for lookups: Use cross-object formula for single-record reference (no aggregation), or Apex/Flow for aggregated rollups on lookup relationships.
Dynamic Forms: Enable moving individual fields and field sections out of the page layout and into the Lightning record page directly. Each field or section can have visibility conditions — rules that show or hide them based on record field values, user profile, permission sets, or device type. This replaces the need for multiple page layouts per record type for display-only variations.
Dynamic Actions: Move action buttons from the page layout action bar to the Lightning page, where visibility conditions can be applied per button. Example: Show the "Convert" button only when Status equals "Qualified".
Component visibility rules: Any standard or custom LWC/Aura component placed on a Lightning page can have visibility rules applied in the Properties panel. Condition types include:
— Record field value (equals, not equals, contains, starts with, is null)
— User profile or permission set
— Device form factor (desktop vs mobile)
Multiple conditions can be combined with AND/OR logic. Dynamic Forms require the record page to be configured for a specific object and the feature to be activated for that object in Setup.
Dynamic Actions: Move action buttons from the page layout action bar to the Lightning page, where visibility conditions can be applied per button. Example: Show the "Convert" button only when Status equals "Qualified".
Component visibility rules: Any standard or custom LWC/Aura component placed on a Lightning page can have visibility rules applied in the Properties panel. Condition types include:
— Record field value (equals, not equals, contains, starts with, is null)
— User profile or permission set
— Device form factor (desktop vs mobile)
Multiple conditions can be combined with AND/OR logic. Dynamic Forms require the record page to be configured for a specific object and the feature to be activated for that object in Setup.
Record types allow you to offer different business processes, page layouts, and picklist values on the same object for different user groups.
Key capabilities:
— Picklist values: Each record type can restrict picklist values to a subset of the master picklist. Unused values are hidden from that record type's users.
— Page layouts: A specific page layout is assigned to each record type per profile (matrix: record type × profile = layout).
— Business processes: For Leads (Lead Processes), Opportunities (Sales Processes), Cases (Support Processes), and Solutions — define which Stage/Status values are available per record type.
Profile assignment: In a profile's Record Type settings, you select which record types are available to that profile, and set the default record type. When a user creates a new record, if they have access to multiple record types, a picker is displayed.
Permission sets: Record type access can also be granted via permission sets (Object Settings > Record Types).
Key capabilities:
— Picklist values: Each record type can restrict picklist values to a subset of the master picklist. Unused values are hidden from that record type's users.
— Page layouts: A specific page layout is assigned to each record type per profile (matrix: record type × profile = layout).
— Business processes: For Leads (Lead Processes), Opportunities (Sales Processes), Cases (Support Processes), and Solutions — define which Stage/Status values are available per record type.
Profile assignment: In a profile's Record Type settings, you select which record types are available to that profile, and set the default record type. When a user creates a new record, if they have access to multiple record types, a picker is displayed.
Permission sets: Record type access can also be granted via permission sets (Object Settings > Record Types).
Screen Flow: Presents a UI to the user — a guided multi-step wizard. Launched from Lightning pages, quick actions, community pages, or embedded in a VF page. Used for complex data entry, guided processes, and step-by-step wizards.
Record-Triggered Flow: Automatically fires when a record is created, updated, or deleted. Before-save flows run in the same transaction as the DML (fast, no separate transaction); after-save flows run after the record is committed. Replaces most workflow rules and Process Builder use cases.
Scheduled Flow: Runs at a specified time and frequency on a batch of records matching filter criteria. Used for nightly/weekly batch operations (send reminder emails, update fields on old records).
Platform Event-Triggered Flow: Fires when a specific Platform Event message is received. Near-real-time event processing with decoupled architecture.
Auto-Launched Flow (no trigger): Called programmatically from Apex, another flow, a process, or an API. No UI, no automatic trigger — used as a reusable sub-flow or invoked from code.
Record-Triggered Flow: Automatically fires when a record is created, updated, or deleted. Before-save flows run in the same transaction as the DML (fast, no separate transaction); after-save flows run after the record is committed. Replaces most workflow rules and Process Builder use cases.
Scheduled Flow: Runs at a specified time and frequency on a batch of records matching filter criteria. Used for nightly/weekly batch operations (send reminder emails, update fields on old records).
Platform Event-Triggered Flow: Fires when a specific Platform Event message is received. Near-real-time event processing with decoupled architecture.
Auto-Launched Flow (no trigger): Called programmatically from Apex, another flow, a process, or an API. No UI, no automatic trigger — used as a reusable sub-flow or invoked from code.
Flows can process up to 200 records per transaction (matching Apex trigger batch size). Common governor limit pitfalls and how to avoid them:
SOQL in loops: Never use a Get Records element inside a loop. Collect all filter values into a collection variable first, then use a single Get Records element outside the loop with a filter condition on the collection. This reduces SOQL queries from N to 1.
DML in loops: Accumulate records to create/update/delete in collection variables. Use a single Create Records, Update Records, or Delete Records element after the loop to bulk-process the collection in one DML statement.
Limit nesting: Deeply nested decision/loop structures increase transaction complexity. Use sub-flows (Auto-Launched Flow called from another flow) to modularise logic and improve maintainability.
Before-save vs after-save: Use before-save record-triggered flows for field updates on the triggering record — they are faster and don't consume an additional DML operation. Use after-save for creating/updating related records.
Flow limits: Maximum 250 DML statements, 100 SOQL queries per transaction (shared with triggers and Apex in the same transaction).
SOQL in loops: Never use a Get Records element inside a loop. Collect all filter values into a collection variable first, then use a single Get Records element outside the loop with a filter condition on the collection. This reduces SOQL queries from N to 1.
DML in loops: Accumulate records to create/update/delete in collection variables. Use a single Create Records, Update Records, or Delete Records element after the loop to bulk-process the collection in one DML statement.
Limit nesting: Deeply nested decision/loop structures increase transaction complexity. Use sub-flows (Auto-Launched Flow called from another flow) to modularise logic and improve maintainability.
Before-save vs after-save: Use before-save record-triggered flows for field updates on the triggering record — they are faster and don't consume an additional DML operation. Use after-save for creating/updating related records.
Flow limits: Maximum 250 DML statements, 100 SOQL queries per transaction (shared with triggers and Apex in the same transaction).
An Approval Process routes records for human approval through a defined sequence of steps. Components:
Entry criteria: Formula or filter conditions the record must meet to enter the process. If criteria are not met, the record is rejected (optionally with a message) or another process is tried.
Initial submission actions: Field updates, email alerts, tasks, or outbound messages triggered when the record is first submitted for approval. Records are locked for editing by non-approvers during the process.
Approval steps: Each step defines: (a) filter criteria to determine if this step applies; (b) assigned approver — record owner, queue, related user field, or specific user; (c) approval actions; (d) rejection actions; (e) whether to go back to the previous step or to the final rejection actions on rejection.
Final approval/rejection actions: Actions taken when the process completes (fully approved or finally rejected).
Recall actions: Actions triggered when a submitter recalls a submitted record before approval.
Jump to step: On approval or rejection, you can route back to a specific earlier step for re-review.
Entry criteria: Formula or filter conditions the record must meet to enter the process. If criteria are not met, the record is rejected (optionally with a message) or another process is tried.
Initial submission actions: Field updates, email alerts, tasks, or outbound messages triggered when the record is first submitted for approval. Records are locked for editing by non-approvers during the process.
Approval steps: Each step defines: (a) filter criteria to determine if this step applies; (b) assigned approver — record owner, queue, related user field, or specific user; (c) approval actions; (d) rejection actions; (e) whether to go back to the previous step or to the final rejection actions on rejection.
Final approval/rejection actions: Actions taken when the process completes (fully approved or finally rejected).
Recall actions: Actions triggered when a submitter recalls a submitted record before approval.
Jump to step: On approval or rejection, you can route back to a specific earlier step for re-review.
Lightning Apps are configured in Setup > App Manager and define the user experience within the app switcher.
Navigation items: Add standard/custom objects, Lightning pages, Visualforce pages, flows, utility bar items, and external URLs. Drag to reorder. Objects added here appear in the app's navigation bar. Users can personalise their navigation (unless locked by admin).
Utility bar: A fixed panel at the bottom of the app containing utility items (components) accessible without leaving the current page. Standard utility items include: History, Recent Items, Macros, Notes, Open CTI (softphone), Einstein Chat. Custom LWC components can also be added as utility items.
Custom branding: Upload a custom logo (SVG or PNG, max 100 KB), select a primary colour for the app header. Enterprise and Unlimited editions support custom themes (Setup > Themes and Branding) with custom brand colours, logo, and default background image.
User personalization: "Allow users to personalise the nav bar" toggle controls whether users can add/remove/reorder items from their personal navigation.
Navigation items: Add standard/custom objects, Lightning pages, Visualforce pages, flows, utility bar items, and external URLs. Drag to reorder. Objects added here appear in the app's navigation bar. Users can personalise their navigation (unless locked by admin).
Utility bar: A fixed panel at the bottom of the app containing utility items (components) accessible without leaving the current page. Standard utility items include: History, Recent Items, Macros, Notes, Open CTI (softphone), Einstein Chat. Custom LWC components can also be added as utility items.
Custom branding: Upload a custom logo (SVG or PNG, max 100 KB), select a primary colour for the app header. Enterprise and Unlimited editions support custom themes (Setup > Themes and Branding) with custom brand colours, logo, and default background image.
User personalization: "Allow users to personalise the nav bar" toggle controls whether users can add/remove/reorder items from their personal navigation.
Quick Actions are customisable actions that appear in the action bar of a Lightning record page or on the Chatter feed. They open a compact action layout (not a full page layout) in a modal dialog.
Types:
— Object-specific actions: Tied to a specific object and appear when viewing records of that type.
— Global actions: Available across the entire org (from the global header's New button).
Action layouts: A separate, trimmed-down layout defined specifically for the quick action modal — typically 4–8 fields rather than a full page layout.
Predefined field values: You can set default values for fields in a quick action (e.g., pre-populate the Status field when creating a Task from a Contact).
Custom buttons (legacy): Traditional buttons defined in Setup with URL formulas or JavaScript. JavaScript custom buttons are not supported in Lightning Experience (deprecated). All JavaScript button logic should be migrated to LWC actions or Screen Flows. URL-based buttons still work but have limited capability compared to flows.
Types:
— Object-specific actions: Tied to a specific object and appear when viewing records of that type.
— Global actions: Available across the entire org (from the global header's New button).
Action layouts: A separate, trimmed-down layout defined specifically for the quick action modal — typically 4–8 fields rather than a full page layout.
Predefined field values: You can set default values for fields in a quick action (e.g., pre-populate the Status field when creating a Task from a Contact).
Custom buttons (legacy): Traditional buttons defined in Setup with URL formulas or JavaScript. JavaScript custom buttons are not supported in Lightning Experience (deprecated). All JavaScript button logic should be migrated to LWC actions or Screen Flows. URL-based buttons still work but have limited capability compared to flows.
Einstein Prediction Builder: Create custom AI predictions without code using a wizard. Prediction types:
— Binary: Will this record X? (e.g., "Will this lead convert?") — outputs a likelihood score and label.
— Numeric: What will the value of this field be? (e.g., predicted close amount).
— Multiclass: Which category will this record fall into? (Salesforce typically surfaces this via custom use cases.)
Predictions are displayed as fields on the record page and can be used in list views, reports, and flow conditions.
Einstein Next Best Action: Defines recommendation strategies (using Flow, APEX, or Recommendation objects) that present the most relevant next action to a user on a record page. App Builders configure the strategy, display conditions, and the recommendation actions surfaced.
Einstein Recommendation Builder: Builds product/content recommendation models for Experience Cloud and emails. Configuration via Setup, no code required.
— Binary: Will this record X? (e.g., "Will this lead convert?") — outputs a likelihood score and label.
— Numeric: What will the value of this field be? (e.g., predicted close amount).
— Multiclass: Which category will this record fall into? (Salesforce typically surfaces this via custom use cases.)
Predictions are displayed as fields on the record page and can be used in list views, reports, and flow conditions.
Einstein Next Best Action: Defines recommendation strategies (using Flow, APEX, or Recommendation objects) that present the most relevant next action to a user on a record page. App Builders configure the strategy, display conditions, and the recommendation actions surfaced.
Einstein Recommendation Builder: Builds product/content recommendation models for Experience Cloud and emails. Configuration via Setup, no code required.
Change Sets: GUI-based metadata migration between orgs connected via Deployment Connection. Outbound change sets are created in the source org; inbound sets are validated and deployed in the target org. Limitations: one-directional, cannot delete metadata, not all metadata types supported, no version control.
Salesforce CLI (sf): Command-line tool supporting source-driven development. Commands:
Sandbox types for testing: Developer (5 MB storage), Developer Pro (1 GB), Partial Copy (5 GB with sample data template), Full Copy (production data replica). Refreshed from production on demand.
Sandbox refresh and data templates: A data template (configured in Setup) specifies which standard/custom objects and their relationships are included when refreshing a Partial Copy sandbox.
Third-party tools: Gearset, Copado, AutoRABIT, and Flosum provide version control integration, automated testing, and deployment pipeline management beyond native Salesforce tools.
Salesforce CLI (sf): Command-line tool supporting source-driven development. Commands:
sf project deploy start and sf project retrieve start for deployment and retrieval. Supports all metadata types and can be integrated into CI/CD pipelines.Sandbox types for testing: Developer (5 MB storage), Developer Pro (1 GB), Partial Copy (5 GB with sample data template), Full Copy (production data replica). Refreshed from production on demand.
Sandbox refresh and data templates: A data template (configured in Setup) specifies which standard/custom objects and their relationships are included when refreshing a Partial Copy sandbox.
Third-party tools: Gearset, Copado, AutoRABIT, and Flosum provide version control integration, automated testing, and deployment pipeline management beyond native Salesforce tools.
Salesforce DX (Developer Experience) is a source-driven development model using the Salesforce CLI.
Scratch orgs: Temporary, configurable orgs created from a project definition file (
Project structure: A DX project has a
Source tracking: Scratch orgs track which local files have changed vs the org and vice versa. This enables precise push/pull of only changed components.
Commands:
—
—
—
Scratch orgs: Temporary, configurable orgs created from a project definition file (
project-scratch-def.json). They are disposable (1–30 day lifespan), not copies of production, and designed for isolated feature development and automated testing in CI/CD pipelines.Project structure: A DX project has a
sfdx-project.json file defining the namespace and source paths. Metadata lives in the force-app/main/default directory, organised in subfolders per metadata type (objects, classes, lwc, flows, etc.).Source tracking: Scratch orgs track which local files have changed vs the org and vice versa. This enables precise push/pull of only changed components.
Commands:
—
sf project deploy start --target-org scratchOrgAlias: Push local source to the org.—
sf project retrieve start --target-org scratchOrgAlias: Pull org changes back to local source.—
sf org create scratch --target-dev-hub DevHub --definition-file project-scratch-def.json --alias myOrg: Create a new scratch org.
The Salesforce Certified Platform App Builder exam (65 questions, 105 minutes, 63% pass mark) covers these domains with approximate weightings:
Data Modeling and Management: 23% — Objects, relationships, fields, schema limits, formula fields, rollup summaries, data management tools.
Business Logic and Process Automation: 28% — Flow Builder (all types), validation rules, approval processes, when to use which automation tool.
User Interface: 22% — Lightning App Builder, dynamic forms/actions, page layouts, record types, quick actions, mobile layouts.
Reporting: 9% — Report types, dashboard components, report filters, custom report types.
Mobile: 8% — Salesforce Mobile app navigation, mobile-optimised pages, offline limitations, Field Service Mobile.
App Deployment: 10% — Change sets, sandboxes, Salesforce DX basics, AppExchange managed packages, deployment dependencies.
The largest domains (Business Logic and Data Modeling) together account for over half the exam — focus preparation effort there first.
Data Modeling and Management: 23% — Objects, relationships, fields, schema limits, formula fields, rollup summaries, data management tools.
Business Logic and Process Automation: 28% — Flow Builder (all types), validation rules, approval processes, when to use which automation tool.
User Interface: 22% — Lightning App Builder, dynamic forms/actions, page layouts, record types, quick actions, mobile layouts.
Reporting: 9% — Report types, dashboard components, report filters, custom report types.
Mobile: 8% — Salesforce Mobile app navigation, mobile-optimised pages, offline limitations, Field Service Mobile.
App Deployment: 10% — Change sets, sandboxes, Salesforce DX basics, AppExchange managed packages, deployment dependencies.
The largest domains (Business Logic and Data Modeling) together account for over half the exam — focus preparation effort there first.
Page layout optimisation best practices:
— Place the most critical fields in the top-left section (users read top-to-bottom, left-to-right).
— Mark truly required fields as required on the layout; use validation rules for conditional requirements.
— Mark calculated or system-managed fields as read-only on the layout to prevent accidental edits.
— Group related fields in named sections with collapsible option for less frequently used fields.
— Configure related lists: show only relevant related lists; set default columns and sort order.
— Use separate page layouts per record type for different business processes rather than trying to fit all use cases on one layout.
Compact layouts: Define the subset of fields displayed in record highlights panels (the top section of a Lightning record page) and in hover cards when mousing over a lookup field. Also used as the mobile quick view card. Best practice: include the 4–5 most important identifying and status fields. The first field in the compact layout is the display name in lookup links.
— Place the most critical fields in the top-left section (users read top-to-bottom, left-to-right).
— Mark truly required fields as required on the layout; use validation rules for conditional requirements.
— Mark calculated or system-managed fields as read-only on the layout to prevent accidental edits.
— Group related fields in named sections with collapsible option for less frequently used fields.
— Configure related lists: show only relevant related lists; set default columns and sort order.
— Use separate page layouts per record type for different business processes rather than trying to fit all use cases on one layout.
Compact layouts: Define the subset of fields displayed in record highlights panels (the top section of a Lightning record page) and in hover cards when mousing over a lookup field. Also used as the mobile quick view card. Best practice: include the 4–5 most important identifying and status fields. The first field in the compact layout is the display name in lookup links.
Before-save record-triggered flows:
— Run in the same transaction as the record save, before it is committed to the database.
— Can update fields on the triggering record directly (using the $Record variable) without an additional Update Records DML statement.
— Faster performance: no extra DML transaction.
— Use for: field defaulting, field population based on logic, setting fields before save (equivalent to before-trigger field updates in Apex).
— Cannot create or update other records (no DML on other objects).
After-save record-triggered flows:
— Run after the record is committed to the database.
— Can query and update related records, create new records, send emails, call Apex, and interact with external systems.
— Shares the same governor limits as the triggering transaction (shared SOQL, DML limits with triggers and Apex in the same transaction).
— Use for: creating child records, updating parent records, sending notifications, Journey Builder entry events.
— Run in the same transaction as the record save, before it is committed to the database.
— Can update fields on the triggering record directly (using the $Record variable) without an additional Update Records DML statement.
— Faster performance: no extra DML transaction.
— Use for: field defaulting, field population based on logic, setting fields before save (equivalent to before-trigger field updates in Apex).
— Cannot create or update other records (no DML on other objects).
After-save record-triggered flows:
— Run after the record is committed to the database.
— Can query and update related records, create new records, send emails, call Apex, and interact with external systems.
— Shares the same governor limits as the triggering transaction (shared SOQL, DML limits with triggers and Apex in the same transaction).
— Use for: creating child records, updating parent records, sending notifications, Journey Builder entry events.
A Scheduled Flow (also called a Scheduled Path in some contexts) runs on a defined schedule to process a batch of records. Configuration in Flow Builder:
Schedule: Set the start date/time, frequency (once, daily, weekly), and time zone. Supports running at specific times of day.
Object and filter: Specify the object to query and optional filter conditions to narrow which records are processed (e.g., Opportunities where Close Date = TODAY and Stage = "Prospecting").
Batch processing: The flow processes records in batches of up to 200. For each batch, the flow's entire logic executes within a single transaction context.
Common use cases:
— Nightly field updates (e.g., set Overdue flag if Due Date has passed)
— Weekly digest email preparation (populate a reporting DE)
— Escalation logic (change priority after N days without activity)
Limits: Scheduled flows count against the daily flow interview allocation. Large record sets should be filtered to avoid processing millions of records in a single scheduled run — use incremental date filters (LAST_N_DAYS) to scope the batch.
Schedule: Set the start date/time, frequency (once, daily, weekly), and time zone. Supports running at specific times of day.
Object and filter: Specify the object to query and optional filter conditions to narrow which records are processed (e.g., Opportunities where Close Date = TODAY and Stage = "Prospecting").
Batch processing: The flow processes records in batches of up to 200. For each batch, the flow's entire logic executes within a single transaction context.
Common use cases:
— Nightly field updates (e.g., set Overdue flag if Due Date has passed)
— Weekly digest email preparation (populate a reporting DE)
— Escalation logic (change priority after N days without activity)
Limits: Scheduled flows count against the daily flow interview allocation. Large record sets should be filtered to avoid processing millions of records in a single scheduled run — use incremental date filters (LAST_N_DAYS) to scope the batch.
Custom buttons and links are configured in Setup > Object Manager > Buttons, Links, and Actions for each object.
URL buttons: Navigate to a URL, optionally using formula-based dynamic URLs that reference record fields. Example: a button that navigates to an external system with the record ID appended in the query string. URL buttons still work in Lightning Experience.
JavaScript buttons (deprecated): Used to execute JavaScript in Classic. JavaScript buttons do not function in Lightning Experience and must be migrated.
Migration options:
— Screen Flow: Replace simple JS button logic (pre-populate fields, navigate) with a Screen Flow invoked via a quick action.
— LWC Action: Build a Lightning Web Component invoked as an action for more complex logic requiring component UI.
— Headless Quick Action (LWC): An LWC component without a screen that executes Apex logic when the action button is clicked.
Use the Salesforce Lightning Migration Assistant or review the JSforce Locker Service documentation to identify JavaScript buttons requiring migration.
URL buttons: Navigate to a URL, optionally using formula-based dynamic URLs that reference record fields. Example: a button that navigates to an external system with the record ID appended in the query string. URL buttons still work in Lightning Experience.
JavaScript buttons (deprecated): Used to execute JavaScript in Classic. JavaScript buttons do not function in Lightning Experience and must be migrated.
Migration options:
— Screen Flow: Replace simple JS button logic (pre-populate fields, navigate) with a Screen Flow invoked via a quick action.
— LWC Action: Build a Lightning Web Component invoked as an action for more complex logic requiring component UI.
— Headless Quick Action (LWC): An LWC component without a screen that executes Apex logic when the action button is clicked.
Use the Salesforce Lightning Migration Assistant or review the JSforce Locker Service documentation to identify JavaScript buttons requiring migration.
Report types: Tabular (simple list), Summary (grouped with subtotals), Matrix (row and column groupings), Joined (multiple report blocks from different objects).
Custom report types: Define the object relationships and available fields for reports. Use when standard report types don't include the object combination needed. Set the primary object and up to 3 related objects; configure "with or without" related records to control row inclusion.
Report filters: Standard filters (date range, owner), field filters, cross-filters (show records with/without related records matching criteria), row-limit filters for summary/matrix reports.
Dashboard components: Charts (bar, line, pie, donut, funnel, scatter), metric (single number KPI), gauge, table, and Visualforce/LWC custom components. Each component is driven by a single report.
Dynamic dashboards: Use the "Run as Logged-in User" setting so each viewer sees data filtered to their own record access — eliminates the need to create separate dashboards per team.
Limits: Dashboards limited to 20 components; reports limited to 2,000 rows in export, 50,000 rows with Printable View.
Custom report types: Define the object relationships and available fields for reports. Use when standard report types don't include the object combination needed. Set the primary object and up to 3 related objects; configure "with or without" related records to control row inclusion.
Report filters: Standard filters (date range, owner), field filters, cross-filters (show records with/without related records matching criteria), row-limit filters for summary/matrix reports.
Dashboard components: Charts (bar, line, pie, donut, funnel, scatter), metric (single number KPI), gauge, table, and Visualforce/LWC custom components. Each component is driven by a single report.
Dynamic dashboards: Use the "Run as Logged-in User" setting so each viewer sees data filtered to their own record access — eliminates the need to create separate dashboards per team.
Limits: Dashboards limited to 20 components; reports limited to 2,000 rows in export, 50,000 rows with Printable View.
The Salesforce Mobile App uses the same Lightning page configurations as desktop, with mobile-specific optimisations:
Mobile navigation: Configured in Setup > Salesforce Mobile App > Navigation. Admins define the items available in the mobile app navigation (the hamburger menu). The navigation is separate from the desktop Lightning App navigation. Best practice: limit to the most frequently used objects for a clean mobile experience.
Mobile-optimised page layouts: Record pages built in Lightning App Builder can use the "Phone" form factor view to arrange components differently for small screens. Fields and components can be placed in different positions or hidden on mobile vs desktop using dynamic visibility conditions on the form factor.
Compact layouts: Define the record card format shown in list views on mobile and in the highlights panel.
Offline capability: Not available in the standard Salesforce Mobile app for arbitrary objects. Field Service Mobile (a separate app) provides offline capabilities for field service workers. For standard mobile, users need a network connection.
Quick actions: Optimise for mobile by keeping action layouts to 4–6 fields; complex layouts are hard to use on small screens.
Mobile navigation: Configured in Setup > Salesforce Mobile App > Navigation. Admins define the items available in the mobile app navigation (the hamburger menu). The navigation is separate from the desktop Lightning App navigation. Best practice: limit to the most frequently used objects for a clean mobile experience.
Mobile-optimised page layouts: Record pages built in Lightning App Builder can use the "Phone" form factor view to arrange components differently for small screens. Fields and components can be placed in different positions or hidden on mobile vs desktop using dynamic visibility conditions on the form factor.
Compact layouts: Define the record card format shown in list views on mobile and in the highlights panel.
Offline capability: Not available in the standard Salesforce Mobile app for arbitrary objects. Field Service Mobile (a separate app) provides offline capabilities for field service workers. For standard mobile, users need a network connection.
Quick actions: Optimise for mobile by keeping action layouts to 4–6 fields; complex layouts are hard to use on small screens.
AppExchange managed packages are pre-built applications installed from Salesforce's marketplace. Key considerations:
Security review: All AppExchange packages listed publicly pass Salesforce's security review. Always review the package's permissions and data access requirements before installation.
Namespace prefix: Managed package components use a namespace prefix (e.g.,
Governor limits sharing: Managed package Apex and triggers share the same governor limits as your org's custom code within the same transaction. High-volume packages can contribute to limit consumption.
Version upgrades: Managed packages can be upgraded to newer versions. Test upgrades in a sandbox before applying to production. Some upgrades may change API behaviour or deprecate features.
Uninstallation: Managed packages can typically be uninstalled if you remove all dependencies (custom fields referencing package objects, flows, reports). Uninstall in a sandbox first to identify and resolve dependency issues.
Test coverage: Package Apex code is covered by the publisher's test classes, not yours — you only need to maintain coverage for your own custom code.
Security review: All AppExchange packages listed publicly pass Salesforce's security review. Always review the package's permissions and data access requirements before installation.
Namespace prefix: Managed package components use a namespace prefix (e.g.,
cpq__Quote__c). Customising managed package components is limited — you can extend them but not modify the package's own code.Governor limits sharing: Managed package Apex and triggers share the same governor limits as your org's custom code within the same transaction. High-volume packages can contribute to limit consumption.
Version upgrades: Managed packages can be upgraded to newer versions. Test upgrades in a sandbox before applying to production. Some upgrades may change API behaviour or deprecate features.
Uninstallation: Managed packages can typically be uninstalled if you remove all dependencies (custom fields referencing package objects, flows, reports). Uninstall in a sandbox first to identify and resolve dependency issues.
Test coverage: Package Apex code is covered by the publisher's test classes, not yours — you only need to maintain coverage for your own custom code.
Deployment dependencies are metadata components that a component requires in order to be successfully deployed. Salesforce validates dependencies during change set deployment; missing dependencies cause validation failures.
Common dependency chains:
— A custom field's formula references another custom field → both must be in the change set.
— A validation rule references a record type → the record type must already exist in the target org.
— A Flow references a custom object or field → the object/field must exist in target.
— A report type references a custom object → the object must exist.
— An email template references a letterhead → the letterhead must be included.
Resolution strategies:
— Add dependencies to the change set (use "View/Add Dependencies" in the Outbound Change Set).
— Deploy dependencies in a prior change set first.
— Validate the change set against the target before deploying — the validation report identifies missing dependencies without making changes.
Deployment order: Objects before fields, fields before validation rules/formulas, objects before relationships.
Common dependency chains:
— A custom field's formula references another custom field → both must be in the change set.
— A validation rule references a record type → the record type must already exist in the target org.
— A Flow references a custom object or field → the object/field must exist in target.
— A report type references a custom object → the object must exist.
— An email template references a letterhead → the letterhead must be included.
Resolution strategies:
— Add dependencies to the change set (use "View/Add Dependencies" in the Outbound Change Set).
— Deploy dependencies in a prior change set first.
— Validate the change set against the target before deploying — the validation report identifies missing dependencies without making changes.
Deployment order: Objects before fields, fields before validation rules/formulas, objects before relationships.
Salesforce's automation strategy prioritises Flow Builder as the single declarative automation tool. Decision framework:
Use Flow Builder (preferred declarative tool):
— Record-triggered flows replace all workflow rules and most Process Builder use cases.
— Screen flows replace custom VF pages for guided user processes.
— Scheduled flows replace time-based workflow actions and batch Apex for simple field updates.
— Auto-launched flows replace simple Apex called from other processes.
Process Builder (retiring): Salesforce has announced eventual retirement. Migrate all Process Builder processes to Flows before they are sunset. No new Process Builder development should be started.
Workflow Rules (retired): Already retired in 2023. All existing workflow rules should be migrated to Flows.
Use Apex when:
— Complex looping logic, data structures (Maps, Sets, nested collections) exceed Flow capabilities.
— Callouts to external systems with complex authentication or response parsing.
— Batch processing of millions of records (Batch Apex).
— Unit-testable, version-controlled code is required for compliance.
— Performance-critical paths where Flow overhead is measurable.
The App Builder certification expects knowledge of the declarative approach — Apex questions are outside the scope of the certification exam.
Use Flow Builder (preferred declarative tool):
— Record-triggered flows replace all workflow rules and most Process Builder use cases.
— Screen flows replace custom VF pages for guided user processes.
— Scheduled flows replace time-based workflow actions and batch Apex for simple field updates.
— Auto-launched flows replace simple Apex called from other processes.
Process Builder (retiring): Salesforce has announced eventual retirement. Migrate all Process Builder processes to Flows before they are sunset. No new Process Builder development should be started.
Workflow Rules (retired): Already retired in 2023. All existing workflow rules should be migrated to Flows.
Use Apex when:
— Complex looping logic, data structures (Maps, Sets, nested collections) exceed Flow capabilities.
— Callouts to external systems with complex authentication or response parsing.
— Batch processing of millions of records (Batch Apex).
— Unit-testable, version-controlled code is required for compliance.
— Performance-critical paths where Flow overhead is measurable.
The App Builder certification expects knowledge of the declarative approach — Apex questions are outside the scope of the certification exam.