In this world, there are many different varieties of the same things. As I look out my home office window, I can see my neighbor across the street planting flowers. I don’t know what kind they are, but seeing the pinks, yellows, and purples, I know they’ll be pretty, regardless. The same applies with articles of clothing. Shirts and sweaters are different, but they cover one’s torso. Shoes and sandals protect one’s feet. It’s these core elements that allow things to be different, but still fulfill a common purpose in their existence. However, as we stray from core tenants, things slowly cease to be what they were originally intended to be, and that’s not always a good thing.
Three things in this world I’m fascinated by are cars, food, and Salesforce.
Start with the elements of a car: 4 wheels, an engine, doors, seats, steering wheel, safety belts – every consumer-grade vehicle has them. Some vehicles are sedans, some are SUVs, and others are pick-up trucks. They all still have the same core elements. But what happens when/if you swap one part out for another for the sake of creativity or uniqueness, like replacing a steering wheel with an airplane-style lever. Saab tried it in the 90’s giving the driver minimal control, along with creating a switch labeled “Extra” that did absolutely nothing. Saab quickly transitioned from the pride of Sweden to a General Motors subsidiary, and now is no more.
My other car-related passion is Formula 1 racing. In the 1970’s, the now-defunct Tyrrell team experimented with a 6-wheeled car. The theory was 6 wheels would give the car more contact with the track, therefore increasing traction in braking. The design even powered the team to a 1-2 finish at the 1976 Swedish Grand Prix, but overall saw more problems than successes. Smaller wheels meant quicker wear, more strain on brakes to slow down from high speeds, and an unacceptably high number of race retirements due to unreliability.
Food is no different. Everyone has a favorite dish or cuisine, and some have versions that are forbidden from change because “mom made it perfect” or “I’ll only eat it at this restaurant”. For a home cook like myself, I know there are ingredients I can swap with no penalty.
When the garden flourishes, my wife makes her own homemade sauce, but Costco’s 3-pack of the big Prego bottles keep us going through the winter
Either way, we’re using a tomato-based sauce intended for pasta when we tell the kids it’s spaghetti night. But if you’re familiar with Honey Boo Boo and Mama June, you know there’s a way to absolutely ruin a dish (see “sketti”). KETCHUP AND SPAGHETTI SAUCE AREN’T THE SAME THING, EVEN IF THEY BOTH COME FROM TOMATOES!! …sorry, minor rant.
So how does all of this relate to Salesforce?
When you as a Salesforce customer activate your org, you get core functionality on day 1: Accounts, Contacts, Opportunities, Workflow Rules, Reports, et cetera. Like the shelves of an auto parts or grocery store, Salesforce also gives you different ingredients to make customized variations on the standard core functionalities: custom fields, custom objects, Flow, Apex and Visualforce. But as you fill your org with customizations that steer you away from core functionality, the onus is on you to ensure there is still balance within your process.
Just as a gourmet chef has to carry a light hand with salt, and a mechanic that fits larger wheel rims has to readjust rotation meters for proper speed and distance, a Salesforce administrator or architect has to understand and respect the magnitude of how over-customization and over-development can kill an org’s usability.
When I was a Salesforce customer, I inherited an org that never had an admin, but was loaded with tons of customization.
Looking back, I should’ve been a little more intimidated by an Opportunity object with 300 fields, 60 validation rules, no record types and only one page layout…but I was new to Salesforce and general system administration, so ignorance was bliss. For the first few years, I just learned to live with it, adding new fields and new validation rules whenever someone asked for something new. But eventually, I figured out it was no longer tenable. Following 6 months of heavy scrutiny (as a solo admin), I discovered half of the validation rules enforced business requirements that could’ve otherwise been handled by dependent picklists, another quarter of the validation rules were based on requirements at certain stages and fixable by applying record types, and almost 100% of the near-0% adoption was due to every user landing on the same page layout with the same (lack of) required fields.
Just because Salesforce allowed my org to have more than 300 fields on an object doesn’t mean I should’ve fostered it. Just because you can put nacho cheese on salmon doesn’t mean you should.
So, after 7 ½ years of living happily in the Salesforce ecosystem, the last 18 months of which have been as a consultant, how do I approach an org? One of the biggest things I’ve learned to appreciate since jumping from the customer space and into consulting is that not every org is the same. Not every customer is the same. Not every industry is the same. Some industries are regulated, some aren’t. Some companies have strict Change Management protocols, while some empower admins to deploy Change Sets to their hearts’ desire. And some companies even have admins who also sit in the corner office on the top floor of the building with his or her name on it. But one thing is the same: all Salesforce orgs come with the same core elements out of the box.
As I prepared to leave my role as the solo admin in 2016, I spent nearly a month documenting every little nuance about my org because it was heavily customized. My unknown successor wouldn’t have been empowered to just pick up the ball and run with it. If I had made a more concerted effort in my 6-year tenure to develop closer to core functionalities, the documentation could’ve been less technical and more business-related. So now as a consulting partner, whether implementing a new org or enhancing an existing org, I try to correlate all requirements to core functionality as much as possible. An Account doesn’t necessarily need to be a company or a customer, it can simply be a group of Contacts who share a common attribute or physically meet in the same location (therefore leveraging native location functionality and Account Teams for multi-user support). An Opportunity doesn’t have to be driven by Sales. It can be any process that starts as an idea and evolves into a tangible final product over time (therefore enabling Kanban Boards for visual progress indicators and a drag-and-drop user experience). Cases aren’t limited to customer complaints. The object can be repurposed as a Salesforce work request system for your internal users (therefore leveraging native Case Comments and Web-to-Case to be applied to an intranet site).
Always strive to wring every single ounce of potential out of those core functionalities in your orgs. If you correctly leverage core functionalities as much as possible, nothing should “break” when Salesforce pushes its 3 major releases throughout the year. But if something should break, you as the admin are empowered to quickly diagnose and fix the issue because it was built with certified genuine Salesforce parts. Speaking big picture, the goal of any admin or consultant is to build sustainable solutions, gain satisfaction and trust, and create partnerships that allow products to grow alongside the business. And all by respecting the flavor profiles and integrity of the ingredients provided by Salesforce.
Mike Walzl is our Chief Operating Officer at Clarus Group. Mike has over twenty years of experience in the staffing and consulting industry, beginning his career as a recruiter. His areas of focus throughout his career have been: Technology, Accounting, and Finance. As COO, Mike is responsible for corporate strategy, development and overall growth of Clarus Group.
