10+ Years in the Trenches

Salesforce Developer Guide

Best practices, tips, and hard-won lessons from over a decade of Salesforce development, 85+ production releases, and every mistake you can imagine.

About the Author

I am Glen Bradford, founder of Cloud Nimbus LLC. I have been building on the Salesforce platform since 2014. Apex, LWC, Flows, integrations, large data migrations — I have done it all. I have also built Delivery Hub, a free project management tool built specifically for Salesforce development teams.

I documented 50+ real mistakes I have made in production, compiled my best tips, and curated the tools I actually use. This guide is the distillation of everything I know.

Apex

Bulkify Everything

Never write Apex that processes one record at a time. Every trigger, every method should handle 200+ records. If you have a SOQL query or DML statement inside a for loop, refactor it immediately. This is the number one cause of governor limit errors in production.

One Trigger Per Object

Use a single trigger per sObject that delegates to a handler class. This prevents execution order conflicts, makes testing predictable, and keeps logic out of the trigger body. The trigger should contain nothing but a method call to the handler.

Use Custom Metadata Types for Configuration

Hardcoded values in Apex are a maintenance nightmare. Use Custom Metadata Types for thresholds, mappings, and feature flags. They deploy cleanly, can be updated without a release, and are queryable in Apex without counting against governor limits.

Write Tests That Actually Test Something

75% code coverage is the minimum, not the goal. Write tests that verify business logic with System.assertEquals(), not tests that just execute code paths. Test bulk operations (insert 200 records), test negative cases, and test edge cases. Your tests are documentation.

SOQL & Data

Selective Queries Save Your Life

In orgs with millions of records, non-selective queries cause full table scans and timeout errors. Index your WHERE clause fields, avoid leading wildcards in LIKE queries, and use the Query Plan tool in Developer Console to verify selectivity.

Avoid SELECT *

Never query all fields when you only need three. Each field adds to heap size. In LWC with wire adapters, this matters even more — you are sending data over the wire. Be surgical with your field lists.

Master Platform Events for Integration

When integrating with external systems, platform events decouple your architecture. They retry automatically, handle failures gracefully, and do not block the user transaction. Use them instead of future methods or queueable chains for integration work.

LWC (Lightning Web Components)

Wire Services Over Imperative Calls

Use @wire for read operations whenever possible. Wire services cache data, reduce server round-trips, and integrate with Lightning Data Service. Save imperative Apex calls for write operations and complex queries that require server-side processing.

Component Composition Over Monolith

Build small, focused components and compose them. A massive single component is hard to test, hard to reuse, and hard to debug. Parent components manage state and pass data down via public properties. Child components emit events up.

Handle Loading and Error States

Every LWC that fetches data should show a loading spinner while waiting and a clear error message if something fails. Users should never see a blank screen or wonder why nothing is happening. Use lightning-spinner and error handling templates.

Deployment & DevOps

Use Scratch Orgs and Source-Driven Development

Stop developing in sandboxes and deploying change sets. Scratch orgs are disposable, version-controlled environments. Use Salesforce CLI (sf), track your source in Git, and deploy via CI/CD pipelines. This is how professional Salesforce teams work.

Deploy Incrementally, Not All at Once

Break large projects into small, deployable increments. Each increment should be testable and reversible. A deploy that touches 50 classes and 30 components is a recipe for weekend debugging. Deploy early, deploy often.

Automate Testing in CI

Run your Apex tests automatically on every pull request. Use GitHub Actions or a CI platform to deploy to a scratch org and run tests before merging. Catch regressions before they hit production, not after.

Flows & Automation

Flows Are Not a Replacement for Apex — But They Are Close

Use flows for declarative automation when the logic is straightforward. But when a flow has 50+ elements or complex branching, it is harder to maintain than Apex. Know when to switch. Admin-maintained flows should be simple. Complex logic belongs in code.

Subflows for Reusability

Just like methods in Apex, use subflows to encapsulate reusable logic. A 'Send Email' subflow can be called from any flow. A 'Create Task' subflow standardizes task creation. Subflows are the equivalent of utility classes in declarative development.

Salesforce Developer Career Path

Every Salesforce developer I have mentored asks the same question: “What should I focus on next?” Here is the honest roadmap — what matters at each level, what to study, and what the market pays.

Junior Developer

0–2 years$70K–$95K

•Apex fundamentals — triggers, classes, SOQL
•Trailhead badges and Platform Developer I certification
•Understanding governor limits and bulkification
•Basic LWC components and Aura wrappers
•Version control basics — Git, branching, pull requests

Build as much as you can. Take on small bugs and enhancement tickets. Ask senior devs for code reviews and actually read their feedback. Every line of feedback is a free lesson.

Mid-Level Developer

2–5 years$95K–$130K

•Complex Apex — batch jobs, queueables, schedulables
•Advanced LWC — wire services, custom events, composition
•Integration patterns — REST/SOAP callouts, platform events
•Flow Builder automation for admin-friendly solutions
•CI/CD pipelines and scratch org development

Start owning features end-to-end. Design the solution, build it, test it, deploy it. Push for Platform Developer II certification. Learn to estimate work accurately — this is what separates mid-level from senior.

Senior Developer

5–8 years$130K–$170K

•System design — data modeling, org strategy, tech debt management
•Mentoring junior and mid-level developers
•Cross-functional leadership — working with BAs, PMs, admins
•Performance optimization — query tuning, async processing
•Security review and managed package development

Your code quality should be a given by now. What matters is your judgment — knowing what to build, what not to build, and when to push back. Start writing documentation. Share knowledge. The best senior devs make everyone around them better.

Architect

8–12 years$160K–$220K

•Enterprise architecture — multi-org strategy, data architecture
•Application Architect or System Architect certifications
•Governance frameworks and design authority
•Integration architecture — middleware, event-driven patterns
•Technical decision-making at the program level

You are responsible for decisions that affect the platform for years. Think in systems, not features. Understand the business deeply — the best architects are the ones who can translate business problems into technical solutions without over-engineering.

Technical Lead

8+ years$150K–$210K

•Team leadership — sprint planning, capacity management, hiring
•Code review culture and engineering standards
•DevOps maturity — CI/CD, release management, environments
•Stakeholder communication and technical roadmapping
•Building and retaining high-performing dev teams

Your output is measured by your team's output now, not your own code. Protect your team's focus. Remove blockers ruthlessly. Build a culture where developers are proud of their work. Ship consistently and the business will trust you with bigger problems.

Case Studies — Real Project Patterns

These are based on real projects I have delivered. Names and client details are omitted, but the patterns, challenges, and lessons are exactly what you will encounter in production Salesforce work.

Building a Loan Management System in Salesforce

Apex TriggersCustom ObjectsAutomation

A financial services client needed to manage thousands of loan applications with complex approval workflows, document generation, and regulatory compliance tracking — all inside Salesforce.

Key Lessons

•Designed a custom object model with Loan__c, Payment__c, and Compliance_Check__c — keeping related data in child relationships for efficient SOQL
•Built bulkified triggers to auto-calculate payment schedules on loan creation and handle cascading status updates across objects
•Used Record-Triggered Flows for admin-manageable notifications and Custom Metadata Types for configurable interest rate tiers
•Implemented a Queueable chain for nightly batch recalculations — processing 50K+ records without hitting governor limits

Complex financial logic belongs in Apex, not Flows. But let admins own notifications and simple field updates declaratively. The key is knowing where to draw the line.

LWC Drag-and-Drop Kanban Board

LWCComponent ArchitectureState Management

The team needed a visual kanban board for managing Salesforce user stories — drag cards between columns, update statuses in real-time, and sync changes back to the server without page refreshes.

Key Lessons

•Built a parent KanbanBoard component that owns all state and three child components: KanbanColumn, KanbanCard, and KanbanDetailPanel
•Used the HTML Drag and Drop API with custom events — child cards dispatch ondragstart/ondrop, parent handles reordering and DML
•Implemented optimistic UI updates — move the card instantly, then call Apex imperatively. If the save fails, roll the card back and show a toast
•Leveraged Lightning Message Service (LMS) to sync the board state with other components on the same Lightning page

LWC state management gets complex fast. Keep state ownership in one place (the parent). Children should be dumb renderers that emit events. This pattern scales to any complex UI.

Multi-Org Deployment Pipeline

CI/CDScratch OrgsVersion Control

A large enterprise had four Salesforce orgs — Sales, Service, Marketing, and a shared integration org. Deployments were manual, error-prone, and took entire weekends. They needed a proper pipeline.

Key Lessons

•Set up a monorepo with separate SFDX projects per org and a shared-libs directory for cross-org Apex utilities
•GitHub Actions pipeline: on PR, spin up a scratch org, deploy, run tests, post results as a PR comment. On merge to main, auto-deploy to the target sandbox
•Built a custom CLI script to diff metadata changes between branches and deploy only what changed — reducing deploy time from 45 minutes to 8 minutes
•Used environment-specific Custom Metadata Types to handle org-specific configuration without branching the codebase

The investment in CI/CD pays for itself within weeks. Once developers trust the pipeline, they deploy smaller changes more frequently, and production incidents drop dramatically.

Common Mistakes Deep-Dive

These are the top 5 mistakes I see over and over — from junior developers and experienced ones alike. I am not just listing them. I am explaining why they happen so you can recognize the pattern before it bites you. For the full list of 50+, see Salesforce Mistakes.

SOQL/DML Inside Loops

Critical

Why It Happens

It feels natural to query or save inside a loop when you are working with one record. But Salesforce triggers fire on batches of up to 200 records, and data loads can push thousands. Your 'one record' code becomes 200 queries in a single transaction.

How to Avoid It

Collect IDs in a Set, query once before the loop, build a Map for lookups, collect records to update in a List, and execute a single DML statement after the loop. This pattern — collect, query, map, process, save — is the foundation of bulkified Apex.

Hardcoding IDs

High

Why It Happens

You grab a Record Type ID from your sandbox and paste it into Apex. It works perfectly — until you deploy to production where every ID is different. This also breaks in scratch orgs and makes your code impossible to test portably.

How to Avoid It

Use Schema.SObjectType.Account.getRecordTypeInfosByDeveloperName() for Record Types. Use Custom Metadata Types or Custom Labels for other IDs. Never assume an ID is the same across environments.

No Error Handling in Integrations

High

Why It Happens

External APIs go down. They return unexpected formats. They time out. If your callout code has no try-catch, no retry logic, and no logging, you will not know why records stopped syncing until a user reports it days later.

How to Avoid It

Wrap every callout in try-catch. Log failures to a custom object (Integration_Log__c) with the request body, response body, status code, and timestamp. Use platform events for async retries. Set up monitoring alerts.

Testing Only the Happy Path

High

Why It Happens

Developers write tests that insert one record and verify it works. But production has duplicate records, null fields, users without permission sets, and validation rules that fire unexpectedly. Your 'passing' tests give you false confidence.

How to Avoid It

Test with 200 records (bulk). Test with null values. Test with users who lack permissions (System.runAs). Test that your validation rules actually block bad data. Test that your error messages are helpful. Aim for 90%+ coverage with meaningful assertions.

Over-Engineering with Apex When a Flow Would Do

Medium

Why It Happens

Developers default to code because it is what they know. But a simple field update, email alert, or record creation is faster to build, easier to maintain, and can be modified by admins without a deployment. Writing Apex for everything creates unnecessary tech debt.

How to Avoid It

Ask yourself: can an admin maintain this? If yes, use a Flow. If the logic has complex branching, needs to process thousands of records, or requires tight error handling, use Apex. The best Salesforce teams use both — declarative for simple, code for complex.

Tools Every Salesforce Developer Needs

These are the tools I use every single day. Not aspirational picks — battle-tested tools that have saved me hundreds of hours. For the full curated list with setup guides, see Salesforce Tools.

IDE & Extensions

VS Code + Salesforce Extension Pack

The official IDE experience. Apex language server, SOQL builder, metadata deployment, test runner — all in one. No serious Salesforce developer should be using anything else.

Apex PMD (VS Code Extension)

Static code analysis that catches bad patterns before code review. Flags SOQL in loops, unused variables, overly complex methods, and more. Configure it to run on save.

Salesforce CLI (sf)

The command-line backbone of modern Salesforce development. Create scratch orgs, deploy metadata, run tests, and manage packages. Learn it well — it is faster than clicking through Setup.

Prettier + Apex Plugin

Auto-format your Apex code on save. Eliminates style debates in code reviews and keeps the codebase consistent. Configure it in your project's .prettierrc and never argue about indentation again.

Browser & Debugging

Salesforce Inspector Reloaded

A Chrome extension that adds a toolbar to every Salesforce page. Quick-export data, run SOQL, view field API names, inspect page metadata. Saves hours every week.

Debug Log Analyzer

Parse and visualize Salesforce debug logs to find performance bottlenecks. See exactly how much time each SOQL query, DML statement, and method call takes. Built into Salesforce CLI with sf apex log tail.

Chrome DevTools (for LWC)

Use the Network tab to inspect wire service calls, the Elements tab to debug shadow DOM, and the Console for JavaScript errors. LWC debugging requires strong browser DevTools skills.

Testing & Quality

ApexMocks / FFLib

An enterprise-grade mocking framework for Apex tests. Isolate your unit tests from DML and SOQL by mocking selectors and domain classes. Essential for large codebases where test execution time matters.

Jest (for LWC)

Test your LWC components locally without deploying to an org. Mock wire adapters, simulate user events, and verify DOM output. Fast feedback loops for front-end development.

Data & Deployment

Salesforce Data Loader

The official bulk data tool. Insert, update, upsert, delete, and export records in bulk. Use the CLI version (dataloader.bat) for automated data loads in scripts.

SFDMU (Data Move Utility)

Migrate data between orgs while preserving relationships. Handles parent-child dependencies automatically. Far more powerful than Data Loader for complex migrations with lookup fields.

GitHub Actions (CI/CD)

Automate your deployment pipeline. On pull request, deploy to a scratch org and run tests. On merge, deploy to a sandbox. Free for public repos, affordable for private teams.

Delivery Hub

Project management built specifically for Salesforce teams. Track user stories, manage sprints, monitor velocity, and coordinate deployments. Built by Cloud Nimbus LLC — by Salesforce devs, for Salesforce devs.

Delivery Hub by Cloud Nimbus LLC

Project management built for Salesforce teams. Track user stories, manage sprints, and deploy with confidence. Built by a Salesforce developer, for Salesforce developers.

Learn more

Frequently Asked Questions

What is the most common Salesforce development mistake?

SOQL or DML inside a for loop. This violates bulkification principles and causes governor limit errors as soon as a data load or batch process runs. Every Salesforce developer makes this mistake early in their career. The fix is simple: collect records in a list, then execute a single DML statement outside the loop.

Should I learn Apex or Flows first?

Learn Flows first. Salesforce is moving toward declarative-first development, and many business requirements can be met with Flows alone. But learn Apex as soon as possible — you will hit the limits of Flows quickly in complex orgs, and Apex gives you full control over the platform.

What Salesforce certifications should I get?

Start with Platform Developer I (PD1). It covers Apex, SOQL, triggers, and basic LWC. Then get Platform Developer II (PD2) if you want to demonstrate advanced skills. Beyond that, focus on certifications relevant to your domain: JavaScript Developer I for LWC, Admin for a broader foundation, or Application Architect for solution design.

How do I become a better Salesforce developer?

Build things. Read the documentation (developer.salesforce.com). Review other developers' code on GitHub. Study the Apex Design Patterns. And most importantly, learn from your mistakes — every production incident teaches you more than any Trailhead module. Glen Bradford has documented 50+ real mistakes at glenbradford.com/salesforce/mistakes.

What tools do Salesforce developers actually use?

VS Code with the Salesforce Extension Pack, Salesforce CLI (sf), Git for version control, a CI/CD platform (GitHub Actions, GitLab CI, or Gearset), and Developer Console for quick debugging. For project management, Delivery Hub by Cloud Nimbus LLC is built specifically for Salesforce development teams.

How long does it take to become a Salesforce developer?

If you already know how to code, you can be productive on the Salesforce platform in 3–6 months. If you are starting from zero, expect 6–12 months of focused learning before you are job-ready. Trailhead is free and covers everything, but real skill comes from building real projects — not just earning badges.

Is Salesforce development still a good career in 2026?

Yes. The Salesforce ecosystem continues to grow, and the demand for skilled developers far exceeds supply. Junior devs start at $70K–$95K, senior devs earn $130K–$170K, and architects can command $200K+. The key is to go deep — learn Apex, LWC, integrations, and CI/CD. Generalists are replaceable; specialists are not.

Should I use change sets or Salesforce CLI for deployments?

Salesforce CLI, always. Change sets are fine for a single admin making a quick config change, but for development teams they are a disaster — no version control, no rollback, no automation, no code review. Use SFDX projects, track everything in Git, and deploy via CI/CD pipelines. This is the industry standard.

What is the difference between a Salesforce developer and a Salesforce architect?

Developers build features. Architects design systems. An architect decides the data model, integration strategy, org structure, and technical standards before a single line of code is written. Most architects were senior developers first — they earned their perspective by building enough systems to know what works and what does not at scale.

How do I handle governor limits in Apex?

Governor limits exist to protect the multi-tenant platform. The key strategies are: bulkify all code (no SOQL/DML in loops), use collections and maps instead of repeated queries, leverage async processing (Batch Apex, Queueable, Platform Events) for large operations, and use the Limits class to monitor consumption at runtime. If you are fighting limits constantly, your design pattern is wrong.

What is the best way to learn LWC?

Start with the official LWC documentation on developer.salesforce.com and the LWC Recipes sample app on GitHub. Build small components first — a data table, a search bar, a form. Then combine them. Understanding JavaScript fundamentals (especially ES6+ classes, Promises, and DOM events) is essential. If you know React or Vue, LWC will feel familiar.

Can I use Salesforce and still write modern JavaScript?

Absolutely. Lightning Web Components are built on web standards — ES6+ classes, shadow DOM, custom elements, and standard event handling. You can use modern JavaScript patterns like async/await, destructuring, template literals, and modules. LWC is the closest Salesforce has ever been to mainstream front-end development.

How do I transition from Salesforce Admin to Developer?

Start with Apex basics — variables, loops, collections, SOQL queries. Build a simple trigger that fires on record creation. Then learn LWC by rebuilding a Flow screen as a custom component. The conceptual gap is smaller than you think — you already understand the platform, data model, and business logic. You just need to express it in code instead of clicks.

Get Glen's Musings

Occasional thoughts on AI, Claude, investing, and building things. Free. No spam.

Unsubscribe anytime. I respect your inbox more than Congress respects property rights.

Join the Community

Weekly deep-dive analysis, real-time position updates, and direct access to Glen Bradford. $20/month.

Learn more

Keep Exploring

Start Here

Debug Before You Deploy

Apex code scrolls down the screen with bugs hidden inside. Spot the SOQL-in-loop, missing null checks, and DML violations before they hit production. Can you ship clean code?

SALESFORCE DEV CHALLENGE

Apex Debugger

Identify bugs in Apex code before deployment!

Read each code snippet and select the bug type. Press 1/2/3 or tap.

"Apex has governor limits for a reason."

+100 Correct answer (× streak)

-50 Wrong / timeout

Power-ups every 10 correct

5x max streak multiplier

BOSS BUG at rounds 10 & 20

Coffee slows time 50%

20 rounds • Boss bugs • Slack distractions • Meeting pressure