Management asked me to perform a 'system health check' on our Salesforce org, but I do not have a standard process for this. What are the key pillars of a healthy org architecture?
I want to cover security, performance, technical debt, and user adoption. Can someone suggest a framework or a list of questions I should be asking myself to determine if our org is truly 'healthy' or if it is secretly failing?
A comprehensive Salesforce health check entails assessing security configurations, optimizing system performance by deprecating unused automation, reviewing technical debt through code and object usage, and correlating login activity with record creation to measure user adoption.
7 answers
A healthy org architecture requires a baseline audit of these four critical pillars.
- Run the security health check report to identify misconfigured password policies and session settings.
- Review the apex class and flow usage statistics to deprecate code that no longer serves a functional purpose.
- Analyze login history and object record creation rates to pinpoint where user adoption is actually failing.
- Examine the current governor limit consumption during peak hours to ensure system performance remains stable.
Start by running the Salesforce Optimizer report to identify the most glaring technical debt and security gaps immediately. Focus your effort on identifying unused profiles, excessive permission sets, and broken automation before you even look at adoption metrics.
I recall auditing a global enterprise client where they had bypassed standard record sharing for years, leading to a massive sprawl of apex sharing reasons that nearly crippled the database performance. I spent three weeks untangling the mess of custom logic and security settings that had been layered on top of each other like a precarious house of cards.
It taught me that before you touch configuration, you need to map out the current data access model against the actual business requirements, as many administrators simply add complexity instead of addressing the fundamental architectural flaws.
You should prioritize the security health check when you have limited time because it provides a quantitative baseline, whereas performance monitoring is better if you are currently experiencing active system timeouts or slow UI rendering. Security metrics offer a objective pass-fail standard that is easier to report to management, but digging into performance logs is necessary if your users are complaining about the interface. You cannot effectively optimize adoption until the system is stable and secure enough to justify the trust of your internal stakeholders.
Stop looking for a magic framework and start looking at the logs. If you are not measuring record counts, apex execution time, and total storage consumption every single week, you are not managing the org, you are just watching it drift. Just pull the reports, clean up the unused fields, and kill the workflows that have not fired in a year.
Performing a system health check is fundamentally an exercise in uncovering the skeletons your predecessors buried in the metadata. You start by pulling the Optimizer report, which will inevitably show you a horrifying amount of legacy code, unused custom fields, and profile bloat that makes you question why the system still functions at all.
The real work is not just finding the technical debt, but having the political capital to actually delete it without breaking the fragile dependencies that keep the business afloat. Most people treat a health check as a documentation exercise, but it should be a cleanup operation.
If you find that your org has more custom objects than actual business processes, you are already failing. Spend your time verifying that your security model is not leaking sensitive data, and then move on to the performance bottlenecks. If you try to fix everything at once, you will just end up with more technical debt disguised as a cleanup effort.
Evaluate your technical debt by quantifying the number of custom fields per object and identifying inactive users with active permissions. Verify that your security model adheres to the principle of least privilege by analyzing profile-level field security and permission set assignments. Monitor performance by reviewing your apex limit consumption and the frequency of platform event failures during peak operational hours. Finally, measure adoption by comparing license usage against active login trends and object-specific record update frequencies to ensure your team is actually utilizing the features you are paying for.
