Salesforce Application Architect

The data model is the part of an app that is hardest to change. You design objects, fields and relationships, choose among lookups, master-detail and junctions, and keep derived values calculated instead of duplicated.

• Objects, fields and data types
• Lookup, master-detail and junction relationships
• Record types and picklists
• Formula and roll-up summary fields
• Schema Builder and the object diagram
• Importing and exporting data

You build A data model for a small application, with relationships and derived fields.

Most business logic can stay declarative. You use validation rules, flows and approvals to enforce and move work along, test them, and recognize when automation has become too tangled to trust.

• Validation rules that guide users
• Record-triggered and screen flows
• Approval processes
• Testing and debugging flows
• Avoiding overlapping automations
• Spotting when flow has reached its limit

You build Automations for one process: validation, a flow and an approval.

People judge an app by its screens. You build apps, pages and actions in Lightning App Builder, tailor layouts per role, add components, and think about mobile from the beginning.

• Lightning apps and navigation
• Record pages and dynamic forms
• Actions, buttons and links
• Page layouts and compact layouts
• Adding Lightning components to pages
• Designing for mobile

You build A role-specific app with record pages, actions and mobile layouts.

Some logic needs code. You write Apex classes and triggers that respect governor limits, handle bulk operations and errors, and sit beside existing automation instead of fighting it.

• Classes, triggers and bulkification
• SOQL and DML within limits
• Exceptions and error handling
• Order of execution with flows and validation
• Asynchronous Apex for long-running work
• Writing unit tests

You build A bulk-safe trigger that complements a flow without conflict.

Custom screens are a second place where code enters an application. You build Lightning Web Components, secure them, and use Salesforce DX and the CLI to develop and deploy changes repeatably.

• Lightning Web Components and Apex together
• Wire service and data access
• Security in components
• Visualforce and Aura in existing apps
• Salesforce DX and the CLI
• Deploying and testing from the command line

You build A Lightning Web Component with tests, deployed from the command line.

An app that works with a few records can fail with millions. You find the model choices that hurt at scale, design queries that stay selective, and plan archiving before storage and speed force it.

• How data volume changes design
• Indexes and selective queries
• Data skew and how to avoid it
• Big objects and archiving
• Reports and list views at scale
• Planning storage and growth

You build A scale review of a data model, with fixes for its weak points.

Data outlives the app that holds it. You plan loads and exports, protect quality with validation and duplicate rules, and set governance for ownership, stewardship and change.

• Planning a data load
• Tools for loading and exporting
• Duplicate and matching rules
• Data ownership and stewardship
• Policies for retention and change
• Monitoring data quality over time

You build A migration and governance plan for the app’s data.

Access starts with what each user may do to objects and fields. You build permission sets and groups, keep profiles lean, and check each person’s effective access before it reaches production.

• Profiles and permission sets
• Permission set groups
• Object permissions: create, read, edit and delete
• Field-level security
• Hiding data in the interface
• Auditing effective permissions

You build A permission structure for four user types built on permission sets.

Record access opens up from a restrictive baseline. You set organization-wide defaults, design role hierarchies, and write sharing rules that grant access narrowly without slowing the org.

• Org-wide defaults and why to start closed
• Role hierarchy design
• Sharing rules by owner and by criteria
• Public groups and queues
• Sharing effects on performance
• Checking who can see a record

You build A sharing model of defaults, roles and rules for a sample org.

Some access cannot be set by rule. You add record teams, manual sharing and Apex managed sharing for exceptions, and decide when each is worth its upkeep.

• Account, opportunity and case teams
• Manual sharing and its limits
• Apex managed sharing and sharing reasons
• Sharing for external users
• Recalculation and its cost
• Testing access across user types

You build A sharing design for exceptions, using teams and one programmatic share.

An app has to travel from idea to production and then keep changing. You choose sandboxes and deployment methods, move changes with change sets or packages, and plan testing and release.

• Sandbox types and their uses
• Change sets and their limits
• Choosing a package type for an application
• Source control for an application
• Testing before release
• Planning a release and rollback

You build A release plan that moves one application from sandbox to production.

Design one application from the data model to access and release. You decide which parts are declarative and which are code, how data scales and who sees what, then explain the whole design.

• Scoping the application and its users
• Choosing declarative or coded parts
• Designing data, scale and migration
• Designing access and sharing
• Planning release and presenting the design

You build A complete application design with data model, build approach, access and release plan.