OK, so normally I prefer to either write something with either a bit of a positive spin on it, or to focus on a topic that I don’t have to put any spin on at all. This post is going to be a little different … this is a post I’m writing out of a bit of frustration around some language around Flow that I have seen ever since I started using Flow. That language being that Flow is a Developer tool. The aim of this post is to allow me to share my views on this topic, highlighting that while there may be some truth to this comment, it is not ultimately a helpful statement to make. I’ll do my best to try and explain why this language is used around Flows in a bid to show both sides of the coin. If you’ve seen this kind of language and have any thoughts, I’d love to hear them in the comments.
For now, that all that preamble is out of the way, let’s dive in and first look at why this kind of statement is being made.
Arguments for Calling Flow a Developer Tool
When looking at the question of why do people say that Flow is a Developer tool (or at least one at heart), we first need to understand the reasoning behind such a statement. From my observations, historically there are three main reasons for it.
#1: Historically it Was a Developer Tool
The first and probably the quickest reason to unpack is that historically Flow was seen as a Developer tool. It has only been within the last few years that Salesforce has made a major push for Administrators to use Flow. Prior to that it was pushed as a Developer tool. Granted, some Administrators did use Flow prior to the recent push of it being an Admin tool, but this change did come until almost two years after Flow Builder was released in its current form. So simply put, this line of reasoning is down to a resistance to change. And I get it, change isn’t always easy … in fact it rarely is. But if we’re being honest this side of the reasoning is more akin to gatekeeping than anything else. Again, I get it … we all can be guilty of gatekeeping at times. That doesn’t really change that when we hear people say that Flow is a Developer tool, this is often part of the reasoning why those kinds of statements are being made.
#2: Flow Requires Knowledge That Traditionally Wasn’t Within the Admin Scope
The second reason on the list is that in order to be an expert Flow Builder, you will need to build up a level of knowledge that for a long time wasn’t traditional to the Admin role. Being an expert Flow Builder means you will need to understand things like naming patterns and conventions, and (of course) govenor limits. There is more that can be added to that list for sure, particularly when you go into things like Apex Actions, SOQL Queries and HTTP Callouts. But the two things I listed before, (naming conventions and govenor limits) are likely to be understand more widely by a Developer than an Admin. This comment is something I actually agree with, yes, Admins are probably less likely to know about govenor limits, that is absolutely true. But in my opinion, that isn’t enough of a reason to say that Flow is a Developer tool. Why? Because Admins can learn about these things. It is totally fair to say that these are advanced areas of knowledge for the Salesforce Administrator, but we can fairly say that Admins can (and should) go out and learn about these things, what they are, what they do, and how they affect the declarative automation that they go and build.
#3: Flow is More Akin to Programmatic Development than Traditional Admin
Finally on this list is the point that Flow is seen as being more akin to programmatic development than traditional admin. Again, this statement is 100% true. But once again I don’t think that is enough to justify calling Flow a Developer tool at heart. A lot of this point comes from the fact that what you’re doing in Flow is creating code. I’ll not say writing code, but creating. I do this to avoid causing confusion, as Flow is a drag and drop declarative development tool (I’ll get to that phrase later). When you add an element to a Flow canvas and configure, under the hood Salesforce is writing code for you. However, if we’re being extremely anal about it, this happens when we configure just about anything in Salesforce. When we create a page layout, lightning record pages, reports, fields, or anything else, we create code under the hood. This is why we can use tools like Change Sets and Gearset to deploy what we create between environments, when we deploy any of these things into a different environment we copy across the code that was built (we often cite this code as metadata. So with that in mind, does this not mean that any task that an Admin does becomes a developer task at heart? No! Of course it doesn’t, that would be a totally rediculous statement. So why do we do it with Flow?
One thing that comes up in my mind with this area is the comparison between building Flows and designing websites. Yes, there are quite a few difference between the two, but the comparison between declarative web design and coded web design aren’t too dissimilar to that of building Flows. In declarative web design, you tend to build pages where you drag components on to them and then configure them. We do this with Flow. In declarative web design (depending on the tool being used), you can also create custom elements and configure, this isn’t too different to creating resources in Flow. We don’t really turn around to people and say you have to be a fully-fledged web developer in order to build websites declaratively. So again, why do we do this with Flow?
To summarise, while it is totally true that Flow is significantly more advanced than Workflow Rules and Process Builder. I don’t think we can say in 2023 that Flow is a Developer tool due to these differences. Rather, we should call it an Advanced Admin tool.
Arguments for Calling Flow an Administrator Tool
Now that we’ve highlighted why Flow gets called a Developer tool by some. Let’s pivot over to the arguments for why we should call Flow an Administrator tool. This is the side of the fence I lean towards more to be honest with you. But I’ll try to avoid being biased. In this section, I want to offer three counter reasons to the argument of Flow being a developer tool. I think these reasons do a good job of covering the reasons behind why we should refer to Flow as an Administrator tool, rather than a Developer tool.
#1: It Keeps Us Consistent With Salesforce’s Messaging on Flow
First in my list of counter reasons is the simplest and quickest to explain reason on my list. The first reason on my list for why we should refer to Flow as an Administrative tool is because that is what Salesforce sees it as now. For those of us in the ecosystem who talk about Flow at events or in the content we create, we have a responsibility to ensure that we are sharing what Salesforce views Flow to be when we talk about it. Does that mean we have to necessarily agree with it? No, not at all. But how we should approach it is to say something like “Salesforce say that Flow is an Admin tool, I disagree with that statement because …”. Obviously we should list our reasoning after saying that. It’s OK for us to have an opinion that doesn’t line up with Salesforce’s messaging, but when it comes to a topic like Flow, I believe we do ourselves a real disservice when we peddle an opinion as fact. We need to be very clear that something is an opinion. Like here, this is my opinion. It is totally fine for you to agree or disagree with me. Now, do I think there is a better way to talk about Flows than it being either a Developer or an Admin tool? Yes … but let’s park that for now, I’ll come back to that as we close out this post. For now, let’s move onto my second counter argument point that I want to raise.
#2: It Prevents Creating Unneccesary Barriers of Entry to Using Flow
The second point I want to raise here is that referring to Flow as a Developer tool can cause unneccesary barriers to entry for Admins to go out and learn Flow. I have had conversations over the last couple of years with Admins who more or less are afraid to touch Flow because they’ve heard that you have to be a Dev to understand it. When we say publicly that Flow is a Developer tool, we only add fuel to that fire and switch off Admins who really do need to go and learn Flow from going out and learning about it. Because of the more advanced nature of Flow, we need to make the ability to enter into the Flow Building space more accessible, not less accessible. Ceasing to refer to Flow as a Developer tool, while also providing great content and learning opportunities on Flow will help Admins get hands-on with Flow, learn its nuances and become expert Flow Builders. If we’re going to brutally honest about it, the basics of Flow Building can be learnt in a matter of hours, the advanced level knowledge of it is something that brings a requirement to be constantly practicing, experimenting, and learning with it. But in terms of the basics, if an Admin was to give it the time, they could pick up the basics in probably around a day. So let’s be clear about this, let’s be upfront about what it takes to learn Flow at an advanced level, let’s also provided opportunities to help people learn it. We can and should already be doing this.
#3: Admins Don’t Really Have Another Option for Declarative Automation
Finally on my list of counter options is another simple one. That being that Admins don’t have another choice but Flow for the creation of declarative automation (or they won’t come sometime in 2025). So with that in mind (and tying back to my last point), why are we making this harder on Admins than it already is. Flow is significantly more advanced than Workflow Rules and Process Builder, we’ve already covered that. However, due to the retirement of Workflow Rules and Process Builder, Salesforce Admins MUST learn Flow, there simply isn’t going to be another choice. So why make it harder than it has to be? Once again, with Flow becoming the main (and one day, probably the only) tool for declarative automation, as Salesforce professionals we should be striving to make Flow as accessible as possible, and from observation there is still a lot of hesitancy from Admins to dive in with Flow. If we begin to stop referring to Flow as a developer tool, this will in turn help to make Flow more accessible to Admins.
OK, Based on Both Sides, How Should We Speak About Flow?
Now that we’ve covered both sides of the fence a little bit. Let’s now address the question of how should we speak about Flow? Should we refer to it as a Developer tool? Should we refer to it as an Administrator tool? Or is there a better way of referring to Flow overall? These questions are very valid in the discussion around Flow. As highlighted in the section on the arguments for referring to Flow as a Developer tool, Flow is significantly more advanced than Workflow Rules and Process Builder. This means that maybe simply referring to Flow as an Administrator may at times over-simplify what Flow is and what it can do. On the other hand, not referring to it as an Administrator tool and instead calling it a Developer can create hesitancy to engage with Flow, a hesitancy that is frankly irresponsible for us to create given the direction of travel that Salesforce has right now regarding Flow.
Like I’ve already noted, for those of use who present regularly on Flow or create content on Flow, we have a responsibility to not create barriers to entry for Administrators to get into Flow. And I have to say, I have heard many stories of Admins who have been put off in using Flow because of hearing how it’s “really” a Developer tool. I think we need to create simpler language around the tool, language that covers both the complexities of the tool, but makes it clear that Admins can (and should) begin to use Flow.
So here’s my thinking on it at the time of writing … please note that this could easily change in the future.
Flow is a Configuration Tool
So this is my thinking in how we begin to refer to Flow within the Trailblazer Community. So I’m going to be slightly controversial here and technically say that I’m actually beginning to think that referring to Flow as either a Developer or an Administrator tool is unhelpful to both technical personas. My current thinking at the time of writing is that it is actually going to be better to begin to refer to Flow as a configuration tool. This verbiage isn’t necessarily something I thought of myself, I’ve actually taken this from Cactusforce. Cactusforce has a track for Configurators instead of Administrators, the team use this title to cover topics that are a little more technical than traditional Admin topics, but are at the same time accessible to people working as Salesforce Admins.
In terms of reasoning behind the label of configuration, I think that this term acts as a healthy bridge between the Administrator and Developer roles. Both Admins and Devs should build up their knowledge and proficieny around using Flow. Also on a very practical level, what you’re doing when you build a Flow is creating and configurating automation. So configuration is in my mind a pretty helpful way of referring to Flow. It allows us to bridge between both roles while at the same time keeping things accurate.
Referring to Flow as a configuration tool also allows us to safeguard how we define Flow as we see more complex functionality come into play. Think of functionality such as HTTP Callouts and Flow Testing, both of these areas of functionality are far more technical than creating say a Screen Flow. Working with HTTP Callouts right now would either require JSON knowledge or passing that portion of the task off to a Developer, however in terms of how you actually build an HTTP Callout in Flow, it still works in the same way as a configuration task would work. Testing and debugging, is also more technical than point and click development (mostly), yet in terms of how Flow handles these things, it still is built via a configurational approach. I think these points go a long in showing that referring to Flow as a configuration tool is actually probably the right approach. But what do you think about this?
Closing Comments
So that’s where I’m currently at on the topic of how we refer to Flow when we talk about what type of tool it is. In summary, I think calling Flow a configuration tool may be more beneficial to both Admins and Devs than calling it either a Dev or an Admin Tool. Referring to Flow as a configuration tool accurately conveys what Flow is and bridges the gap between the two technical personas. But what do you think? Do you think we should refer to Flow as an Admin tool? Do you think we should it call it a Developer tool? I’d love to hear your thoughts on this subject in the comments below or in the comments on social media when I share this post. I think this is actually quite an important topic, referring to Flow in a way that is both true to what it is while at the same time doing so in a way that doesn’t create barriers to entry to Admins to go out and learn Flow is something that I feel is an absolute must. But I’d love to hear your thoughts, so let me know if you think I’m on the right track or if you think I’m completely off base on this front.
I’ll be back next week with not one, but two posts. The first will be a post on the One Flow vs Multiple Flows debate, the second will be a brief post that highlights what is coming to The Flow Architect over the month of March. I am working on releasing a blog series in March, it’s one I’m very excited for. So make sure to check out the post on that series when it goes live next Thursday.
Until then, thank you for checking out this post. And once again, I’d love to hear your thoughts on this talking point. See you soon.
