Admins / Career / Flow

Do Salesforce Admins Have Too Much on Their Plate?

By Nick Bryner

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 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.

The Author

Nick Bryner

Nick is a RevOps Solutions Architect at Go Nimbly. He loves connecting with people on LinkedIn, so go say hi to him over there.

Comments:

    Stacy
    August 19, 2024 6:03 pm
    Flows have slowed me down in the ability to create simple workflows. As an admin for over a decade, I was an advanced Workflow creator. There were limitations. When Process Builder came about, there was a small learning curve, even to how to access the Process Builders as that screen looked completely different than most other Setup pages. However, I developed fairly quickly on my own for this tool. When Flows came out, that was and still is a barrier for me. I continue to improve but would say I am only to a mid-level in proficiency and still outsource multi-step, complex flows as I would for APEX. We, my programmer and I, have debated the 1 flow per object (especially from reading your posts) and multiple per object, and keep coming back to the 1 flow per object would become unruly and too easily to likely mistakenly/by accident break/mess-up/change a part of the flow with unintended consequences. So, we use multiple flows per object but do try to name appropriately. I look at colleagues other software programs, such as HubSpot, that seem to be so much simpler and can accomplish something Salesforce would need a very complex Flow for, I am disappointed.
    David Allen
    August 19, 2024 6:33 pm
    I agree with all your points. And it is not just the more sophisticated automation requires the specialization. It is the fact that Salesforce is being used for many more businesses functions.
    sandra schanzer
    August 19, 2024 6:47 pm
    Salesforce originally said databases could be created using "No Software". Limited of course but easy to use and create. So the skills needed were analytical (about the business and people), understanding about building a database, and how people were going to interact with and use it. Of course that limited what you could do, but you could do a lot. And you could respond to a new or changed user requirements quickly. Which was the beauty of Salesforce. As someone who used traditional programming languages I welcomed the ability to respond the my users quickly. It was wonderful. To expand its usefulness and the market SF began to introduce more capabilities. Still good. And screens were simple, uncluttered, easy to design, explain, create. (Classic, workflow, process builder with all its flaws, I am looking at you). Then.. Lightning and flows. Every step has become far more complicated, far more expensive to build. More cluttered. More for a user to understand and learn but users just want to get their work done. Do they need/want so many ways to do a search? Further adding to the (needless) complexity are the periodic releases. I wonder what percent of new features actually get used and by what percent of customers. Salesforce, I think, has lost its focus about what it should be and has become the tool of its internal developers to the detriment of the actual builders and users.
    Gurney Halleck
    August 19, 2024 8:12 pm
    I understand that Flow is more powerful than WFR and Process Builders, but unlike the old tools, Flow is unintuitive, and the very complexity that makes it more powerful is why non-developers are having a hard time. Looking for guidance online generally results in some solution that's not always close enough to what you're trying to do for it to be of any help. Attempting to contact support, even with a partial solution generally ends with a statement about limitations of support. And as usual, Salesforce documentation is half-baked. So all that's left is trial and error and Google searches, and that takes time that a lot of SF Admins don't have, which is never an excuse for the boss. So to answer your question, yes, I think most SF Admins have too much on their plate. Flows has been nothing but frustrating, and coupled with the lousy design of the Lightning interface, I'm actually starting to look at other career paths.
    Kevin Hastings
    August 19, 2024 8:16 pm
    This article expresses perfectly what has concerned me the past few years. I did like being in the middle of it all to serve the business. It is just not possible to go forward like that.

Leave a Reply