As we approach 2023, it’s time to think differently about our most powerful and robust professionals in the Salesforce ecosystem: Administrators.
Admins are the Swiss Army Knife within the platform: acting as Business Analyst, Data Analyst, Configurator, and in many smaller organizations, Architect.
The power of Salesforce is that it doesn’t take a solid technical background to set up – at least on the surface. It is easy to take some Trailhead lessons and be off and running, often landing a job as a Solo Admin in an organization.
We mainly learn what we have encountered in our travels. A Solo Admin knows to fail fast and learn fast. The most successful are like a mechanic, tinkering, adjusting, and learning how their org runs. But they don’t know what they don’t know.
They don’t get the privilege of code reviews. Others question the changes they’re making and suggest an alternative way of approaching a solution.
The rookie Solo Admin makes configuration changes tentatively at first. A talented Admin (Engineer, Analyst, Architect) reviews their prior work and realizes what they may have done differently.
Challenges
Admins that work in silos or do not gain exposure to other technical areas may face a few challenges in their journey. Specifically, if we toss an apprentice Admin into a complex business without support, we face the following challenges:
- Design and Architecture that may not scale
- Do we miss better technical solutions (Opportunity Costs)
- How do we know we’re building correctly (It worked, but why?)
When I started with Salesforce, an Admin’s focus was relatively small. We leveraged our Developers for Triggers and Automation as we had only Workflow Rules to use. The design was pretty simple as we had page layouts, not the robust Lightning Record Pages we do today. Our data model was relatively simple, and we didn’t have easy, out-of-the-box solutions to move data from point to point. Event-Based Architecture, don’t even think about it!
I have come behind several organizations that have been a mess. You know the ones I’m talking about: everyone is an Admin, workflow rules galore, tons of custom fields, public reports that are duplicative, custom objects that are duplicated where a record type should have been, and more profiles than users even.
These organizations usually come from an overworked Admin or an Admin who lacks a solid technical design foundation.
Worse are those Admins who get pressured by others in the business who may have had some Salesforce Admin experience but did not receive exposure to best practices. They are pressured to build something that may not be best practice or doesn’t leverage modern design principles, such as Flow or Lightning Record Pages.
Disclaimer: I love Accidental Admins; they are great for the community. We should celebrate that we shipped a working feature. Still, we perform retros to understand why we should have designed it differently.
The Technical Challenges
Salesforce is a fast-moving ecosystem and is an open platform. Unless we take our time to learn about changes and new features, we are doing ourselves a disservice.
Admins need to understand that Lightning Web Components can display data that would typically take 3 or 4 custom objects in the data model.
Admins must know about OAuth tokens and Connected Applications. Admins need to understand security practices: that managed package that the business wants to install, oh, it wants Modify All despite only reading records from your organization, what is that about?
As Salesforce becomes increasingly the hub of a connected ecosystem, Admins will need to know more about how APIs work and error handling. What’s the order of operations? How do they investigate API failures from a connected application or event bus?
When we build Flows, we need to understand sound design principles and how DML works. Typically something that is left for Developers. This is a lot to take in.
DevOps is the new buzzword. But have we empowered our Admins to be able to read metadata? Our Admins know what it looks like in Setup, but what does the XML tree look like? Do they know how to look at a delta diff when they do a code review? Is it really a change or just the way git handles XML?
How do our Admins handle VCS? Are we empowering them to understand how VCS works and concepts such as commits, Pull Requests, Rebasing, etc.? These are concepts typically left in the hands of developers.
DevOps Center does a fine job abstracting these concepts. Still, for proper troubleshooting, our Admins must know the basic concepts to succeed.
Trailhead does have introductions to Git and VCS, but we need to dive in deeper. We should present our Admins as technical resources and leverage them as such.
The Path Forward
From a corporate strategy perspective, we must admit that Salesforce is robust but requires attention to harness its full potential. We should treat it with the respect that we do our bespoke products.
Team Structure
Salesforce teams should work technically and enforce their boundaries. Working with these boundaries will allow our teams to work creatively and design for the long term.
When every project is a fire, we tend to build ourselves into a corner, reacting to what’s put directly in front of us. If we allow our teams to breathe, we receive better results and foster creativity.
We should work to improve our intake processes, ensuring that incoming work is appropriately sized and specced. This allows us to bundle work and not be so reactive. This empowers our teams to think larger and see the big picture versus working on tickets verbatim without seeing the impact.
Skillset
As the platform scales, knowing each area of Salesforce becomes difficult, and we must specialize. Business Analysts, Developers, Administrators, and Architects are individual roles for a reason. They each require a particular skill set.
Business Leaders should realize that we wouldn’t have our engineers close our ledgers, so we shouldn’t expect accountants to code (but don’t stop them if they want to!). Dedicate room in your budget to hire dedicated expertise to support a vital tool within your business.
Salesforce is easy to learn the basics and start configuring. But, as the saying goes, it’s enough to be dangerous. Designing the most efficient way is a learned skill. We should provide training, resources, and mentorship to our team members. Hence, they gain exposure and develop best practices. Splitting time between your regular job function and administering a SaaS platform can lead to burnout and not provide the opportunity to grow as a technical professional.
We should provide our Admins with experience outside of Declarative. Yes, that’s a hot take. But, our Admins should understand how to integrate two platforms through standard design patterns. This teaches our teams to not force custom objects to store data that can be retrieved at runtime. Reducing our footprint and staying DRY.
Feedback Loop
We must provide a feedback loop to our teams and build the documentation around our projects. These ceremonies and artifacts help everyone involved learn and provide snapshots into our thought patterns.
We can reflect upon our prior decisions and understand their context as we continue to iterate.
Additionally, we should empower our Admins to think like Architects and Developers. Just as we should have our Developers think like Admins, etc. This breaks our standard thought patterns and allows us to devise alternative solutions.
As our Admins stretch their Architect wings, we should then provide feedback. Coaching what went well and opportunities to approach a solution differently. This does reduce the number of features shipped within a release in the short term but increases velocity in the long term as our team knowledge grows.
Salesforce continues to be a phenomenal ecosystem to be a part of. Seeing folks switch careers or learn new skills they never dreamed possible is fantastic. However, we shouldn’t shortchange them or our community by not providing support and resources to them.
We shouldn’t put Junior Administrators in a position where they are Solo Administrators that feel pressure from sides of the business that stunt their growth.
Conversely, we shouldn’t spec our stories so much that our Junior Admins can’t learn how to design solutions. If we always give our teams the answer, they’ll never know how to ask the right questions.
I look forward to seeing the ecosystem grow in size and knowledge. I will keep my inbox open for folks to bounce ideas off of.