Salesforce was founded in 1999 – that was a long time ago. A lot of Salesforce Admins were still children in 1999, myself included. This means there are orgs out there that are 20+ years old – the oldest I’ve worked with was 16.
Legacy Salesforce orgs have been around for over 10 years. Dealing with orgs over a certain age has both pros and cons, but one of the best things about an older org is that (hopefully) all of the growing pains have passed, and all of the processes are already in place.
That’s wishful thinking, right? The truth is, Salesforce has changed so much since its inception – things that were once ‘best practice’ may have become unnecessary routines over the years (code), or perhaps new features are not being used (Lightning) because users are too comfortable with the ‘old ways’. And documentation? You’re lucky if there is any at all, and the older the org is, the less likely there is to be any!
There are many reasons why you might suddenly inherit a legacy org. Maybe you’re a consultant and you have a new client with an old org. Or maybe you’ve been hired as a Salesforce Admin. Perhaps you’re an “accidental admin” and this task has just landed on your desk. Regardless of the reason, today we’ll explore some of the first things you should do when you inherit a legacy org – there will be lots of questions to ask!
1. Company Information
Check out which Edition the org is on, when it was created, and what the current agreement is with Salesforce. This step gets overlooked sometimes because the majority of companies use Enterprise. In fact, in almost ten years, I’ve worked with dozens of companies, and only two were not on Enterprise.
In addition, in many companies, the Salesforce Admin is not actually the person negotiating the renewal with Salesforce. Even if you are not the person who deals with the renewal, it’s important to understand the critical dates for your org. This will put you in a better position for advising the company on any necessary (or unnecessary) paid features, as well as any changes to the number of user licenses your company purchases.
I have been shocked to see that sometimes the company address is wrong or the primary contact is long gone, so check these things out first and take a look at data storage and API calls too!
2. Users
It’s important to check how many user licenses you use, how many are available, and who is using them.
Do you have any users that don’t log in regularly? If so, can they be deactivated?
Ask yourself the following questions:
- Do you need to add any more users for dedicated integrations like Marketo, Hubspot, LeanData, and Outreach.io?
- Does the company have plans to hire in the coming months, and do you have enough licenses to accommodate those new hires?
- Is there a process for deactivating users when they are terminated?
3. User Interface
How much customization has been done to the user interface? Are they using Lightning Experience? In my opinion, this is indicative of a company’s overall attitude towards Salesforce, as well as the amount of support they have received.
Migrating to Lightning Experience is the most obvious user interface change, but there are many other simple interface customizations we can check. For example, have search results been customized? Have tab columns been customized? Are there different apps for different teams? Do these apps have good and useful home pages? These are all important questions to ask.
If none of this is done, especially in a legacy org, my alarm bells begin to ring. Perhaps the company didn’t realize those things could be changed, or perhaps they never dedicated a resource to do so. Either way, we can tell immediately that the users are probably not working as efficiently as they could be.
4. Code
Now, I’m not a developer. If you’ve read any of my blog posts, you know that I’m an admin through and through, and I use declarative programming for everything. That being said, even admins should know where code is, how to look at it, and how to get a sense of what it is meant to do. You can tell if a trigger is from an installed package or not. Older orgs are especially guilty of having a lot of triggers, for the simple reason that declarative programming was either not available at the time, or could not accomplish what it can today.
5. Community (Digital Experience)
Find answers to the following questions:
- If there is a community, how old is it?
- Who is managing it and the users?
- What is it for?
- Are the customers or partners actually using it?
- Is the content included up to date?
6. Objects and Fields
Does this org have a lot of custom objects? How about custom fields? Remember, this is just a preliminary look around – we’re not quite ready to break out Field Trip at this point. We just want to look at the Object Manager and see what kind of custom objects exist. Take a look at the major standard objects: Accounts, Contacts, Opportunities, Leads, and perhaps Campaigns and Cases. Do you see an abundance of custom fields? Are there a lot of validation rules on each object?
7. Records
Now you can run some reports. Let’s ask:
- How big is the Lead and Contact database?
- How many Opportunities exist?
- How many Accounts exist?
- How do these records get created?
- Are records being created in bulk from tools like ZoomInfo or other systems?
8. Data Quality
Once you’ve assessed what records exist, you can start looking at data quality. Check out this post on a basic data quality dashboard you can create in Salesforce. Generally, I look to make sure that Leads and Contacts have an email address and company name. Opportunities should have an Amount, Company, and Close Date.
Start with what you generally know to be good data quality, but also check with the company. If your company never uses Phone Numbers, for example, maybe you can ignore Leads and Contacts where the Phone is blank.
9. Integrations
It never fails – you start working as a Salesforce Admin, then almost immediately learn how to work with everything that connects with Salesforce, even if it’s just for self-preservation! In the case of a legacy org in particular, there’s probably a lot going on. Some good places to look are login history (shows any connected apps), installed packages, and users.
10. Automation and Actions
Take a look at what existing automation exists. Older orgs are more likely to have a lot of Workflow Rules and Process Builders that have never been upgraded. How many exist? Do they still need to be running? Do people even know they still exist?
And for Actions – this is one place where poor data quality can come from. Even when you make an Email address required on the Lead record, for example, if you have a “Create Lead” Quick action, it needs to be set to required there too!
Summary
Finally, and this goes without saying, make sure you talk to the people who work in this org (or the people who hired you) regularly. The moment you get access is the most un-informed you will ever be about this work – you’ll start learning as soon as you begin looking around. The more information you can get, the better you will understand what you’re looking at, why things were built a certain way, or why they were not built a certain way.
This is not an exhaustive list – there are many things that will tell you the story of a specific legacy org. Your next steps might include running a Salesforce Health Check or even the Optimizer.
What is the first thing you review when you get access to a legacy org? Let us know in the comments!
Comments: