After being fresh back from TDX22 we are filled with enthusiasm and vision so look forward to seeing some awesome site updates. In the meantime though we had to get this off our chest. We spoke to so many people who identified as an admin who are most certainly #NotAnAdmin.
What is #NotAnAdmin
Salesforce has grown in leaps and bounds with new product offerings coming so frequently it’s almost impossible to keep track. However, the title we use to describe the different job roles most certainly have not. So we wanted to talk about what we understand a Salesforce Admin to be and share some roles we’ve seen along the way. So read on and see if you are #NotAnAdmin.
So of course lets start with a confusing diagram to show all the different roles we use and their career progression. Don’t worry: we are going to break this down. To start lets look at the different buckets of roles:
- Green: Individuals in these roles primarily focus on documentation and organization.
- Yellow: These individuals live in the Salesforce declarative world.
- Blue: These individuals live in the code and integration world.
- Orange: These individuals act as the conduit between to the Green world and the Yellow and Blue world.
Check out the details of these roles to learn about them in greater detail. Now don’t worry if you don’t immediately see an exact match to what you do. This is Salesforce after all, we still wear lots of hats.
- Drafts training documentation
- Crafts user stories
- Drafts demos/backlog stories
- Coordinates timelines
If you are known for your detailed documentation and always knowing the schedule you may be a Salesforce Business Analyst.
You’re the director of the ship and rely on your team to keep the ship afloat. You make sure the work agreed to is always being done.
If you find yourself taking the birds eye view and delegating the details you may be a delivery lead.
You also have a birds eye view, but you think in metadata and integrations. With a full understanding of the power of Salesforce you advocate for using the right system for the right job and see how Salesforce fits in a vast technical landscape.
You are the machine that keeps the Salesforce environment working day to day. Onboarding users, drafting reports, and overall fulfilling the details many others miss. You may not build a lot but with time you understand the Salesforce environment better than anyone and know how to translate the little painpoints in things your development team needs to address. The business turns to you for support and you are there to give it.
While you started onboarding users and building reports you were drawn to building more. The declarative framework of Salesforce has let you scale and now layouts, declarative automation, and built in Salesforce tools are all under your command as you update the system to resolve the day to day needs of your user base. Some stories still come with a framework of how they will play with others, but for small builds you got this.
Declarative Salesforce is a strong tool and your familiarity lets you design with ease. Instead of a quick layout update you’re thinking in multi object schema and chaining tools to reach your end result. You keep the developers on their toes, you know how to build without code.
Your mission: to break things and protect the end users. You run through scenarios and make sure all the boxes are checked. If your company has automated testing, you understand it and leverage it. No breaking Prod on your watch.
You don’t understand why Apex and LWC components get so much flack. They are super powerful. You make sure Salesforce does whatever is asked of it and customize to fit when declarative just isn’t the right tool.
When it comes time for Salesforce to talk to other systems or stage incoming data you are the translator that makes sure there are no miscommunications. You also view the code framework and make sure everything fits together nicely.
There are many backgrounds that lead to tech lead, but at the end of the day you are the translator between the business requirements and the technical requirements. You make sure the development team is not overly literal and the business team is not sending half baked ideas.
If you’ve ever mentioned “Shipping code” you likely have worked with or done the work of a release manager responsible for making sure good quality work is delivered on time. You also find yourself chasing errant developers who haven’t refreshed and promoted their work and admins who forgot to tell you changes were made until things got overwritten.
From the diagram you can see there are many paths highlighted, but bear in mind we are trailblazers, we don’t have to stick to these paths.
Small Business = Many Hats
If you’re at a small company I’m willing to bet you are #NotAnAdmin. You talk to end users, build to fix items and scale your knowledge quickly to meet today’s brief. Your role is whatever the business needs.
So what do you think are you #NotAnAdmin?