You Just Inherited a Messy Salesforce Org, Now What?

You just started working at a company as a Salesforce Architect or tech lead and withing few days it occured to you that the Salesforce org is complete mess. The previous vendors and architects admin who managed this instance was a yes-people who did everything that was asked for even if it made no sense or went against best practices. On the top of that there is hardly any documemtation and requirements tracebility framework to understand why this massive customization was developed.

Sounds familiar ?

TYou just interited an entire huge pile of mess. So many running flows, nothing documented, legacy crap with old unused fields, and more. You don't even want to get started on hundreds of permissions sets permissions and profiles.

where do you begin? How do you start organizing and culling the massive amount of tech debt that an org has?

The Broad Plan

It's going to require immense patience, and that's the first thing you need to accept.

1. Be Patient

This is a monumental project of tech debt cleaning and will take some time possibly plenty of time. You're not going to fix years of accumulated tech debt in a sprint or two. Accept that upfront and set your expectations accordingly.

2. Get Business Buy-In

Start with leadership. Help them understand the situation. Outline a broad plan of what you want to do to correct it, the costs of not correcting it, and the benefits of doing the work. Without executive sponsorship, this project will not move forward.

Frame it in business terms: performance, maintainability, risk reduction. Not in Salesforce technical jargon such as 100 triggers and 70 flows optimization.

3. Don't Put Down the Previous Admin/Architect

Even if it's obvious that poor decisions were made, don't drag their name through the mud. You don't know what situation some of those poor souls went through. That muddies the focus and can make you look bad. Try to give them the benefit of the doubt as to why certain choices were made.

The previous admin may have been working under constraints you don't know about possibly tight deadlines, demanding stakeholders, or limited resources. Dragging their name serves nobody.

4. Understand How the Org Runs Today

Since you're new to the company or org, spend time understanding how it runs. Document things as you fix or discover them.

In your documentation of existing processes, add notes as to what you plan to do to correct or adjust a process and if it needs fixing. This becomes a living document that tracks both the current state and your roadmap.

5. Organize Your Plan

Break it down into manageable work streams. Use a project management toollike Jira, Azure ADO, whatever your team uses to manage the project. This also serves as a baseline for documenting the org.

Each work stream should have:

• A clear scope
• Measurable outcomes
• A rollback plan

6. Focus on Primary Objects First

Start with the critical objects such as Account, Contact, Opportunity, and related automation. These are the backbone of the org and where the most damage from poor design accumulates.

Get these right first, then work outward to secondary objects and custom functionality.

7. Consider Bringing in a Consultant

I am a strong believer that asking for help is a sign of strenght. If there are areas outside your expertise, don't try to hero through it. Ask for help. Your are not great with Revenue Cloud, for example, so ask your sponsors to bring in a consultant to help tackle some of the tasks.

There's no shame in knowing when you need specialist help. It's often faster and less risky than learning on the job in production-adjacent environments.

8. Create a User Group

Build a group of technical and functional users you can connect with for quick feedback or business questions. I have at least one user from each department or at aleast a product owner. Use a Slack or MS Team channel so everyone can weigh in.

This group serves multiple purposes:

• Quick validation of assumptions
• Early feedback on changes
• A communication channel for updates

9. Develop Power Users Per Business Group/Department

Have at least one power user per group, someone who can directly assist their team with more basic Salesforce needs, like report assistance. They communicate system updates that you pass along to them.

They also act as a coordinator for collecting and vetting department requests and system feedback. This eliminates duplicate and conflicting requests before they reach you.

The Bottom Line

Inheriting a messy org is not fun, but it's also an opportunity. You get to shape it into something well-architected and efficient. The key is patience, documentation, and stakeholder management.

Don't try to fix everything at once. Pick your battles, get quick wins where you can, and build trust with the business as you go.