No, It's Not Just About Clean Code—It’s About Clean Thinking
Let’s Start with a Real Story
Two years ago, I walked into a project where every change felt like walking on Lego bricks barefoot. Add one new field → five flows broke. Update a validation rule → Apex tests cried.
We called it: “The Org of Doom.” 😅
It had 20+ active record-triggered flows, hundreds of fields on Account, and code written by 8 developers over 6 years — with no documentation.
That’s not a system — that’s technical debt in its most terrifying form.
What Is Technical Debt in Salesforce?
Think of it like this:
Every time you take a shortcut today for faster delivery, you’re borrowing against your org’s future scalability.
Just like financial debt, technical debt builds interest. The more you delay paying it off, the more painful it becomes to make changes.
Common Causes of Technical Debt in Salesforce
Let’s break it down with everyday examples you might recognize:
Cause | Real-World Example |
---|---|
🪓 Quick Fixes | A validation rule added in a rush during UAT, never optimized |
🔁 Duplicate Logic | Same logic in Process Builder, Flow, and Apex Trigger |
😵💫 Over-Customization | 20+ custom fields that nobody uses |
🧪 Poor Test Coverage | Test classes that just cover for coverage’s sake |
🙈 No Documentation | You found a flow named Flow_123_Test_v2_FINAL (1) and cried inside |
🏷️ Bad Naming Conventions | New_Trigger_UpdatedBySomeone — no idea what it does |
🔄 Mixing Declarative + Code | A validation rule added in a rush during UAT, never optimised |
How to Prevent Technical Debt Like an Architect
1. 🔍 Think in Systems, Not Features
Don’t build for a requirement. Build for a future-proof system.
Bad:
“Client wants a checkbox → I’ll add it and update flow.”
Architect Approach:
“Why is this checkbox needed? Can we solve it via a formula or report instead?”
Architects ask why before building the what.
2. 📐 Establish a Guardrail Architecture
Have rules for:
- When to use Flow vs Apex
- Naming conventions
- Folder structure for Flows and Reports
- When to use custom metadata/settings
Example:
For one client, we implemented a rule:
“No record-triggered flows allowed on Opportunity. All logic handled via Apex + platform events.”
It saved us countless hours of debugging in the long run.
3. 🧹 Do a Monthly Org Cleanup Sprint
Every month, allocate 1–2 hours to:
- Delete inactive flows and old reports
- Merge duplicate fields
- Archive old dashboards
- Review test methods with poor coverage
Call it “Tech Debt Friday” — serve chai and clean your mess together 😄
4. 📚 Document as You Go
Documentation doesn’t have to be fancy. Even a shared Google Sheet that says:
Flow Name | Purpose | Owner | Last Modified |
---|
…can save a new developer hours of confusion.
5. 🧪 Write Tests That Teach, Not Just Cover
Bad:
System.assert(true); // just to get 75% 😐
Good:
@isTest
static void test_WhenOpportunityClosed_CreateTask() {
// Arrange
// Act
// Assert meaningful logic
}
Your future self (or next developer) will thank you.
6. 🧠 Create a Design Review Ritual
Before any major logic goes live, review it with your team:
- Is this scalable?
- Can this be done declaratively?
- Does it conflict with existing flows?
Even a 20-minute sync avoids months of debugging.
Architect Mindset Summary
Habit | Architect Thinking |
---|---|
🧠 Thinking beyond ticket | What impact does this have on data model & future logic? |
📂 Organizing everything | Future devs can easily navigate |
💬 Communicating clearly | Stakeholders understand tradeoffs |
🔄 Reusability > Redundancy | Use invocable Apex, subflows, and custom labels |
✂️ Less is more | Sometimes removing a feature is the best fix |
The best systems are not the ones with the most features. They’re the ones with the least surprises.
– Arpit vijayvergiya
Technical Debt in Salesforce
Salesforce Architect best practices
Salesforce cleanup checklist
Prevent technical debt Salesforce