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 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.

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.

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.