When a request lands in an existing Salesforce org, the reflex is to open a new browser tab and start building. A field here, a Flow there, maybe a quick validation rule. It feels productive. And sometimes it is.
But in a mature org, the most useful work often happens before you touch a single component. The org you inherited isn’t a blank canvas. It’s a record of decisions other people made for reasons that may not be written down anywhere. That field with the odd name? Someone added it because a team needed it. That Flow nobody documented? It might be the only thing keeping an approval step honest.
So before you build, it pays to slow down and look.
Key takeaways
- Understand the business process before you reach for a technical solution.
- Investigate existing functionality and dependencies before creating anything new.
- Review the automation landscape before adding one more automation to it.
- Treat technical debt as something to understand and manage, not something to delete on reflex.
- Use native and AI-assisted analysis to investigate faster, with business context still in the driver’s seat.
Table of Contents
Understand the Business Process before the Technical Solution
Every technical component in your org exists because of a business reason, even if that reason has drifted over the years. A field captures information some team relies on. A validation rule enforces a rule someone in operations actually cares about. A Flow automates a step that used to be a person clicking buttons.
That’s why jumping straight to the technical fix is risky. You can build something that works perfectly and still break how the business runs.
Before I change anything in an org I don’t know well, I try to answer a few plain questions:
- What problem are we actually solving here?
- How does this process work today, on the ground?
- Why was it built this way in the first place?
- Who depends on it, and would they even notice if it changed?
- Are there exceptions or edge cases hiding in it?
- Is the current behavior a bug, or is it just the process doing its job?
That last one catches me more than I’d like to admit. Plenty of times what looked like a defect turned out to be someone’s carefully placed guardrail. The point of a Salesforce org assessment isn’t to pile on more functionality. It’s to improve the platform without quietly dismantling the logic people already trust.
Investigate Before You Build
Investigation is the least glamorous part of the job and probably the highest-leverage. Before you spin up new fields, Flows, Apex, record types, permission sets, or any of the things we love to create, two questions are worth sitting with:
Does something already exist that solves part of this?
And if I change that thing, what else moves?
The answers rarely live in one place. You’ll find pieces in the configuration, pieces in the metadata, and pieces only in the heads of the people who use the feature every day. A component can look abandoned in isolation and still quietly feed another process. I once wrote off a “dead” field because nothing referenced it in automation, then found out it drove a report the finance team reads every month. The “Where is this used?” button and the dependency view exist for exactly that reason, so use them before you trust your gut.
You don’t need to audit the entire org to make one change. That way lies madness. You need to understand the slice that touches the problem in front of you. Sometimes the best outcome isn’t a new component at all. It’s extending, consolidating, or simplifying something that’s already doing most of the work.
Review Automations Before you Add Another One
Here’s where a “simple” change turns into a support ticket a week later. On any given object, a single record update can set off a chain you didn’t know about:
- Record-triggered Flows
- Apex triggers
- Legacy Process Builder processes
- Legacy Workflow Rules
- Validation rules
- Approval processes
- Integrations reacting to the change from outside
An automation audit is essential for any established organization. Before adding a new trigger point, it is important to understand what is currently being triggered. The ‘Flow Trigger Explorer’ is incredibly useful for visualizing the sequence in which flows execute for a specific object. The question shifts from “Can I build this?” to “What is already happening when this record is saved?”
One note on the legacy tools. As of December 31, 2025, Salesforce ended support and maintenance for Workflow Rules and Process Builder, and you can’t create new ones, though existing ones keep running (Salesforce Help). If your org still leans on them, factor migration to Flow into your planning rather than building around them and hoping.
Look for Technical Debt
Technical debt has a bad name; it doesn’t fully deserve it. Finding it doesn’t mean someone did a bad job. It usually means the org grew, priorities shifted, and a few “temporary” solutions quietly became permanent.
In practice, an org health check tends to surface things like:
- Old automations nobody has looked at in years
- Two or three components doing nearly the same job
- Fields that were retired in spirit but never in the schema
- A quick fix from 2021 that’s now load-bearing
- Logic that’s genuinely hard to follow, let alone maintain
The goal isn’t to rip all of it out on sight. Some debt is fine to leave alone. The real skill is seeing it clearly and understanding what it costs you. Once you have that picture, you can make an honest call: keep it, improve it, consolidate it, or redesign it. Salesforce’s own Well-Architected guidance on maintainability is a solid reference if you want a framework for that judgment.
Use the Org as a Source of Information
I’ve come to treat the org itself as the most reliable documentation I have. It doesn’t sugarcoat, and it doesn’t forget. Native tools like Salesforce Optimizer, the dependency view, and Flow Trigger Explorer help you read that story faster, and AI-assisted analysis can speed up the mapping when you’re staring at a tangle of dependencies.
None of that replaces business knowledge, though. Tooling tells you what is connected to what. It won’t tell you why, or whether the why still holds. Use the tools to investigate quickly, then spend the time you saved on what actually needs a human: deciding whether to build or improve.
Before You Build: A Quick Checklist
Keep this one handy. Run through it before you commit to creating anything new in an existing org.
- Do I understand the business problem, not just the ask?
- Do I know how the current process actually works?
- Did I check whether something already solves part of this?
- Did I review the automations that fire on this object?
- Did I map the dependencies my change would touch?
- Did I account for existing technical debt?
- Did I think through what could break?
- Is building something new genuinely the best option here?
If you can’t tick most of these with a straight face, you’re not ready to build yet.
Mistakes to Avoid
A few traps that catch people, myself included:
- Treating the org like it’s empty. New functionality gets bolted on next to something that already did the job, and now you’re maintaining two.
- Testing on the record but not the process. Your change saves fine in isolation and quietly breaks an approval three steps downstream.
- Assuming “unused” means safe to delete. Reports, integrations, and dashboards reference things automation doesn’t.
- Skipping the people. The users often know about a dependency that no config screen will ever show you.
Final Thoughts
The next time a change request lands in an existing org, resist the urge to open a new Flow straight away. Pick one thing from the checklist above and run it first: map what already fires when that record saves. That single habit will catch more problems than any amount of careful building afterward.
Good work in a mature org isn’t measured only by what you add. It’s measured by what you understood before you touched anything, and by leaving the org a little simpler and safer than you found it.
Salesforce resources
Suelen Yuri Nissato
Suelen is a Salesforce Developer focused on Apex, Lightning Web Components (LWC), SOQL, Flows, OmniStudio, REST APIs, and integrations. She is passionate about building business solutions, automating processes, and solving real-world challenges through technology. She is continuously expanding her Salesforce expertise, with a particular interest in integrations, modern development practices, and Agentforce.