When Tim Combridge first stumbled across Salesforce Flow on a student records project, the implementation partner gave him one piece of advice: “Don’t touch it.”
These words of advice only made him more curious, and soon after, Tim would start tinkering with early Trailhead modules, following along with tutorials, and discovering how much business value could be delivered with “clicks-not-code”.
What started as a side experiment quickly became a career-defining skill, reshaping how Tim solved problems, how colleagues saw him, and, ultimately, how he contributed to the Salesforce community.
In this article, Tim shares how Flow changed his career and what you can take from his journey to shape your own.
Where Did Tim’s Flow Journey Begin?
Tim’s first interaction with Flow all started with curiosity. To his implementation partner, Flow was a kind of Pandora’s box – powerful, but best left untouched.
“It was back on my first Salesforce project that I first encountered – back then – Cloud Flow Designer and the very early days of Flow,” Tim explained.
“I was a general IT guy helping out the business. We were implementing a new system to help with student management, student records, and that sort of thing. The implementation partner had done some stuff; there were flows running in the background, and I was like, what’s this? Their answer was basically: don’t touch it, there’s a lot of stuff going on.
“There’s a lot that we’ve built; if you play with it, it could break a lot of things. It’s a very powerful tool. Go easy. I’m like, okay, that’s fine.”
The message was clear – this was a powerful tool that could cause problems if handled incorrectly. But the warning only deepened Tim’s interest.
“Towards the end of that role, after go-live and after everything, I decided I’d start learning about this tool.
“I was doing a couple of Trailhead modules, trying to understand what was going on. This was in the earlier days of Trailhead, too, when there wasn’t as much content as there is today. The Salesforce Ben site had a bit going on that massively helped me through my admin journey, and I also found a lot of value from AutomationChampion.com – Rakesh Gupta’s site.
“There were a lot of follow-along, ‘build these flows with me’. It was an easy way to learn the basics, and it blew my mind how much I could do using clicks, not code.”
How Did Flow Change Tim’s Career?
Calling something “career-changing” is no small claim, but for Tim, it couldn’t be more accurate. What began as simply delivering projects soon shifted the entire course of his career, creating real business impact where it mattered most.
“We’re doing this thing that takes us, you know, an hour a day of repetitive tasks,” Tim explained. “I’m going to build a flow and show the CEO and suddenly just save an entire team an hour a day. And it took me half an hour to build.”
Moments like this showed him the potential of Flow to transform not only processes, but also how people saw him in his role. That excitement eventually grew into sharing what he had learned with the wider community, which has become just as important as the building.
“It was a genuine excitement for me… that energy and that obsession I suppose with the Flow tool was picked up by Salesforce Ben, and I started being able to post about it and talk about the tool more.
“Something I’ve really enjoyed across everything I’ve ever done in my life is I love sharing things that I know will benefit other people. So I started talking about how you can learn Flow. Not just, hey, here’s these cool features, but hey, if you’re starting out in the place that I was a couple years ago where I was, there’s this cool tool I know about.
“I then built the course that was on Salesforce Ben Courses, just trying to teach people, like here’s everything you will need to know to master the basics of Salesforce Flow and be able to start seeing value inside your business.”
Looking back, Tim sees Flow as the bridge that took him from doing to teaching, opening up opportunities he may not otherwise have had.
“I started in the technical side and the doing side. I’m still doing a lot of that today. But really, my favorite part about my career is talking about the power that Flow has and helping people to learn it and harness that power for themselves inside of a business.
“So my career would not be anywhere near what it is today or have followed the path that it has today without learning Salesforce Flow and without – quite frankly – being involved with Salesforce Ben and being able to share that knowledge and that passion as well for the tool with other people.”
“I’m a Huge Believer in Flow, But It’s Not the ‘Everything Tool.”
The clicks vs. code – or Flow vs. Apex – debate is one of the most opinionated conversations in the Salesforce ecosystem. Tim is a strong advocate for Flow and its capabilities, but I wanted to know if there were situations where he’d choose one over the other.
For Tim, the decision ultimately comes down to a single factor: complexity.
“The first question is: does the process need data capture or a UI for staff or customers? If so, that points to a screen flow, or sometimes a custom Lightning Web Component. I always look at the level of complexity.
“I’m a huge believer in Flow, but it’s not the ‘everything tool.’ For example, creating a new Lead can be done in Flow, but a Quick Action would be faster. Flow solves more complex problems than Quick Actions, but not everything belongs in Flow.”
Ultimately, the lines get drawn once situations become more complex, and Tim is first to admit there are things Flow simply can’t do compared to Apex or Lightning Web Components (LWC).
“The biggest problem that I sort of come across a lot is the need for Flow to have a map or a key value pair collection type, which it does not, which is very unfortunate… You could kind of loop within a loop inside of a flow, or you could kind of try and construct your own sort of thing with variables, but okay, maybe in this case it’s a little bit easier with Apex.”
“There are things that you can do with Apex that you just can’t do in Flow; for example, there are things you can do with Lightning Web Components that you just can’t do inside of Flow. It’s obviously an easy way to draw the line.”
Despite some of its limitations, Tim explained that Flow will always be his first port of call, saying: “I, out of habit, will go to Flow first for a lot of automation, particularly sort of anything that’s a basic record trigger. If you know if it’s a simple if this then that, great. That’s kind of where, in the very far past, I used to use a workflow rule because that was the model that I followed.”
But understanding when to use it based on how difficult the business process, for Tim, is the most important aspect.
“Sometimes, some of the flows that I’ve seen, some of the flows honestly too that I’ve built over the years, I look at them after the fact and think ‘that would have been so much quicker inside of Apex.”
“Quite often too, I’ll start in a Flow thinking we’ve got the business requirements down pat, and then we’ll go, oh hang on, and also this. And it’s the ‘and also this’ that goes okay. Hang on a second that’s not just an ‘and also this’… should we really be using Flow for what we’re doing here?”
In essence, what makes Flow so fundamental to Tim’s career is actually knowing when and when not to use it. As his first implementation partner detailed, it’s a powerful tool, and using it incorrectly has its consequences – mastering it is in itself a skill that Tim has perfected.
Trial and Error: Lessons Learned from Flow Failures
Like many people who start with Flow, a lot of Tim’s learning began with trial and error. Early on, he challenged himself to see how much he could build inside the tool, going so far as to experiment outside work hours.
These experiments quickly showed how easy it was for Flows to spiral out of control.
“In my early, early days, when I was learning Flow, I challenged myself to do everything I possibly could inside of Flow. I’d build checklists like my to-do list for myself outside of my professional world, but in my personal world, I’d build checklists inside of Flow just to say that I’ve built a checklist inside of Flow, you know, just to get that hands-on experience,” Tim said.
“I remember facing some earlier issues where I’m like, oh yeah, I’m going to build a… and I couldn’t remember what I was doing. It was like a calendar, or an organizer, or something that I was trying to build in the earlier days. It was more of a personal project to see how I do this inside of Flow to try and learn the tool. And I realized just how complex some things were getting.”
Even in professional projects, Tim was facing similar challenges. Flows began to grow more complicated than expected, especially before newer features were on hand to make things easier.
“Now we’ve got things like the transform component, which makes conversion and transformation, and mapping multiple different variables into one or different collections into one. Before we had that, you’d try and do some of this stuff inside of loops, and you’d have a loop within a loop that tries to break out with a decision and then try to bring it back in. It got very complex, very quickly.”
So what did Tim learn from these complexities? A very simple approach that he still echoes to this day: Design before you build.
“We should always design our flows before we go in. But I still – and I always will because it’s who I am – will have a habit of just jumping on the tools, getting excited, going, ‘yeah, that should be a quick and easy flow’, without really documenting it. And then that comes back to bite me. And I’ve been doing this for a long, long time.”
Proper design not only prevents “monster flows,” it also makes maintenance easier later.
“Documenting it, designing it before you even start building is very important… Because sometimes a flow will grow far more complex than you think it will. Designing it out, playing it back to the customer, to the business, the subject matter expert, and saying, ‘Is this all it needs to do? Is this how it should work in terms of functionality?”
Tim’s takeaway is clear: design first, build modularly, and resist the temptation to just dive straight into Flow – or, you could be left with what Tim describes as a “monster flow”.
“Designing gives you the opportunity to build modularly from the outset as well, using subflows instead of just building one big massive monster flow.”
What Needs to Change About Salesforce Flow?
Flow has become as popular and as powerful as ever in the Salesforce ecosystem, but we were keen to understand what Tim thought could still need changing to improve the tool.
According to Tim, governance is still an outstanding issue with Flow. Unlike Apex, Flow can be built directly in production, which is something he sees as a risky practice. For Tim, this difference is a fundamental gap between clicks and code.
“When you write Apex, you need to write it in a sandbox or in an IDE, VS Code, whatever else. And then you need to push it up to production with test classes that unit test your code and make sure that it works, make sure it doesn’t fail, and make sure it doesn’t do anything you shouldn’t do. In Flow, you can build them in production.
“I understand that Flow and workflow rules and process builder and all of that are clicks, not code. They’re not as powerful as Apex. There we go, I said it! Apex is a lot more versatile, it’s a lot more feature-rich, it’s got a lot more power to it. But that doesn’t mean Flow is not powerful in such a way that you should be able to build straight in production.”
To mitigate this, Tim argues that there needs to be stronger guardrails enforced by Salesforce, as well as more versatile testing options.
“I believe Salesforce needs to introduce – optional for historic orgs and enforced for new orgs – requirements so that you can no longer create flows inside of production. There needs to be a new feature inside of automation settings or something which requires your flows to be built inside of a sandbox and pushed up.
“The next thing that we need inside of Flow… There needs to be more versatile testing of Flow like available to us. Something like a test class in Apex, right? So we’ve got those automated testing and record-triggered flows, but that’s kind of where it stops. We need something like that for every flow that goes up.
“If you put out a testing tool, and you could get Einstein to assess your flow and then go, hey, do you want me to help with some of the testing and create some of these automated tests for you? That’s a great way to alleviate that burden of, hey, we’re doing a massive change to the Flow tool in terms of how it works and how you push things up.”
While he understands many may not agree with this line of thinking, all it comes back to is building more sustainable automation practices.
“It’s popular for some and unpopular for others. There’s nothing that I believe that everyone would disagree with, right? But a lot of it is around guardrails and testing.”
Is Flow Still Valuable in the Agentforce Era?
Salesforce has put full focus on the AI and Agentforce development, which has raised questions around whether Flow still has a place in this new era of tech.
However, Tim is adamant that Flow is just as important in the AI era and is in no position to be sunsetted.
“Agentforce is here, right? Everyone’s talking Agentforce – we’ve heard about it nonstop for the last almost year! But Flow is not going anywhere in the Agentforce world.
“I’m not saying that Flow will never be replaced, but what I’m saying is that it’s not going to be, ‘hey, there’s AI now, there is no need to build flows anymore.’ Flow is still a very, very, very relevant tool.”
If anything, Agentforce is likely to rely on flows as part of its automation toolkit, making it as fundamental to the Salesforce experience as ever.
“Think of Flow as a tool. We humans have used Flow as a tool for years now. All we’re doing with Agentforce is going, ‘right Agentforce, I’m a human, here’s the tool that I use. Go bananas and use it yourself.’ We’re handing Agentforce the same tools that we use.
This, in turn, means it’s never too late to start learning Flow, and for those who eventually may want to step into Apex, Flow is the perfect on-ramp to get you started.
“Just because we’re in the AI era or the Agentforce era doesn’t mean it’s too late, or that Flow’s finished – because it is not… It will still be extremely valuable for your career if you pick up Flow today and start learning it.
“In learning Flow and learning it properly… it really helped me when I started to learn Apex. If I hadn’t gone through my Flow learning journey, I wouldn’t have picked up some of those core fundamentals.”
Final Thoughts
Reflecting on his journey, Tim laid out a simple set of lessons to follow to ensure success when building a career with Flow:
- Design before you build: “Documenting it, designing it before you even start building is very, very, very important.”
- Don’t prototype in production: “If I want a Flow, I do not build it in production ever, because that’s just not a good practice to get into.”
- Keep things modular: “Designing gives you the opportunity to build modularly from the outset as well, using subflows instead of just building one big massive monster flow.”
- Use the right tools for production: “Flow is more complex than a quick action and can solve more complex problems… but there are things you can do with Apex or LWCs that you just cannot do inside of Flow.”
- Share your knowledge: “My favorite part of my career is really talking about the power that Flow has and helping people to learn it and harness that power for themselves.”
For Tim, Flow became much more than just a feature. It was the spark that really shifted his career, the tool that instilled confidence in him, and the platform that turned him into a teacher and a mentor.
From saving teams hours with his first flows to shaping thought leadership all across the Salesforce ecosystem, Flow has always been the constant thread.
And with Salesforce’s future being written with AI and Agentforce, the message from Tim is that Flow is still pivotal to building, learning, and growing on the platform.
“Do not let Agentforce and other AI scare you away from learning it. It’s still super valuable.”
If you learn Flow, design smart, and share your knowledge, you may find that – like Tim – it changes your Salesforce career.
