Salesforce Platform App Builder Course Notes

Highest-weight domain. Start by identifying whether the requirement is a calculated value, a save-time guardrail, an aggregate, an approval, or automation. Formula fields calculate without storing updates; validation rules block invalid saves; roll-up summaries aggregate directly related detail records in master-detail; approvals route records for review; Flow handles interactive, record-driven, scheduled, and reusable automation. For record-triggered Flow, use before-save for efficient same-record field updates and after-save when you must create/update related records or perform actions. Prevent repeat execution with precise start conditions and change detection; design for bulk operations and fault handling.

• Using Flow to store a value that a formula can calculate dynamically.

• Translate the requirement into WHEN, WHAT, and WHERE: when does it run, what must change, and is the change on the triggering record or elsewhere?

Think in layers and context. Prefer declarative tools when they meet the requirement; use programmatic customization when the requirement exceeds platform configuration. Evaluate AgentExchange solutions for capability, trust, permissions, and rollout—not as a bypass around Salesforce security. For access, distinguish object/field permissions from record sharing. OWD establishes the record-sharing baseline; role hierarchy, sharing rules, and manual sharing can open access. Reports and dashboards test format, grouping, formulas, running-user behavior, and drill-down. Mobile questions often hinge on global versus object-specific actions, compact layouts, and form-factor-aware page design.

• Changing OWD to solve object- or field-permission problems.

• Access question? Ask three questions in order: object, field, then record.

Model lifecycle first: can the child exist without the parent, who owns it, what happens on delete, and is native roll-up required? Lookup is loose/optional and keeps independent ownership/sharing; master-detail is tightly coupled and supports native roll-up summaries on the master. Use junction objects for many-to-many relationships with attributes on the association. Select field types for how data is stored and used, and analyze dependencies before type changes. Use External ID plus upsert for stable external keys. Choose Data Import Wizard for supported, smaller, guided imports and Data Loader for larger or repeatable/API-driven jobs. External objects represent data stored outside Salesforce rather than copying it into normal Salesforce objects.

• Choosing master-detail merely because records are related, without checking lifecycle/ownership needs.

• Relationship questions are lifecycle questions disguised as schema questions.

Keep UI layers separate. Record types select business processes, picklist values, and page-layout assignments. Page layouts control fields, related lists, buttons, and actions in the traditional record layout. Lightning App Builder composes app/home/record pages from components and controls page activation/assignment. Dynamic Forms places individual fields/sections on supported record pages and applies visibility rules; Dynamic Actions applies visibility to actions. Compact layouts drive highlights panels. Component visibility can depend on record data, user permissions, and form factor. Use custom Lightning components only when standard/declarative components cannot meet the interaction or presentation requirement.

• Using OWD/FLS as a substitute for component or action visibility.

• Record type selects business process/picklists/layout assignment; it does not grant record access.

Know the real sandbox types and the deployment path. Developer is metadata-focused isolated development; Developer Pro provides more capacity for development/QA; Partial Copy includes a template-selected sample of production data and is common for UAT/integration testing; Full is the closest production replica and supports performance/load testing and staging. Change sets move supported metadata between related orgs with deployment connections; they do not automatically solve missing dependencies. Validate inbound changes in the target before committing. Managed packages are designed for controlled distribution and upgrades; unmanaged packages are editable templates without a managed upgrade path. Always verify permissions, assignments, integrations, and critical business paths after deployment.

• Inventing generic 'testing' or 'staging' sandbox types instead of choosing from Developer, Developer Pro, Partial Copy, and Full.

• Representative subset = Partial Copy; production-scale/performance = Full.