Salesforce Roles and What Skills they Bring to the Project

Whether you’ve interfaced with the Salesforce industry before or, this is your first foray, the terms administrator, developer, consultant and architect are plastered everywhere, but often with vague explanations. For those that are not in the industry it is key to understand these roles as the skillset that they each bring will directly impact the solution that is delivered. The simplest way to understand what each of these different players bring to the development of your salesforce platform is comparing the roles to the players involved in the construction of a house.

The Salesforce Lie: The Administrator

An admin can be thought of as your handyman; they have the ability to do simple tasks such as paint and plaster and, maybe they dabble in a more technical aspect such as electrical wiring, but you would always want their work reviewed by a specialist. Similarly, the Salesforce Administrator dabbles in many elements of the Salesforce Platform, but often lack experience with enterprise architecture. Yes, the Admin can build you a report, add an email notification, or tweak configurative automation, but what about when you ask that Admin to build you a net new process? Would you want someone that can only paint walls building and designing the foundation of your new house? Salesforce has long touted the story of the Administrator, but the reality of what an Administrator offers has become more and more misinterpreted. The simplest way to think about a true admin is that they have the ability to maintain a system and tweak it, and yes they can extend it, but the solution delivered will lack scalability and flexibility.

The Code Junkie: The Developer

Your Developer can be thought of as a highly skilled electrician. This individual knows the inner workings of electrical wiring and understands how to extend and repair the system. Similarly, the developer lives in a world of code. They know Apex (the salesforce coding language) intimately, and can work hands on with lightning web components (i.e. LWC) and visualforce. However, the Salesforce platform has evolved tremendously over the last 5 years. The need for a true salesforce developer is becoming rarer and rarer with the evolution of the salesforce flow engine. Nevertheless, there are still situations where a true developer is needed such as if you are operating in a Salesforce Instance with a lot of legacy code, have automation with very complex logic or need a highly customized UI component.

The Mastermind: The Architect

When building a house you have to have a schematic. You need to know how the plumbing for the kitchen faucet impacts the plumbing that runs the shower on the second floor bathroom which impacts the type of shower head that can be installed…etc. The interconnectivity of all the different aspects of a house requires a great deal of meticulous planning to make sure that they are work together harmoniously. This is the responsibility of the architect. Similarly, in the world of Salesforce the Architect is responsible for designing the inner workings of your solution ranging from data models, automation patterns, and process design. These individuals often have both the background as a business consultants mixed with an in depth knowledge of the salesforce platform allowing them to help shape and build both your salesforce solution and business.

So what is a consultant?

Now that we have covered the main roles in the Salesforce ecosystem you might be asking yourself what then is a consultant? If you’ve worked with a Salesforce Partner before you have inevitably worked with a consultant. A consultant is just a loose term consultancies use to describe any resource on their roster. The actual skillset of this resource should always be vetted as they could range from a junior admin to a highly qualified architect. You just don’t know so it is always imperative to understand the resource being allocated to your project and make sure they have the skills required to complete your specific project. For instance you wouldn’t want a Salesforce Admin implementing Salesforce CPQ. So ask and understand the resources skills and project experience to make sure they match the work they are being brought in to deliver.

Don’t Forget

Of course there are more roles in the ecosystem such as an Integration Architect, CPQ Architects, Data Migration Specialist, Marketing Specialists…etc and we will discuss these in a future blog post. The key takeaway of this blog post is to understand the skillset that the core roles will bring to the build of your solution. Don’t get lost in the salesforce lie that all you need is an admin when what you really need is an architect that can design a solution that will grow and evolve with your business and not leave you an excessive amount of technical debt.

Previous
Previous

Salesforce Object and Field Naming Conventions and Why It Matters