If you asked me three years ago, “What are the main skills a Salesforce Admin needs to be successful?” I probably would have said something like business analysis, communication, and building automation in Salesforce. This is still true, but the “building automation in Salesforce” point now has some serious asterisks next to it.
Back in the days of Workflow Rules and Process Builders, an admin could deliver incredible value to stakeholders with relatively little effort. This isn’t to say it was a perfect system. The tools had some pretty big limitations, and any Salesforce Developers who were around years ago probably have horror stories about some Process Builder breaking their code. However, the turnaround time from when you received a stakeholder request to when you had a solution deployed was pretty minimal.
Then Salesforce made the earth-shattering announcement that it was going to deprecate Workflow Rules and Process Builders in favor of Flows. It is hard to overstate exactly how enormous of a shift this was for the admin profession. Even if you have something really simple you want to do, like update an Opportunity field when the stage changes, Flow is the tool you need to use.
Don’t get me wrong. I’m not saying this was a bad call on Salesforce’s part. It was the right move for the platform. Flow is a much, much better tool to build with. However, there are some far-reaching downstream effects that are worth discussing as a result.
The Need for a Developer Mindset
The scale and complexity at play with Flows are orders of magnitude greater than what existed with Workflow Rules and Process Builders. Spend any time with Flow experts on LinkedIn, and you’ll start seeing phrases like “Flow Patterns”, “Flow Interviews”, “DevOps”, “Governor Limits”, “SOQL”, and so on.
I’ll give you a few examples of what this complexity can look like in practice:
- Bad practices – like putting an update element inside of a loop – aren’t obvious. If you don’t have a mentor around who can help you learn these things, you can expect to lose much time to bug-fixing.
- Testing Flows is an enormous burden. I’ve had times when a change I made to a Flow broke something totally unrelated on a different object. Really testing a Flow often means laboriously going through some list of manual tests or having your end-users do QA for you in production (this is widely considered a bad idea).
- In just the last week, I’ve seen earnest debates on LinkedIn about whether or not it’s a good idea to use a single Master Flow per object that might call multiple Subflows or if you should use multiple independent Flows. I do think there is a right answer to this question, but the fact that the answer isn’t obvious is my point here.
- The more Flows you have, the more important certain practices become, such as having consistent naming conventions. If you can’t look at a list of Flow names and understand where each lives and what it does, that’s a problem.

The main point here is that the amount of skills and technical knowledge needed to properly manage your Flows is significant. Flow is declarative code, and coding concepts, practices, and tools are generally the solutions to the problems I described above. While many of the practices I’m mentioning would ideally have been used with earlier tools, the consequences of not doing so with Flows can be staggering. If you expect to be building Flows, you need to take some time to learn where Salesforce development concepts apply to them.
If you’re looking for a good place to start, make sure to take a look at the following resources:
- The Ultimate Guide to Flow Best Practices and Standards
- Record-Triggered Automation
- Mastering the Art of Salesforce Flow Architecture: 7 Tips to Rule the Org
- Flow Conventions
The One-Man Band… Except It’s an Admin
Building quality software is a multi-faceted endeavor. It requires business analysis, product management, data integrity, UX/UI design, project management, architecture, DevOps, QA, security, software development, and so on…
This usually takes a whole team to manage. Now consider how many of those functions your typical admin takes on – sometimes by themselves. There’s obviously going to be loads of variance in the specifics, but it’s very common to see admins wearing many hats at the same time.
This isn’t a new problem. This has been the case for a while now and some admins thrive in it. At the same time, there are not many people who can juggle that many responsibilities effectively. There’s a reason why software developers don’t do all of that stuff by themselves.
This dynamic got dialed up to eleven after Salesforce’s announcement, though. We’re asking admins to remain incredibly business savvy while also raising the bar on needed technical skills. It’s getting a bit suffocating…

Takeaways
In the future, I expect we’ll see more Salesforce Admin teams dedicating people to specific functions like Business Analysis and QA. There are some challenges here, though, as one of the biggest value-adds of a good admin team is the close relationship they have with their stakeholders. Care will need to be taken to ensure that isn’t lost during any transition.
If you’re an admin right now, it would be a good idea to give some thought to what you want your career to look like long term. If you’re really into the business analyst side of things, consider talking with your manager about shifting your focus to that kind of work more explicitly when the time is right.
If you want to continue with Flows, you’re going to need to start learning how to think about Flows like a developer would, as I mentioned above. Take special care to learn how Salesforce expects you to manage Governor Limits and when Apex should be used instead of Flow.
Summary
Flows, while incredible, are significantly increasing the skills required of admins. Admins have always been multi-functional, but it’s reaching a point where this is becoming problematic.
Having admin team members specialize in dev-team-like functions will be a great way to manage this. Any admin who wants to continue building Flows should spend some time learning relevant Salesforce development concepts.
Any thoughts? Share them in the comments below.
Comments: