In this week’s episode of the Talent Hub Talk, we’re joined by Stephen Church, a Salesforce Administrator based out of the US. We asked Stephen to come onto the show because of the content that he puts out regarding Salesforce flows.
We explore Stephen’s background, how his career got started, and how he found his way into the Salesforce ecosystem. Stephen talks about how he came across Salesforce flows and how he got comfortable building the automation. He shares the best practices around building flows, different considerations, and the different types of flows that are available. Stephen also offers advice on how other people can get comfortable building them.
We hope you enjoy the episode and you can find Stephen on his LinkedIn page!
Ben (00:00.545)
Stephen, welcome to the show.
Stephen Church (00:02.786)
Thank you so much for having me. I’m excited to be here.
Ben (00:05.377)
Two English guys on opposite sides of the world that left the nest, hey?
Stephen Church (00:09.978)
I know, we’ve kind of similar directions but completely opposite ways around the world, right? And it’s quite funny actually, that happens quite a lot. I’ve met, when I was at Dreamforce and met some people and they’re like, “I had no idea you were English”. Because most of my content is written, so I might keep it that way. It’s like the element of surprise when I meet people.
Ben (00:42.873)
Yeah, well, look, we’ve got a lot to dive into today. I’ve reached out to you because, like you mentioned, you write a lot of content. I’ve read a lot of that and I really like the things you talk about. But I also know that they’re really important because obviously I’m speaking to people daily about the Salesforce ecosystem, about careers, jobs and direction, I guess, that the platform’s going in. And you talk heavily about flow. So we’re going to get into that today and look at some of the things you’ve been doing in that space, but I always like to start looking back at your earlier career and how you’ve ended up where you are today. So can you tell me a bit about your early career aspirations and how your career really got started?
Stephen Church (01:26.058)
Yeah, I made the choice to study journalism at college, university, but didn’t really ever feel compelled to do it and pursue it in the end. So I think maybe like many people feel, I’ve spent quite a bit of time not being exactly sure on what I wanted to do with my career. After college, I spent some time working in the financial sector in the UK. When I got here, the experience I had in finance didn’t really count for much out here because it’s sort of a different financial system and all that stuff. I ended up getting an entry-level sales job at a company here where I ended up working for nine years. That was really good because I had a bunch of different roles at that company. Sales, account management, research and development, change management. I was a Business Analyst and then my very last role at that company was managing a team of BAs. Although I spent that early part of my career sort of jumping around different roles, I look back on it being incredibly valuable because I feel like I got this broad exposure to different areas of the corporate world. So that’s how I got started.
Ben (02:44.157)
And can you think about some of the skills or experience that you gained in those earlier roles that actually set you up for success in the role you do today?
Stephen Church (02:55.242)
Yeah, so especially in my time when I was in sales and account management, I was on the phone with customers, quite a lot of potential customers. So I know how challenging it can be to be on the front line serving customers. And when you’re in that role, how important the tools you have are and how big a difference they can make if they’re easy to use. So I think the empathy from that time has come in really handy. Obviously, that’s on the front line and also in my time as a BA as well. In the finance sector, a really interesting part of working there which has come in handy is, I was part of a team that managed big corporate clients. So it was actually my boss that had ultimate responsibility for it, but I was there in meetings and conversations with executives that are running these big companies. And that was really super helpful to be part of because that’s been invaluable when it comes to managing stakeholders, which we all know is really, really important in Salesforce. And then the attention to detail. Obviously in the financial sector, I was looking at profit and loss sheets, balance sheets, applications for credit, that type of stuff. And when I was a Business Analyst, I spent a lot of time analyzing business processes, thinking about how they can change and documenting them. So really the attention to detail that I got to practice over those has obviously come in very handy in the Admin role too.
Ben (04:27.189)
For sure. So where and when did your path and Salesforce cross and what was the initial involvement?
Stephen Church (04:37.738)
Yeah, it’s an interesting one because, so I’ve been in the ecosystem and I’m defining that essentially as when I became an Admin. So that’s like four years now, but it was probably back in 2012 when I actually first became aware of what Salesforce was. So there’s been quite a long gap of knowing what Salesforce is and vaguely what it does before really and truly getting into it. So back then the company I was at, they signed up for Salesforce and started using it. By that time I was no longer in my roles in sales or account management, so I wasn’t really a regular end user of it. So I didn’t really think too much about Salesforce at that time. In one of my later roles in a sort of change management position, I was responsible for creating and maintaining articles in the Salesforce knowledge base, and then creating some training content. So that definitely required me to get a bit more familiar with it, but it still wasn’t super in the weeds. It was more just content creation and people are telling me what to write about Salesforce. I’m not necessarily knowing every detail of it. So it was really when I got into a role as a Business Analyst where I really became more curious about it because at that point I was gathering requirements and writing user stories for different technical teams, but one of the ones we worked with most was the in-house Salesforce team. So I want to be clear, like when I say I was a Business Analyst and working with Salesforce, I was totally not like the Salesforce BAs in the ecosystem who are certified and all of that stuff. I would have failed the exam miserably at that point in my career. But I think what it did is like being in the room with the Salesforce team really kind of helped me learn more about it and started to kind of generate that curiosity in the platform.
Ben (06:26.243)
And so how did that transition into becoming a salesperson happen?
Stephen Church (06:31.146)
Yeah, so I was doing this BA work where I was listening to teams talk about Salesforce and other platforms too and technical solutions and that really kind of sparked a desire in me to move into a more technical role. So I’ve been doing BA type work maybe for three or four years. But yeah, seeing all these types of discussions made me want to get a bit more technical. So what I started to do is I dabbled with different things. I took some courses on Codeacademy at work. I had to write some sequel every now and then, which I sort of just figured out as I went along. But what I found is I never really stuck to learning one thing in particular. And I think part of that is I didn’t really see a path from dabbling on Codeacademy to change in my career. So I can’t remember exactly how I came across Trailhead. But really I started learning on the platform, really enjoyed it, and through that I could see and learn about the Admin career path. So at that point, given my background and given I didn’t code, it felt like a good way to move into a more technical career. So I’d really say one, the desire to have a more technical role, and two, the perceived low barrier to entry to the Salesforce Admin role was really what sent me down that path. And I’m careful in saying perceived because I know obviously finding the Admin job can be pretty hard for some people finding the first one, but that’s the sort of the feeling that sent me down that path.
Ben (07:59.709)
Yeah, that makes sense. So did you transition into an Admin role with the same company or did you gain exposure and experience and then seek employment elsewhere?
Stephen Church (08:09.662)
So it worked out that when I got certified and I wanted to start looking for roles, there was unfortunately no Admin openings at the company there. And they were willing to help me learn, help me observe people and learn that way. But ultimately, there just wasn’t an open position at that time. So I ended up looking around and found a different role somewhere else. Because I wasn’t really sure how long I’d have to wait around.
Ben (08:32.029)
You mentioned obviously it is hard to get your first role, but to move internally with a company where you’ve got a track record of success and you’re known is probably easier than finding a row externally when you don’t have a track record as a Salesforce Admin. So what was the position? Was it like a junior role or were you able to kind of jump that level because of your previous exposure to the platform?
Stephen Church (09:08.058)
So just to be clear you’re talking about my first role elsewhere, it wasn’t specified as a junior role specifically. It was a new org that was hiring two Admins and one Developer, I believe. And both the Salesforce Admins were both called just Salesforce Administrator. So it wasn’t explicitly a junior role. The other Salesforce Admin, she had a few years of experience. So she was sort of the more senior one on the team. So yeah, there were probably some situations where I was doing slightly more junior things.
Ben (09:42.041)
Was it a challenge to find a role? Like, it is a challenge now, right? Do you feel that companies, when you were interviewing and looking for a role, took into consideration the BA work you’d done in the Salesforce world and saw that as experience, like counted that towards your transferable experience?
Stephen Church (10:02.62)
Yeah, I definitely think that helps. Because if you can just sort of, I think going in there and knowing what Salesforce is, and you know, you pick up certain, when you hear these technical discussions and then you go to places like Trailhead, you can start to put two and two together. So I think the fact that you could talk about maybe how a story related to particular functionality that was built, I do think that probably gives you a big leg up. It’s a little bit hard to answer that question fully, because obviously I guess I don’t see necessarily how they react to someone that doesn’t have any of that, but for me in terms of my confidence going into that for sure, I think being able to lean on that BA experience helps.
Ben (10:46.205)
So when did you start to explore flows and how did you feel about flows when you first started looking at the power of them?
Stephen Church (10:56.478)
Yeah, so when I was looking for my first job, I got some advice, heard some advice that it’s good to build an app in your dev org, kind of show what you can do. So I built an app in my dev org and included a demo of it, a link to it in job applications. And so it was an app to track my finances. And so part of that, I built a screen flow where I could enter in expenses and it would sort of deduct from different budgets that I’d also stored in Salesforce. So that was really the first time I dove into Flow because I didn’t really need to get into the weeds of it at all to pass the Admin exam. You just sort of needed to be able to explain how to use flow in comparison to process build a very high level. And really I found it incredibly hard to build that first simple flow. Firstly, it’s really not as intuitive as tools like process builder or workflow rules. They’re quite simple in the sense that if something happens on a record, then you want to take a certain action. But back then we didn’t even have record triggered flows. It was just screen flows. So I was having to learn about things like variables, which other than dabbling on Codeacademy was a completely new concept and definitely new in the context of Salesforce. The first impression was it’s pretty complicated and pretty hard to use. But at the same time, it’s very different than anything I’d seen in Salesforce at that time. So I was certainly intrigued by it. And I think that sort of set me down the path of wanting to learn more about it.
Ben (12:30.854)
So how did you go about that? How did you start to really develop those skills?
Stephen Church (12:35.626)
It’s not the most interesting way I would say, but what I found really useful was just reading the official dry Salesforce help documentation, because it goes into a lot more detail than what was on Trailhead and the aAdmin Trail mix back then. So that was really invaluable. Now a lot of that was spent sort of reading stuff that I really didn’t understand what it meant. So as I was doing that, I was sort of researching online, I came across a lot of great blogs on process automation and flow in particular. So for me, this was really invaluable because it gave me a little bit more context than just saying “hey I’m gonna go build my first flow and really not have the lay of the land at all”. So that was really useful to do that and then the interesting thing is about doing that, as I read more blogs and different use cases for building flow. So then what I could do is some of the things I was reading about, I would go to my Dev org and I would try and build things similar to them. Not necessarily copying the use case exactly, but sort of reading it and sort of inspiring myself to build something similar. And I think this highlights a really important thing for people learning flow. Like advice I often hear is that, you know, the only way to learn flows is go out and build some flows. But I kind of really disagree with that. If you just, if you’re new to Salesforce and you just go try and build a flow without spending any time like absorbing content on the topic, it’s going to be incredibly difficult. It was for me because really you don’t know, you don’t know where to start. So I definitely encourage people from my experience, spend some time absorbing content on flow, reading it, even if it doesn’t make total sense straight away, it’s a good way to get a high-level overview before you start building and it definitely comes in handy then.
Ben (14:40.465)
100%. Yeah. Do you think there’s this perception that flows are scary? Do you think there’s the communication and because they’re more technical, you know, there’s certain elements that you need to understand. Do you think there’s this messaging in the market that people should be a lot more conscious about what they’re doing with flows in comparison to process builder?
Stephen Church (15:04.558)
That’s an interesting question. I mean, for sure there is definitely people that feel it’s scary. And I do think to some extent flow is more powerful in some ways. So if we think about it, like in a flow in theory, you could sort of accidentally update every single record in your org if you configure update records wrong. I mean, I think there’s probably some people who would always find it challenging, right? We’re all sort of wired differently, right? So there may always be some people that will find it harder to grasp. I think for me, like the key thing is you just have to kind of practice and learn from your mistakes. So like the absorbing the content piece, really for me, that’s just important in terms of getting started and having a little context on how to build a flow and get ready with it. But I think really practicing and being creative to come up with use cases and trying different things is really where you learn a lot of the nuances. And obviously certain topics like variables are scary up front. So obviously some reading and understanding on those may be needed.
Ben (17:48.973)
And have you gone back and looked at that app you built and critiqued it?
Stephen Church (17:54.962)
Oh goodness. Yeah, I’m sure I’d be critiquing more than just my flows as well, probably my data modelling and some other stuff too, but I haven’t actually looked at that in a while. That’s interesting. I should probably do that as long as the Dev Org hasn’t expired. I think that might be my action item from this call.
Ben (17:56.221)
Yeah, it’s funny, isn’t it? Because I think as your Salesforce career evolves and the power of the platform becomes more, there’s always things you can look back at and go, “oh, I wish I hadn’t done it that way”, but you don’t know what else is available. Like if you’re thinking back to four years ago when you became an Admin, there’s probably so many things, an actual org that you built could be, you know, someone could still have the link in their email and go and look at something you’ve built a few years back and be listening to this.
Stephen Church (18:40.254)
Right. Yeah, I’ll have to check on that.
Ben (18:46.183)
So you mentioned back then only screen flows were available. So what should people understand about the different types of flows that are available now and when they should be used, I guess?
Stephen Church (18:58.582)
Yeah, so I guess there’s a few different types of flows. So I’ll kind of focus on some of the most common ones. So obviously at a high level with record triggered flows, you’re building automations that run when changes to records occur, but I think one of the most important considerations is within record triggered flows and I think that’s knowing when to use before-save flows versus after-save flows which are the two main types of record triggered flows. So before-save flows are very limited in functionality. All they can do is update the same record that was created or edited. So let’s say you create an account and you want to automate some updates on that same account then a before-save flow can do that record related to it you can’t do that in a before-save flow only an after-save flow can do that. So I think since after-save flows have more functionality I believe there can be a tendency where people just default to using them since they do everything before-save flows do and more. Although that’s all before-save flows can do is update the same record that was created or edited they’re actually a lot more efficient at doing this than after-save flows. I’ll get a little bit technical but since they run before a record has finished saving to a database hence them being called before-save flows this means that when a flow updates them it doesn’t actually go through that process of resaving the record to the database because it’s still in the process of the record initially getting saved. On the other hand with after-save flows they’ve already been saved to the database given the name so if you try to change that again in the flow it has to go through the process of getting resaved and obviously that uses up Salesforce governor limits saving records takes time so I think a really important concept is within record triggered flows definitely try to use before-save flows and don’t be put off by the fact they can’t do much use them when they can do what you’re trying to do. One other concept that I think is quite important and applies to a couple of types of flows is think about how you can use scheduled flows and asynchronous paths for these automations that don’t need to be completed in real time. So scheduled flows are good because you can kind of take care of repetitive work on a schedule. So let’s say you wanted to close all cases that are over two weeks for scheduled flow that runs each night and closes them all out. And asynchronous paths are pretty cool because you can add these to after-save flows. So let’s assume you have an after-save flow and it performs a bunch of actions. What typically happens is when the user is sort of there on their screen and it’s spinning, they’re waiting for all of those actions in the flow to occur. But what you can do is you can put some of these actions on an asynchronous path doesn’t have to wait around and wait for all of these things to finish, only the critical things they need done there and then can finish, and then all this other stuff sort of gets done in near real time. And so the benefit there is obviously it’s a better user experience. You’re not waiting around as long. And secondly, if you have a really complex org and you get in trouble with governor limits, when you have those separate asynchronous paths, they have their own set of governor limits. So you kind of ease the burden on when the initial change is made. So there are a couple of nuances that I think are really important on the types of flows and then obviously another common type is screen flows, so these are completely different from triggered flows and that’s really when you need to kind of build some complicated user interaction and data entry that you can’t really do just on a simple record page.
Ben (22:58.621)
You mentioned governor limits, historically, governor limits have been something that Developers typically reference more in my conversations than an Admin would. So have governor limits now become something that the Admins really need to be across?
Stephen Church (23:44.266)
Yeah, for sure. So like one of the functionalities we have in flow is loops, right? And one of the things you can do with loops is if you have a group of records, you can go through all of those records and like perform a certain action. So if you’re not aware of governor limits, what you could end up doing, let’s say you have a group of child records and then on each of those, what you want to do is create a record on them. So a child record of them. If you’re not aware of governor limits, you could decide to loop all of those records and within your loop, put a create records element. And so obviously what’s happening is each time it goes round, it’s saving a record to the database and that’s a critical governor limit that’s getting used up. So obviously with flow, there’s certain practices you would want to follow where you don’t do that stuff in the loop and do it outside of it. But yeah, to answer your question, because of that type of functionality, you certainly need to be more aware of governor limits for sure.
Ben (24:44.065)
Which actually brings me on nicely to the next question around, you’ve mentioned what you would say would be best practice there, but what does flow best practice mean to you and are there key things people should consider, like the loop example you gave?
Stephen Church (24:59.006)
Yeah, so I guess I sort of view best practices almost on a sliding scale. For me, there are hardline things that we should always do or not do. There’s things that we should almost always do. And then I think there’s guiding principles that we should consider as all of our solutions as we’re building. So starting with the hard line stuff, that’s exactly it with the loop example, right? I view these type of best practices as things that if you don’t follow the best practice, you’re really creating a significant risk of everything blowing up and failing. So yeah, if you put the pink elements in flow, which are all the ones that sort of query or change stuff in the database, if you put those in a loop, the absolute best case scenario is that everything is highly inefficient and slow, and the worst case scenario is that it fails completely. So I view that as sort of a hard line best practice that people need to follow. Sort of a level down from that are things that we should really almost always be doing as they’re likely to make things more efficient. So the example there is what we spoke about before-save flows and after-save flows. So typically if you want to automate an update on the same record that was created or edited, then you should really always do that in a before-save flow. But there can be some sort of edge cases or exceptions where that’s not possible. So a good example is if you want to run a before-save flow on a new record and for some reason you need to use the exact created date stamp on that record, well you can’t do that in a before-save flow because it doesn’t yet exist in the database. So there’s sort of those type of exceptions where you know you may have to deviate from the best practice but generally speaking you should be following that most of the time. And then sort of the final level I mentioned, these guiding principles, these are sort of key concepts that I think you should be thinking about each time you build. So like a good example is trying to make the logic you build reusable, so other flows and other automations can use it. So in flow, you can build what’s called sub flows. So you sort of build a piece of logic and then other flows can use it. So a good example, one of the roles I was working in, I had a screen flow where it was involved in creating a record and before the record was created I needed to show a due date value that was going to be on that record on the screen. But what could also happen later in the business process is that a parent record of this record that got created could change and that could result in the due date needing to change. So I could have built the logic in both the screen flow and the record triggered flow but then the problem is because it uses the same logic, if the business requirements change, I’d have to change it in both places. So in that case, I built in a subflow and then both flows then used it. So these type of best practices are kind of things to consider when you’re building and sort of guiding principles to follow.
Ben (28:08.837)
And is there like a checklist that you follow or like when you’re designing a flow, are you one of these people that will draw it out or, you know, have a formula that, “if I do this and follow this practice and this structure, then I’m not going to go far wrong.”
Stephen Church (28:25.598)
So it’s in my head, so shame on me, I don’t have it wrote down, I probably should. But yeah, for sure, there’s definitely like a list of things that I follow. And if you’re new to Flow, for sure, I’d probably suggest writing a list down. I’ve done it a few times now, so I feel like I have it memorized. But yeah, some of the things I go through in my head is like, first and foremost at a very high level, do I actually truly understand the problem I’m trying to solve here, right? So very often people can ask for something and we jump straight to trying to automate it, but we haven’t actually got to like the root cause of what they’re trying to solve. So obviously doing that and depending on your org, if you have a good BA, they can obviously help with that. I think another question I always ask myself before I start building is, “have I analyzed which type of flow I need to use?” So we sort of spoke about before and after, save flows already, so answering that type of question. Now a really important one nowadays, given some of the improvements to flow over the last couple of years and the new functionality is, “have I decided whether I want to create a new flow or add to an existing one?” So what we can do now is you can set up your flows so you have lots of different record triggered flows that only run when certain conditions are met. But in the past that wasn’t really doable due to the flow functionality we had. So if you’re working on record triggered flows I think it’s always important to ask that question. Don’t just go and build a new flow but see if there’s one you can add to. And I think a good way to make that determination is say “is there the same type of flow I need to build, so like a before or after save flow, and does it have the same or very similar entry conditions to this new requirement I’m working on”. And if it does, in that case, it probably makes sense to add to the existing flow instead of building a new one. And then, yeah, a couple other things is just thinking about like other components you may need, right? So like if you’re building a screen flow that’s saving entries to a record, maybe you need new fields on the object to hold that data that people enter into the screen flow. And then once I’ve sort of gone through all of those questions, what I really do is map out the granular steps. So I think you mentioned the process diagram. Personally, I don’t do the diagrams, but I just like to write out bullet points, essentially.
Ben (31:02.333)
Yeah, awesome. I think that’s super valuable to anyone that’s, you know, trying to get their head around flows now. Next question is around like the future and looking forward, like do you think every admin is going to need to know how to build flow? Or do you think we could see like a bit of a separation in the admin role in the one element might be more business facing and the second element might be more technical and you know, you might have two different types of admins, which we’ve probably got now, but there’s no differentiation in name. But do you think there could be like a Business Admin and an Automation Admin as an example, and people will focus on one end rather than the other?
Stephen Church (31:40.066)
Yeah, that’s an interesting question. And I’m kind of interested to get your take on it as well when I answer it, because I’ve heard this one come up in the community quite a lot. For me, I struggle to see a world where you can be an Admin and not be competent with flow. So I’m not saying that everyone needs to be a flow expert and everyone needs to kind of be able to architect the flows for a complex org. And nor does everyone need to be able to understand every type of flow off the top of their head. There’s so many different types of flows now. But at the minimum, I think all Admins need to be comfortable and competent with building routine automations with flow. And what I sort of define as that are the type of things you would have done at least with process builder and workflow rules. Can you do those with flow? Do you feel confident doing that? I mean, I look at it this way, like every Admin was expected to be able to build those routine automations with different tools so I kind of feel like they should be able to build them with flow. But I guess to your point about splitting it into different roles I’m kind of wondering if this business or user focus person is more along the lines of the BA role which seems to be growing in prominence, where you maybe don’t need to get us in the weeds with tools like flow. But of course being a BA kind of requires its own skills too if you don’t get into the technical weeds you have to do more stakeholder management and stuff. I’m kind of curious what you’ve seen on your side as a recruiter.
Ben (33:14.241)
Yeah, I mean, I think I asked this question because I am finding it more and more difficult to find people that can do both. You know, like we have, like I’ll give you an example. I had a requirement recently and it was for a Salesforce Developer. Like there was a contract requirement and the company were hiring for a Salesforce Developer, but their expectation was that over the next six months that person would write absolutely no Apex. So I said, “well, why do you need a Developer?” And their view was, well, it’s 99% flows and there might be 1% requirement to write Apex, but we’d rather have someone that’s very technically sound that is going to be technically confident with flows and able to meet all of our requirements with flow. And if anything came up on the development side, they could also do that. But that company weren’t hiring for an Admin, they wanted someone that was technical because of the flow element. I’ve got requirements at the moment with an org where they’ve got over a hundred flows. And I’m speaking to candidates about the best practice. And what I’m finding is a lot of the Admins in the market haven’t done much with flow at the moment, which is, there obviously are a lot of people that have, but quite a few haven’t. And I just wonder, is that because they haven’t had the opportunity in their org, but then it goes back to your comment about like you kind of self-taught yourself this stuff, right? You went away and read, you built your own flow in a finance app. So there is still opportunity to do it. And I wonder if it’s just because people aren’t confident in the technical aspects of it, they gravitate more towards the user side. So it’s just interesting to see how that evolves, I think. And then like back to my point earlier about, you know, putting in a picture of a flow into ChatGPT and it pumped out steps for me to add a field to that, that screen flow, you know, that’s really powerful and is going to become more and more powerful. So will people hire someone that can prompt AI and you’ve mentioned to me before about, you know, the, the GPT capabilities that Salesforce will have and how you can just kind of write a text brief and it will build the flow for you. So, yeah, it’s just going to be really interesting to see, I think. But I guess, like to my point about people maybe gravitating towards the things they’re more comfortable with. Like if you, if you look back four years, I guess you would never have thought that you would be on a podcast talking about flows in four years time at that point.
Stephen Church (35:48.766)
No, no, yeah, that’s a good point. And I think it’s kind of interesting on some of the comments you made about a lot of Admins not being comfortable with Flow. Because one thing I’ve noticed since I’ve started talking to more people in the community about it is that I’ve actually came across quite a lot of people who are very early in their Salesforce career who have sort of embraced Flow and seem really confident with it, but at the same time I’ve received messages from people that have been in the ecosystem close to 10 years and don’t feel comfortable with Flow. So it definitely does feel like one of those tools that if you kind of have that more technical tendency, you sort of gravitate towards it, but if you don’t, perhaps it’s something that’s a bit intimidating and scary.
Ben (36:38.089)
Well, this is the thing for me about Salesforce in that you have to rip up that whole, you know, qualifying or assessing people based on years of experience, because like, actually, what’s happening now on the platform is more relevant than what happened 10 years ago, in terms of like, you know, the evolution of the platform and someone that has, I always give this example, right, I’m the Admin for Talent Hub, you know, I’ve been using Salesforce and I’ve been the Admin, to make sure people can see that, for eight years, right? But as I said to you today, I use ChatGPT to tell me how to build the steps of building a flow. And I was petrified of it. Like I’ve never built a flow before, but I’ve been the Admin for eight years. But you’ve been an Admin for four years and you’re on a podcast talking about flows confidently. And I’ve not thrown any questions that you’ve not been able to answer about flows. So it’s not about how long you’ve been doing something. It’s about how technically competent you are with that platform, what you’ve learned in that period of time and what you’re doing day to day. So yeah, I think that needs to change in people’s thinking around like, oh, a Senior Admin is someone with five plus years of experience. And like, it’s really about like, what are they doing today? Like, what challenges are they solving? What problems are they solving in an org? And what are their capabilities? What’s their skill set, not how long have they been doing something. So yeah, you’re right. There’s plenty of people I’ve spoken to that have got lots of experience that aren’t comfortable with flow.
Stephen Church (38:10.93)
Yeah, it sort of comes down to the, you know, a lot of the time the quality of the experience, right? You can be doing something for a long time, but depending on what you’re doing, the quality of the experience may not be as good. But in this case, it’s more like you may still have quality experience in a lot of the fundamental Salesforce stuff that’s still super important, like sharing and security and that type of stuff. But maybe for whatever reason, you just haven’t had a chance to work on flow. Maybe your org’s not prioritizing moving stuff to flow. So it definitely creates an interesting dynamic where people newer in the ecosystem feel confident with it, but perhaps others don’t.
Ben (38:52.369)
Yeah, for sure. So obviously for people listening, I recommend they follow you on LinkedIn because you put some great stuff out. But who do you recommend or what resources are there out there aside from what you’re posting about that could help people get on top of the evolution of flow?
Stephen Church (39:09.534)
Yeah, so there’s one blog I always like to give credit to, because it was super helpful when I was learning. I ended up on it all the time as a blog called Automation Champion. So I think it’s by Rakesh Gupta. That’s a really good blog and that has a ton of use cases and are very detailed. You know, there’s various people on LinkedIn as well who create content. Another good blog is Salesforce Time. Yumi, I think a guy that won FlowFest one time. So obviously he knows what he’s talking about. Andy Utkens, another good person to follow on LinkedIn and produces good content. So they’re like some content creators that I think are good in terms of other resources, like official Salesforce help documentation wise as something called the Record Triggered Architect Guide, which is an incredible resource. It kind of gives you a lot of considerations flows to have on an object, when you should use code or when you should use flow, how you can optimize your flows for performance. It really gets into a lot of technical weeds. If you’re super early in learning flow, it’s probably not the best time to dive into it, but I would highly recommend bookmarking that and reading it as you’re getting more confident and rereading it because it really does get into a lot of detailed performance considerations on flow. That’s one I recommend too.
Ben (40:39.449)
Awesome, and I’ve plugged your LinkedIn profile, but if anyone’s got any questions or wants to reach out, is that the best place to find you?
Stephen Church (40:47.05)
Yeah, yeah, LinkedIn is the place I’m active, so yeah, for sure, reach out. That’d be great.
Ben (40:51.173)
Awesome. Well, thank you so much. I’ve enjoyed it. And yeah, really looking to see what comes down the line in the future with Flow. And, you know, hopefully people are listening to this and wanting to learn more because, yeah, I think, like you said, you can’t see the space without people needing to know it. And I think, yeah, there’s lots of gaps in the market at the moment where people don’t. So it’s really important that people take note.
Stephen Church (41:14.058)
Yeah, for sure, and I think the area that’s going to get a lot of development and love and already has is ScreenFlow, so wait for all that to come.
Ben (41:20.341)
Keep an eye out. Well thanks so much.
Stephen Church (41:22.946)
Thank you so much for having me, it was a pleasure.
Ben (41:24.649)
My pleasure.
You can visit our Salesforce jobs page for up to date opportunities. If you’d like to become involved in the Talent Hub Talk podcast as a guest, we’d love to hear from you.