The Salesforce Graveyard
50 Real Salesforce Mistakes I Made So You Don't Have To
10+ years. 85 production releases. Every mistake documented with the war story, the wrong code, the right code, and the lesson learned. These are battle scars turned into wisdom ā so you can skip the pain and go straight to the fix.
By Glen Bradford, Salesforce developer & founder of Cloud Nimbus LLC
Mistakes by Category
š
Flows
5 mistakes
ā”
Apex
5 mistakes
šļø
Data
5 mistakes
šļø
Architecture
5 mistakes
š
Security
5 mistakes
š
Integration
5 mistakes
š
Deployment
5 mistakes
āļø
LWC
5 mistakes
āļø
Admin
5 mistakes
š¤
AI & Agents
5 mistakes
50 total mistakes ā¢ Searchable ā¢ Filterable ā¢ Each with code examples
Why I Published My Mistakes
Every Salesforce developer makes mistakes. The difference between a junior and a senior is not that seniors don't make mistakes ā it's that seniors have already made them, documented them, and built guardrails so they never happen again.
I've been building on Salesforce for over a decade. I've shipped 85+ production releases across orgs ranging from 10-user startups to enterprises with thousands of licenses. Along the way, I crashed production environments, burned through governor limits, deployed broken change sets on Fridays, and once accidentally deleted a custom object in production that had 50,000 records.
Every single one of those mistakes taught me something. This graveyard is my way of passing those lessons forward. Each entry includes the real war story (names changed where appropriate), the wrong code I wrote, the right code I should have written, and the lesson I carry with me to this day.
Whether you're studying for your Salesforce certification, debugging a production issue at 2 AM, or trying to convince your team to adopt better practices ā bookmark this page. Share it with your team. These 50 mistakes represent thousands of hours of painful learning compressed into something you can absorb in an afternoon.
50 mistakes found
The Fix Framework
How to Fix Any Salesforce Mistake
After fixing hundreds of production issues, I've distilled the process into five steps. This framework works whether you're dealing with a governor limit exception, a misconfigured flow, a broken integration, or a deployment gone wrong.
Identify
Pinpoint the exact mistake. Read the error message carefully — Salesforce error messages are surprisingly descriptive once you know how to decode them. Check debug logs, flow fault messages, and governor limit usage. The worst thing you can do is start fixing something before you understand what's actually broken. Write down the exact error, the exact steps to reproduce, and which users are affected.
Reproduce
Recreate the issue in a sandbox. If you can't reproduce it, you can't fix it — and you definitely can't verify the fix. Clone the production data if needed. Use debug logs with FINEST level on the relevant categories. For intermittent issues, check if it's related to bulk operations, specific user profiles, or timing. Document your reproduction steps because you'll need them for testing.
Fix
Apply the smallest possible change that resolves the issue. Resist the urge to refactor everything while you're in there. A surgical fix is easier to test, easier to deploy, and easier to roll back. If the fix requires a larger refactor, do the quick fix first to stop the bleeding, then plan the refactor as a separate deployment. Always fix the root cause, not just the symptom.
Test
Test the fix with realistic data volumes. If the bug happened with 200 records, test with 200 records. Run all existing unit tests to make sure you didn't break anything else. Test with the same user profile that hit the error. For flow fixes, test every path — including fault paths. For Apex, add a new test method specifically for the scenario that caused the bug. Your test coverage should increase, not decrease.
Document
Write down what happened, why it happened, and what you changed. Future you — or the developer who replaces you — will thank you. Add a comment in the code explaining the fix and referencing the ticket number. Update your team's knowledge base. If the mistake was systemic (like a pattern you use everywhere), audit other code for the same issue. One bug found is ten bugs prevented.
Pro tip: Keep a running document of every production issue you fix. Include the date, the symptoms, the root cause, and the resolution. After a year, you'll have an invaluable reference that makes you faster at diagnosis and earns you a reputation as the person who always knows what went wrong. That document is how this graveyard was born.
10 Rules I Follow After Making All 50 Mistakes
Never put SOQL or DML inside a loop
In Apex triggers, in Flow loops, in batch execute methods. Anywhere. Collect, query once, map, then loop.
Every Flow element that does DML gets a fault path
If it can fail, handle it gracefully. Your users should never see an unhandled fault message.
Never hardcode Salesforce IDs
Record Type IDs, Queue IDs, Profile IDs — all different between environments. Query by DeveloperName or use Custom Metadata.
Test with 200 records, not 1
Salesforce processes records in batches of 200. If your code works with 1 record and fails with 200, you have a bulkification problem.
Before-save flows for same-record updates
Before-save flows cost zero DML. After-save flows cost one DML per record. For updating the triggering record, always use before-save.
Never deploy directly to production
Full sandbox first. Run all tests. Verify dependencies. Have a rollback plan. Deploy during off-peak hours. Never on a Friday.
Null-check everything
In Apex: check for null before accessing properties. In Flows: use Decision elements before accessing variables that might be empty.
Log integration errors to a custom object
Platform events, custom objects, or Big Objects. If an integration fails silently, you will not know until a user reports missing data days later.
Use one trigger per object with a handler class
Multiple triggers on the same object create unpredictable execution order. One trigger delegates to one handler class. Always.
Document every automation
Flows, triggers, process builders, validation rules, workflow rules. If you cannot explain what fires when a record is saved, your org is a ticking time bomb.
Frequently Asked Questions
What is the most common Salesforce development mistake?
The single most common Salesforce mistake is putting SOQL queries or DML operations inside for loops. This violates the governor limit of 100 SOQL queries and 150 DML statements per transaction. It works fine with small data sets in sandboxes, then fails catastrophically in production when bulk operations trigger the code. The fix is always the same: collect IDs first, query once outside the loop, build a map, then reference the map inside the loop. This pattern applies to both Apex triggers and Flow Get Records elements.
How do I avoid Salesforce governor limit errors?
Governor limits exist to protect the shared multi-tenant infrastructure. To avoid hitting them: bulkify all Apex code (no SOQL/DML in loops), use collections and maps instead of individual queries, leverage before-save flows instead of after-save when updating the triggering record, use platform cache for frequently-accessed data, batch large operations into chunks of 200, and always test with realistic data volumes. Monitor your limits with Limits.getQueries() and Limits.getDMLStatements() in Apex, and use the Developer Console to profile your transactions.
What are the biggest Salesforce Flow mistakes to avoid?
The top Flow mistakes are: putting Get Records inside loops (hits SOQL limits), not adding fault paths to DML and callout elements (users see cryptic errors), creating recursive flows that trigger themselves infinitely, hardcoding Record Type IDs (different between environments), using after-save flows when before-save would work (wastes DML), and not setting entry criteria tight enough (flows fire on every edit). Each of these is documented in detail in this graveyard with real-world examples and fixes.
How do I debug a Salesforce production issue?
Start by enabling debug logs for the affected user at the FINEST level for Apex Code and FINE for Workflow and Validation. Reproduce the issue and read the log carefully. For Flow issues, check the flow fault message in the debug log or set up a fault email alert. For Apex, look for the specific exception type and line number. Use the Developer Console or VS Code Replay Debugger to step through the log. Never debug by making changes directly in production — always reproduce in a sandbox first, then deploy the fix through your change management process.
What is the best way to handle errors in Salesforce Apex?
Use a layered approach: try-catch blocks for recoverable errors, custom exception classes for business logic violations, and a centralized error logging framework that writes to a custom object or platform event. Never swallow exceptions silently — at minimum log them. For triggers, let unrecoverable errors bubble up so the transaction rolls back cleanly. For integrations, implement retry logic with exponential backoff and log every failed attempt. Always include the stack trace, the record IDs involved, and the user context in your error logs.
Should I use Flows or Apex for Salesforce automation?
Use Flows for straightforward record-triggered automation, screen-based processes, and anything an admin should be able to maintain. Use Apex when you need complex logic, tight governor limit control, integration callouts with retry logic, advanced error handling, or operations that Flows handle poorly (like complex collection manipulation). The real answer is: use both. Flows for the 80% of automations that are simple, Apex for the 20% that require precision. Never build in Apex what a Flow can handle cleanly, and never force a Flow to do something it was not designed for.
How do I prevent deployment failures in Salesforce?
Follow a strict deployment checklist: always deploy to a full sandbox first, run all tests (not just the ones you wrote), verify metadata dependencies are included, check that profiles and permission sets are part of the package, never deploy on a Friday or during peak hours, have a documented rollback plan, and use a CI/CD tool like Salesforce CLI with source tracking. The most common deployment failures are missing dependencies, insufficient test coverage, and metadata conflicts from parallel development. Version control with Git and a proper branching strategy prevents most of these issues.
What Salesforce architecture mistakes should I avoid?
The biggest architecture mistakes are: over-customizing (building features Salesforce already provides), choosing the wrong object model (custom objects when standard objects would work, or vice versa), not documenting the data model, premature optimization, ignoring technical debt until it compounds into an unmaintainable org, and skipping naming conventions. Start with standard objects, use custom objects only when standard ones genuinely do not fit, and establish naming conventions on day one. Document every automation, every integration, and every custom object. Future developers will inherit your decisions.
Don't Make These Mistakes Yourself
Hire someone who already made all 50 of them. I'll get it right the first time ā because I already got it wrong.
10+ years of Salesforce development. Apex, Flows, LWC, integrations, architecture, and deployment. I've seen it all and fixed it all.
View Consulting ServicesGet 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.
Keep Exploring
Salesforce Hub
Tools, tips, directory, and more from 10+ years of Salesforce development.
Read moreSalesforce Developer Guide
16 battle-tested tips covering Apex, SOQL, LWC, flows, deployment, and career path.
Read moreConsulting
Skip the learning curve. Hire the developer who wrote the graveyard.
Read moreBlog
2,700+ posts on investing, Salesforce, markets, and life.
Read more