4 Symptoms that Indicate It May Be Time for a Salesforce Health Check

Every Salesforce implementation deserves to be re-evaluated and re-examined. It is an especially expensive investment and it’s reassuring to know that the investment is paying off – that the system is still solving the problems it set out to solve and that users are readily and happily adopting it.

Unfortunately, no Salesforce implementation is protected from the effect of general wear and tear that evolving business processes,requirements and organizational changes can have.

Yes, it can be costly to continually keep up, but not keeping an eye out for these 4 symptoms could result in a much larger, much more expensive problem down the line!

The Symptoms:

Objects and Fields that No One Uses

It’s a fact of development that the way things are designed won’t necessarily be the way things are used. Only time and the user will tell. However, if you’re noticing several fields in your implementation that do not serve a function other than being used as holding areas for miscellaneous notes and comments, it could lead to inconsistent data, bad reporting, and further confusion down the line. Deleting these fields and objects is no easy job. Usually fields are being used by other integrations or processes and may contain valuable data (at least to someone). The proper data validation, extraction, and impact analysis is usually required before acting.

Non-Salesforce Workarounds

Are your users turning to systems outside of Salesforce to get what they need done? Is it easier to extract a report from Salesforce and run a pivot table to present during meetings? Are sales users keeping tasks and notes in excel files? These can be signs of a more serious syndrome called low-adoption-itus (LAI) and may be caused by a mismatch of functionality and practicality. If processes are not defined and trained, and data is not easily accessible to those who need it – users will begin leaving any CRM to get what they need.

Low Code Coverage

Are you passing production validation by the hair of your chinny, chin, chin? That’s not going to be sustainable for long, especially with a big, important deployment. Sometimes you know something works – but you don’t want to be bothered writing the extra test methods to get the code coverage. It’s kind of like playing who will finally take out the trash with your college roommates until trash spills all over the floor and the apartment smells for 3 months straight. Side effects of Low Code Coverage may include: acute anxiety about deployment.

A Broken Security Model

Do more people have Admin access than don’t? That’s not a good thing, but easy to understand – a specific security model was designed, and access was slowly granted to specific fields, then specific records, then specific objects… until caving in and just giving everyone access. It can prove detrimental due to increased risk of internal data compromises which can damage client relationships or violate regulations. Salesforce offers a wide range of tools to properly grant access at the necessary levels, so take advantage of them!


What is the best thing to do if yours or a loved one’s Salesforce Implementation is suffering from one or more of these symptoms? Reach out to your Salesforce professional immediately – grant.ongstad@theofficegentleman.com or visit www.officegentleman.com to learn more..


What Makes a Salesforce Professional Valuable

It’s a big world for the Salesforce professional. There are tons of features to learn, tools to master, certifications to grab and trails (Trailhead) to be explored. There are weekly meetups, online communities, conferences, webinars and workshops. If desired, one could LITERALLY eat, breath, sleep, and dream Salesforce.

To a large extent, I too am involved in the community. I have certifications. I do the Trailheads (Expeditioner), and I try to stay abreast on new tools and functionality. I believe it is my responsibility as an admin/developer to keep learning.

However, I sometimes have a fear that Salesforce professionals dance on the precipice between professional understanding of the tool and obsessive loyalty.

The obsequious professionals collect and treasure digital accolades like badges and certifications a little too much and it’s common for many to have a few years of professional experience in the application development world.

To be clear, this isn’t a BAD thing. In many ways, this is not dissimilar to my experience. See my previous article: https://www.linkedin.com/pulse/perfect-detour-from-english-major-personal-trainer-grant-ongstad/.

In my work experience as an Admin/Developer I try to keep remembering two simple things:

1)     Serve the Business, Not the Application

Unless you work for Salesforce, Salesforce doesn’t pay your bills – the person or organization that signs your check does. They use Salesforce because it may be a tool that can solve their problems and help scale their business and, in some cases, it may not be.

They do not care if you use flow, process builder, workflow rule, or apex they only care if you solved their problem. If Salesforce reporting cannot handle their unique groupings and summaries as well as an existing excel report – don’t be afraid to tell them!

Businesses don’t just hire Salesforce professionals because they know Salesforce, they hire them in the hopes that they can solve their problems.

Whether you are an Admin, Developer, Cloud Consultant, Salesforce CPQ expert, Architect, or all of the above, your first allegiance is to the business and its requirements.

My boss once told me that tools and applications come and go but if you can understand the goals and mission of the business, how it operates, and where they are heading that I’d always be in demand.

2)     Be a Solution Architect

Every change, customization and enhancement should be considered in relationship to the entire system architecture. You are not just an order taker who reads a requirement and implements a change without question. What effect will this change have on existing customization, user experience, reporting etc.? Are you making assumptions about how users are interacting with the system vs how they are actually using it?

A solution architect thinks ten steps ahead when implementing or recommending a solution rather than jumping to the neatest and shiniest tool. Sometimes the solution is a change in an internal process.

I don’t intend to throw shade on those who truly love Salesforce. For many of us, the tool has provided a rewarding career path and I believe the demand will only continue to grow. It is also tremendously important to have skilled users of the tool. Everyone who wears the badge (yes, on Trailhead too) of the Salesforce professional should have an in depth understanding of it.

I only hope that we never lose sight of the customers we serve and of the skill that make us most valuable: The ability to understand and solve problems.