Orgs Gone Wild: An Admin’s Guide To Salesforce Org Cleanliness
Originally Presented at 2019 Southeast Dreamin’
As the VP of Business Analysis & Architecture at 7Summits, I had the privilege of standing on stage with Mike Martin (Salesforce MVP and Chief Customer Officer at 10K Advisors) at Southeast Dreamin’ to discuss one of our favorite topics: Salesforce Org Cleanliness. More specifically, we took the anti-cleanliness approach and focused on our experiences working in orgs that were less than clean — or flat out wild!
For seasoned administrators and developers, there are few topics that generate as much interest as the best practices for creating and maintaining a well organized Salesforce org. This was evident by the standing-room-only crowd and the robust discussions that we had. Before we dive into the best practices for keeping your org clean, let’s take a step back and highlight some of the most common problems that we see in orgs.
Real World Pain Points
It’s worth noting that orgs do not become wild overnight. Instead, it is generally a function of scaling too fast, having a rapidly evolving team, and the simple accumulation of changes over time. And, let’s be honest, we’ve all created solutions in Salesforce that we’ve come to regret. Here are a few that I’ve experienced personally.
Duplicate Objects and Fields
I’ve seen this more times than I’d care to admit. Salesforce has a significant number of standard objects and fields available to admins directly out of the box. However, some admins intentionally or inadvertently create functionality that replicates out-of-the-box functionality. Not only is this confusing, but it also limits your ability to use the new features that Salesforce releases three times per year. As a best practice, I recommend reviewing the standard out-of-the-box functionality before creating new objects and fields. More often than not, you’ll be able to leverage what’s already there.
Everyone Is A System Admin
When your org is really small it is not uncommon to provide most users with administrative access. This allows the team to quickly enhance the org without the burden of traditional IT system governance. As the org scales, this approach can quickly lead to problems such as duplicate efforts, siloed development, and conflicting solutions. The best practice is to establish a governance model as soon as you can and limit the number of users that are authorized to make changes to the system.
No User Management Process
This pain point has the potential to cost your company from both a financial and a security perspective. What I’ve seen is that some organizations do not have a process in place for deactivating users when they leave the company. The end result is that users can still access the system even though they are no longer employed, which is a significant security risk. Additionally, that user is taking up a license that could be provisioned to another user, which could have financial implications. The best practice is to immediately terminate a user’s access to the system once they no longer need it.
Sandboxes are a great way for administrators and developers to build and test new functionality without impacting the production environment. However, oftentimes sandboxes can be forgotten about if a formal maintenance program has not been established. This can quickly result in problems ranging from failed deployments and overwritten code and configuration. The best practice is to establish a limited number of sandboxes, update them routinely, and deprecate the ones that are no longer needed. Or better yet, established a Dev Ops team to create efficiency in the entire development and deployment process.
Not Using Descriptions
Every object, field, workflow rule, and report that is created in Salesforce can have a detailed description to indicate what the item is, what it was designed to do, when it was created, and any other relevant information you decide to include. Not having descriptions forces administrators and developers to spend hours reviewing related configuration and code. The best practice is to always include a detailed description when creating anything in Salesforce.
Top Three Ways To Prevent A Wild Org
Now that we’ve discussed the common pain points that are seen in orgs, let’s highlight the top 3 things you can do today to prevent your org from going wild.
1. Run the Salesforce Optimizer – The Optimizer is a tool that analyzes your org and provides a detailed assessment that is focused on ensuring you and your users get the most out of Salesforce. More specifically, the analysis includes information about storage limits, object limits, field usage, unused reports, unassigned page layouts, unassigned profiles, code using old API versions, and new features that have not been activated. Overall, it’s a great way to benchmark how wild your org is!
2. Use the Where Is It Used Feature – This is a beta feature that is available in sandboxes and has quickly become my favorite new tool. When viewing validation rules, layouts, custom fields, Visualforce pages, apex classes, triggers, email templates and dozens of other metadata types you can quickly see where something is being used. This in turn can help you identify unused metadata items and prioritize the items that you use most as you begin to clean up your org.
3. Think like Marie Kondo – At the end of the day, it is critical that you do not get attached to specific solutions within your org, especially if they are no longer being used. Administrators and developers will routinely keep legacy solutions around as a reference. But in all honesty, all this does is clutter up the org. When it comes time to evaluate a specific feature or solution, take Marie Kondo’s advice and ask yourself this. Does it bring you joy? If it does, keep it. If not, throw it away!
Joe Fiega is the Vice President of Business Analysis and Architecture at 7Summits. He brings more than 15 years of experience delivering technology-based solutions for startups, small businesses and global companies.