Name: Salesforce Automation Throw Down: Apex vs. Flow
Uploaded: 2025-08-21T16:31:05.366Z
Duration: 1 h 1 min 32 s
Description: Salesforce Automation Throw Down: Apex vs. Flow

Transcript for "Salesforce Automation Throw Down: Apex vs. Flow": Alright. So welcome everybody to the Salesforce automation throwdown, Apex versus Flow. Very, very excited to be here today, to bring you this topic on the Salesforce Ben webinars channel. There we go. Getting my slides going. My name is Peter Chittum. I am your host today, and I'm the director of technical content here at Salesforce, Ben. And we have with us two, imminent experts in, Apex and Flow respectively, Pablo Gonzalez and Tim Combridge. So Tim Combridge is a seasoned Salesforce expert with an session for helping businesses streamline their processes using the vast tools that the Salesforce platform offers. He is primarily known for his work in the Salesforce flow space. And Pablo Gonzalez has been working with Salesforce for fourteen years. He is the author of the recently published clean Apex Code and happysoup.io. Pablo believes in applying a software engineering mindset to all things Salesforce. And as those introductions are going to tell you, Tim is here as our team flow expert, and Pablo is going to be arguing team Apex. So, Pablo, Tim, welcome. Thanks for Thank you. Thank you for having us. Yeah. Thank you. Fantastic. Okay. So before we get started, just a couple of bits of business I'd like to share with all of you. We are Salesforce Ben, of course. Many people know us for our website and our articles, but there's loads of other content that we have. For instance, this webinar here, of course. We also have a newsletter. We do in person events like we've got some that we've now announced for Dreamforce. And, of course, we have our YouTube channel and podcast. Now speaking of some of our other programs, we do have our developer survey going on live. Right now, I'll give everyone about fifteen seconds to scan that QR code and queue up taking the developer survey as soon as the debate is over here today. We would love to have more, more of you taking the survey. And even if you don't really consider yourself a traditional developer, if you build complex complex solutions only using clicks in the Salesforce, we would still consider you a developer and we want to hear from you as well. And finally, this is just my appeal as director of technical content. We cannot do what we do, without you writing for us. So if you haven't got a great idea and you'd like to write an article or, you know, kind of put together a story about some problem that you solve, please go to salesforce ben dot com slash write dash for dash us or follow the instructions there. The bottom of the page, every page has a little link that says write for us. Go there and tell us your idea. We'd love to hear that. Part of how Tim and Pablo got here is because, we're really pleased that they've both honored us with sharing their writing with us in the past. And in fact, that is exactly how this whole thing got started. So about a year ago, Pablo wrote a very thoughtful piece about what the state of Salesforce flow was like in the world of Salesforce, and that was called navigating the challenges of Salesforce flow. Can we turn the ship around? Where flow where sorry. Where Pablo argued for a more engineering like approach, not just to how people use flow, but for Salesforce to bring more such features that allowed us to do that, in the future. A year later, just a mere month ago almost, Tim wrote a rebuttal to that article, navigating the challenges of Salesforce flow, a response to the problem for Gonzales. And when that happened and we were gonna be having flow month this month, this just seemed like the best opportunity in the world to get them both here on the stage to discuss this debate. This debate that goes on all the time in public social media, to have each of them come aboard and kind of argue their points. Now in doing so, we thought we would, kind of kick this off and sort of structure this in a kind of debate. And it's, it's a little bit of, an I'm gonna call it an homage to a podcast, and a debate club in Canada called the monk debates. It's not exactly like that, but we're gonna use one piece of that that is how we are going to score the winner of the art argument basically. So we'll get to that in a moment. The structure is gonna look like this. We will put a proposal to the audience. We're gonna have you then vote on that. So you have to vote what you all in our audience have to vote whether you agree or disagree with the proposal. We'll then have Tim and Pablo each go through and do some opening arguments and some rebuttals. We then have some very specific points that we're gonna go through some discussion on. We'll pause at that time to take some audience questions. Depending on how much time we have at that point, we might, bring up some other points that we sort of put, in the queue in case we need to fill a bit more time. We'll then have some closing arguments, and then we're gonna take a vote. Now the way that it's gonna work is, you know, let's say at the beginning, the people who agree with the proposal are at 40% and the people who disagree are at 60%. If at the end of that, which, you know, whichever side at the end of that has a higher vote has basically quad more votes to their side is going to be the winner. What happens if there's a tie? I guess if there's a tie, there's a tie. You know, this is international rules and, you know, not unlike American sports, we can end with a tie. So there we go. So that is going to be the structure today. Hopefully, you all enjoy this. It is obviously a bit of fun. There's nothing on the line except for a bit of pride and a bit of enjoyment and a bit of thoughtfulness, I think, for all of us to think about these features that impact all of the work that we do. And this is our proposal that states flow cannot survive as an automation tool on Salesforce because of its lack of guardrails, struggle to provide enough information to make it usable by AI, and the lack of documentation and general structure around it. So that is our that's our proposal. So it's time to vote. Our producer, Saima, is going to open up the polls for about a minute, and you all have those are open right now. If you, look at the webinar UI, there is a poll tab with a little red dot above it, and that poll is now live. So please go and put your votes. And I'm gonna actually take my slide down, and that way we can, sign it and put the poll results up, and we can track those as they come in. So I've been wondering this myself, Pablo, Tim. Where do you think people are gonna be at with this proposal to begin with? Pablo, do you have any ideas? Well, first, hi, everyone. I'm not sure. I think that the word survive may be a bit strong here. Like, you know, what what does not survive mean? Like, you can take the example of workflow rules. Like to pull back now, Pablo. You're in this. Let's get it. Yeah. Well, no. Like like, survive is a is a very strong word. Right? Like, I may like, workflow rules and profitability clearly do not survive, and I doubt a flow will ever reach that stage where it really regardless of what I think, I just don't think Salesforce would ever actually make a decision of that magnitude such as just not recommending flow anymore, especially because there's so much emphasis in kind of low code and anyone can build anything. I think it may long term be maybe kind of the second option if you really can't write Apex or if you're struggling with, you know, to use AI to write Apex. Then you may want to know. But I I don't know. Well, I'm interested to see the poll results. Yeah. What about you, Tim? Do you think, where do you think this is gonna be? Look. I don't think survive is a strong word at all. I'm willing to stand by my initial statement, personally. I think, look, the the the the discussion always, always, always, always tends to go to, oh, it's flow versus Apex. Which tool is best? And I think that's that's the problem. Right? Like, when we look at flow versus workflow rule and process builder, I'm really glad you brought that up. Flow versus workflow rule and process builder, these are all types of declarative tools that achieve the same purpose. Right? So the the winner is gonna be the one that does that the best, the most flexible using the, you know, the the most modern tools. Yeah. You look at the way that process builder was built. That was a it was an older, application that, you know, we tried to shrink the screen and all that. It didn't work. It's you you went down the, the list of decisions and, okay. Cool. If we're gonna follow this decision, then we'll do that. Then you can maybe reassess, but it was very sort of two dimensional. Workflow rules even more so. If this, then that, that's it. That's the end of workflow rule. Right? When you look at Right. Yeah. But when you look at flow, flow is a lot more and as we're seeing today, you know, it's a lot more, it is a little more structured today where you got the auto layout flows. That's for sure. But, man, some of the flows you can see back earlier on before was sort of auto auto, layout more free form. They'd just be everywhere. It'd be, you know, instead of just going up and down decision trees and all that, you'd be like, the whole canvas would be your playground, which is not necessarily a good thing. Right? Alright. So I'm gonna ring this in because we're already starting to debate. I was Oh, we're not supposed to be. My bad. My bad. Not not not we're not debating yet. I was really more just like, what do you think you know, how do you think this is gonna gonna score? Because it I agree. This is a very strong statement to say, like, survive. But remember, the winner doesn't have to win all the votes. They just have to pull people a bit more onto their side. Right? That's all that it's needed here. So if one of you two can gain one or two more votes, remember, you've won. Tell you what. So, the three of us, I think, have to step down from the stage and, Saima is going to share the results. So, Tim, Pablo, if you'd, just pop off the stage for a moment, we'll get those results up there and then we'll Alright. So we ended up with agree at 27.2%, and that was 21 votes. And disagree, was 56 votes, which is 72 sorry. 27.27. And then we have 72.73. I just wanna make sure I've jotted those down, and that was 56 votes. Okay. So that's good. Basically, if one of you can claw a few more votes over to your side, boom, we've won. So with that, and that was so it was my fault that we didn't get the polls up there. I was still sharing my screen. But, let's go ahead and go back into screen sharing. We'll get the there we go. Alright. There we go. So, we already voted. Let's go to opening statements and we agreed for Pablo to start. We kinda did a little bit, but, Pablo, if you want to, share a bit more on this and then we can, proceed. Yeah. Alright. So how how this started? Right. It's about a year ago, I wrote an article, for Salesforce, Ben. For some reason, I about a year ago, I feel that the debate of Flow versus Apex was very much alive in the, like, on LinkedIn and Reddit and stuff like that. And there were people posting pictures of their huge enormous, flows, and and there was a lot of debate. And that's not the case anymore, I think, because AI has kind of taken over the conversation. But at the time, AI was still kind of not what it is today. But there was a lot of debate, and and most of it came from from sales with developers kind of criticizing, you know, the lack of guardrails, with flow. And so one of the things that I wrote in the article, which is kinda my main statement here is that and I will probably have to read it out loud, is that the best thing, about Flow is that almost anyone can create a complex business process with a simple drag and drop UI. And the worst thing about flow is that almost anyone can create a simple or complex business process with a simple drag and drop UI. And so the thing is that flow has become so powerful, especially the the record trigger flows. They have, you know, loops and rollbacks and transactions and a bunch of different things. That is, like, almost anyone can create a very, very complex process without really having to know a lot about software design. And I personally at the time, and I still feel that that's that's kind of a recipe for a lot of technical depth because it's very easy to then just create something that just works but doesn't really scale. And so that was kinda my main main argument at the time that the lack of guard rails, the lack of testing, the lack of software design thinking basically enables flow to be a kind of, again, a recipe for technical depth that just become a lot more common. And the thing is, like, if you think of Salesforce orgs in the past years, people used to think of technical depth as mainly two things, Apex and data model. Right? Maybe a bunch of convoluted fields or unused objects, unused fields, and then a lot of messy Apex code. But now Flow is actually kind of now this new thing that can actually become a huge pain point and a huge part of technical debt, and that wasn't the case before. And one of the things that I argued at the time is that why so many developers were arguing against Flow, and I have no evidence for this, is that before Flow, you know, only developers could create a very complex logic. It was kind of the thing that, okay, if you want really complex logic in Salesforce, they need a developer. And so we kind of had that power. Right? And now it's gonna be taken away from us because now just anyone can write a business process, which is drag and drop. And so I don't care about that, but I I do feel that some people may feel protective of that that, well, now almost anyone can be a developer. So what's the difference between code and a drag and drop UI if the outcome is the same? The fact that you were able to fulfill a complex process, for your customers. There is no difference for the end user. And so it may make some developers feel that whatever power they had is just kind of not there anymore because almost anyone can do it now. Anyway, that was my argument at the time. And my argument today is that now with the rise of AI and how good AI is at writing code, if you know what you're doing, I'm not sure what's the point of flow anymore, at least for record trigger flows. I I think for UI flows, that that's a different story, and I want to clarify that for UI flows, I I I think that's actually a great use case because UI development is really hard. But for pure business logic, just back end automation, I do argue that Salesforce could have Salesforce could create a flow builder with AI, which is kind of the same thing that you've seen in flow. But behind the scenes, it uses AI to generate Apex for you. And so, basically, you're just writing Apex through a flow like UI, but that there's no point of flow anymore. And so that's kind of my main argument now that if AI had appeared before Flow did, I'm sure Salesforce wouldn't have created Flow. They would have done something differently. They would have created some platform for by coding or, you know, creating Apex easily. But now the AI is here, and to me, drag and drop UIs for a back end business process feels out of place. That's my argument. Alright. So moving to Tim. Opening statement. Wonderful. Alright. Look. It's no secret that I am a massive fan of Salesforce Salesforce flow. You know? This is this is actually my wall behind me. This is not a virtual background. So I when I first came onto the scene in Salesforce many, many, many years ago, as an admin and starting out, I had Cloudflow Designer, obviously, which has come a long way since then. I I really fell in love with the idea of being able to give non coders the same ability to create value for your business. You know? To me, it doesn't matter what tool you use. If you're able to be empowered to, to automate some of those complex business processes using declarative tools as opposed to code based tools. Really. You know what I mean? We're all we're all fighting for the same cause. Right? We're all you know, not every Avenger has the same superpower. They're all different, and they all create a big team. This is the same thing in my opinion. We're all fighting the evil, you know, powers of of of slow business, ultimately, whether that's through Flow, Apex, or another tool. Yeah. I need to clarify as well. I'm not saying that Flow should be the everything tool. I'm really not. I'm seeing a lot of comments on the side that are agreeing with me as well. I don't think Flow should be the everything tool. But what I am doing here is I'm sticking my hand up to defend the idea that FlowShip is going in the wrong direction. I really don't believe that. My personal belief is the Flow is here to stay, at least for now, and it's it's a tool that Salesforce invests in heavily for a reason. That's my opening statement. I already have some rebuttal too, Peter, if I'm allowed or my I should hold back. Alright? Yeah. Hold hold on to that because we'll have rebuttal time as well. So Awesome. Beautiful. Which That's where I see it. Excellent. Alright. So that does bring us to rebuttals. So, Pablo, sort of your opportunity to having listened to Tim's opening statement to make, any rebuttals that you'd like to. Yeah. So I I do think sometimes that flow may be going in the wrong direction, and I need to clarify again that I actually think that flows are great for UI stuff. Like, without a doubt, if you just need users to both kind of literally follow a flow, right, of do this and that and then whatever in a UI, Lightning Web Components is an oracle for that, and flows are great for that. And I've used flows a 100 times for that, and I think Salesforce should have kept it at that. But it's it's a visual kind of UI tool for guiding users through a business process. But as they have become, you know, kind of record trigger automation and schedule and all that, They're almost getting on par with Apex in terms of concepts. Right? Now you have as I said, you have schedules. You have, transaction control. Now you have the bug in. But the thing is it doesn't have the same flexibility as Apex. So I actually don't understand who's the target audience for record trigger flows when they become so complex. Now, obviously, I'm not saying that we should have kept something like workflows or process builders because that also wasn't enough. But I think there's there should be a cap on how much flows can do on the back end. So it's maybe simple automations to the same record or maybe related records. But I see the PMs of Salesforce releasing all these features that are kind of making flow very similar to Apex in, again, in its concepts. But the thing is that people using Flow don't necessarily have the same mindset of a developer, and that's what I critique. I'm just saying that's that's kind of reality. They're not building it for developers. They're not building Flow so that someone that knows Apex stop writing Apex. They're doing it so that somebody who doesn't know Apex can, create complex business processes. But if you give the same tools without the knowledge, then it's a recipe for, again, disaster, for technical debt, for very high complexity. So I do think it's going in the wrong direction because it's it's like they're kind of making it as close to Apex as possible without considering who the target audience for that is. And that that the people that they're building it for may not actually have the same level of software design thinking that a developer would have that would allow them to use those tools correctly. So if anything, I think that to use if if if Flow is not gonna go anywhere and Salesforce is gonna keep pushing and pushing and making it more like Apex, there should be an effort from Salesforce or from my community at least to make sure that local users have a certain baseline knowledge on software design. Thank you. That's my argument against Damon. Very good. Tim, would you like to rebut Pablo's opening statement? Well, the that was my rebuttal to Tim. Tim said that that is not going in the wrong direction. I think it is going in the wrong direction. Yeah. Now he gets to rebut yours as well. So yes. So I can get your hand cramp for writing down my rebuttal. So alright. So look, against your your opening statements, I wanted to call something out. Right? Recently, and somebody's made a reference to it in the in the comments already. You were talking about sales Salesforce flow not sort of surviving in the world of AI. Right? Whereas recently on LinkedIn, you yourself suggested that flows could be built using Vico. So how can that be done given that that Flow is a is a is a visual based tool alone? Well, as you would know, and some may not, this is more suited for for for a bit of context. Flow is code behind the scenes. Okay? All we're doing with Flow and the reason that Flow is so powerful at what and and I think it really deserves a spot where it has a spot and potentially more in the future, is that it makes code more accessible. So I I, many, many, many years ago, actually, it was around the same time I was starting out with Salesforce. I went to a, a science and and technology, like, what's what's the term I'm looking for? It's it's 1AM my time. I apologize. My brain's a little bit slow on on the right words. But it was like a a a a fair, I suppose, is the or or, you know, whatever event, for kids. And what shocked me what genuinely shocked me was I was watching kids who were, like, holding an iPad like this because it was so big in their hands because they were so small, coding, not using code, but using blocks to code. I think it was Scratch was the application that they were using. Right? That so what what we're doing there is we're empowering people who, haven't learned full syntax to be able to code. At its core, this is kind of what I believe do I a 100% agree with? Sorry. I just need to go off track real quick, Drew, that the, until Flow has a map concept like Apex, it will always be limited. Salesforce, if you're listening, maps. And then Don't give don't give them ideas. Don't don't give them ideas. Hey. Can we delete that comment? Look. I have seen as well. Salesforce did make a comment recently. I'll see if I can find the idea when when you're speaking next. Maps or key value pairs to a degree are coming very, very soon, which I am excited for. Anyway, sorry. Back to that. So what what flow does is it basically allows you to code without writing the code. Okay? So in this day and age as well in the world of AI, coding without code is something you can now do with Apex as well. So, hey. Potentially, maybe Flow is, losing its its its place in the market, but I'll I'll come back to that that in a second. Right? What I would do wanna call out though was behind the scenes, and Flow is just a big XML document that you don't write yourself because that was suck. But Flow Builder gives you a visual interface that allows you to construct XML code using clicks, not code. Flow killed workflow rules and process building because it achieved the same goal. This is what I was saying before. What was that goal? To be able to automate complex business processes using clicks, not code. That's not what Apex does. I this is why I don't really think it's a, you know, should Apex replace Flow? Should Flow replace Apex? Definitely. Not all my goodness. Imagine that. Well, potentially down the track, and I know we've got a talking point about this potentially later. There is something like an Omni Studio, right, which at its core, maybe a little bit differently, and and and those of you with Omni Studio know what I'm kinda talking about here. It's not really just clicks versus code. It's kinda clicks and code and whatever else has been pushed together is Omni Studio versus flow. Maybe that's an argument. I don't think it's flow versus Apex because they serve two different goals. Yes. Both involve complex automated complex processes. One is with clicks, one is with code. That's that's ultimately the point of these two tools. One thing I will concede is that Flow does lack guardrails. I 100% agree with this. I'm on board. I'm with you there, but I don't think the solution is, okay, if fluid doesn't have guardrails then flows on its way out, it's not gonna survive at all. Because, you know, we we what we should, what we should be pushing for instead is not the depth of flow, but for Salesforce to empower businesses to put their own guardrails in place. So what we've seen in the past is Salesforce will make a change. They're not gonna force that change on everybody who's always been using Salesforce. They'll make it optional that you can apply in the future. Lightning, for example. When Lightning rolled out, they're not like, hey. Lightning's here. Good luck, and put it in everyone's org. They made it available so that you as an organization could assess what Lightning looked like in your org, where you had issues with your with your custom stuff, and then apply it over the top. New environments with Lightning first. This is what we've seen. What I believe Salesforce needs to do is put some guardrails in place and say, right. Apex has a 75% code coverage. We need the same sort of thing for Flow. So Flow has automated testing now to a degree. Again, that needs to sort of be expanded upon, but that's okay. That's the latent Flow rules, 100%. Yeah. So so, test exists inside the flow now that you can automate. It's not just, you know, I'm gonna go through and test the flow myself. You can now put in data and automate that testing of flows. That needs to be optionally for existing flow users and enabled by default in new Salesforce orgs made required. So you cannot you need what I believe Salesforce needs to do here is add a toggle saying that you can't create flows inside of prod because you can't create code inside of prod. So why should you be able to create code using a visual builder, which is what Flow is, inside of prod? I think having that option for the businesses is a good idea. Salesforce has always operated through a shared responsibility model. Right? So I think what they should do here is rather than say, okay. Cool. We're gonna change it so that in, you know, January 2027, after everybody's had a wonderful Christmas Christmas break, you're gonna come back and you're not gonna be able to build flows in prod anymore. Good luck. All your flows that are in prod are gonna die because I haven't been tested. Terrible approach. They need to hand it back to the, businesses. What is the point of flow in an AI world? Pablo, unlike you where I quoted you actually where you said I don't really have evidence. I do have evidence. There is my evidence I've just posted in the chat. If it's gonna let me. There we go. Yep. So Salesforce, this is this is an article I wrote about how Salesforce flow is empowering agents in an era of AI. What I haven't written there is how flow is being replaced by agents. Okay? When you think about Salesforce flow beyond just screen flows and UI, that makes a lot of sense. I agree 100% of what you said there. When you think about flows, so auto launch, record trigger, all that sort of thing, these are tools that we humans use. Flows don't replace humans. Agents don't replace humans. But flows sorry. Agents and humans together will leverage flows to take action and to streamline data. That ultimately is, is where flow sits in the AI world. You said in the AI I I wanna I wanna wrap up something here thirty seconds ago or so so so we can move on to some of the other topics. I'm gonna skip a few. Like I said, hand cramp. There was quite a bit to rebut there. Pablo, you mentioned you yourself there's one more point I'll make. Pablo, you mentioned you yourself use Flows. You admitted as well that Flow is a very, very powerful tool and is becoming on par with Apex. Personally, I I, as a as a predominantly sort of flow first flow first person, I don't believe that. I I actually believe Apex is far more powerful on that front than Flow is. There's no denying that. As, Vu mentioned before, there's no for example, a basic, a variable structure of a key value pair doesn't truly exist natively out of the box with Flow. That's been a massive pain point. So there's, like, there's no equivalent for a map, collection type. That's something that's been a massive pain point for for Flow Builders for a very, very long time. You did also say something, about debugging also becoming very, very more much more powerful inside of Flow. The tool as a whole is becoming very, very more much more powerful. You said people who build Flow don't have the developer mindset when they build sorry. People who build Flow don't have the same mindset that a developer does. Okay? I don't think the problem here is the people who build Flow. Because as you've also mentioned with five coding, anyone can write Apex. And using AI, if you're not savvy to what what a what Apex is, you can write some terrible code. Just like if you're not savvy with how you should be building Flow, you can build some terrible Flows. I think the guardrails that Apex has in place make that a little bit safer, I guess. So if Salesforce would have put optional guardrails in place for flow as well, you'd have the same sort of outcome. I think education is important. It needs to come both from Salesforce and from people like you and me. You've written a lot of great stuff to help people learn how you should be thinking. In fact, you've done a lot more in that space than I am, which is really, really, you know, incredible stuff. Highly recommend that that does work. I'll shut up now. I can see that. Let's move on. Very lively discussion and really appreciate all of the comments that are coming from the audience as well. The discussion, I think, is, really, yeah, really engaging. So one of the themes that both of you brought up that I think would be good to dig a bit deeper into is governance. Can flow achieve parity with testing, debugging, static analysis, etcetera? And I think some of you know, both of you have also alluded to what that has you know, what that could mean. So I think this is an opportunity to go a little deeper into that topic of how do you make sure that the flow that gets into production, is going to scale, is, you know, the best structure possible, and is going to, you know, meet the goals not just functionally, but of a well functioning, enterprise software. I think Pablo will let you, let me let me start again. Do you wanna do you wanna talk about about this a little bit? Yeah. I I can also use it to address some of, Tim's points. So when I said earlier that flow is reaching party with Apex, I well, I recognize that's what I said. Obviously, that's not true. What I meant is that the features that they are building, you can tell that there's a kind of a pattern that they're bringing more developer like concepts to flow. Right? Like, now you have the default kind of exception stuff. You have, rollbacks, and you have scheduled stuff. Now you have testing. Now you have comparison. Right? They recently released, being able to compare, two flow versions, which was always a pinpoint. So, obviously, flow is not the same as Apex in in terms of features. Otherwise, this debate wouldn't make sense. What I meant is that I can I feel that that's Salesforce's intention, that all the features they're shipping is trying to get, flow to be almost on par with Apex at least conceptually? Right? That if you can do rollbacks in Apex, you can also do them in Flow. If you have Apex and coverage in apex, then you have the same flow. And if you have static core analysis in apex, then you have the same in flow. That's kind of what I meant that I can at least, think that's Salesforce's intention. The thing is that so can Flow achieve parity with testing, debugging, and static analysis? I don't think so. At least for testing, probably, But even testing for Salesforce is for Apex is really hard, and I have a whole chapter dedicated to why that's super hard mainly because all the tests that we write are integration tests. And in Salesforce, everything is coupled to database. So if you have a flow that inserts an account and you test that, you're actually testing the entire order of execution. You're not just testing that flow, and the same is true with Apex. And so testing in general in in Salesforce automation is really hard because of how all automations are coupled to database transactions. So So let me push you a little bit on that. You know, so if if, for example, you could, let's say, isolate one branch of a flow, you know, let's say mock the the input values or the the state of the flow up until that point and then just execute, you know, that one part of the flow, you know, in a sense, you know, enacting something very close to a, a unit test. I mean, would you welcome that feature? I would welcome it, but then I argue, why not just do it in Apex? Because that's the thing. It's like you keep introducing developer concepts to a tool that is not a programming language. Well, it is a programming very high level of abstraction. Okay. Right. Language per se. And so that's kind of my argument that I I don't understand who the audience for that is. Now I saw a comment that was really interesting, on the chat. Somebody said that they they have experience with different programming languages, and they don't wanna learn Apex or they don't know Apex. And so using Flow allows them to think about programming without knowing the specifics of Apex. And I I had never heard that argument, and I think that's a very interesting argument that it's actually pretty good. I noted that one too, actually. Yeah. No. That was very interesting. And and the thing kind of you can say the same about byte coding. It's kind of the same. Like, I can code in Python now even though I've never written Python because AI can do it for me. But, anyway, the point is, if you're gonna bring those developer like concepts, then I I argue then why not just do it in Apex? Because I don't know that, aside from the person who made that argument, I don't know that the general population of flow users would even understand what the the concept of of mocking data or having kind of, you know, breaking down the flow into smaller chunks that you can unit test. And I I'm not trying to say that the people that use flow don't know any of these things and then and they cannot learn. I just I feel like there's a disconnect between Salesforce saying, hey. This tool is for local users, and anyone can do it. But, hey. Here's all these developer like concepts that to truly make sense of them, you need to understand software design. There's no way around it. So it's it's so to kinda sum that up, like, you really you're concerned about the dissonance between the message and the marketing and the, you know, the the the sale that come goes on from Salesforce of, you know, this is you know, you don't need to be a developer to make x Apex work, and yet Flow is becoming more and more a tool that really needs a develop not just a developer mindset, but a developer, like, skill level almost, even though it is drag and drop. Exactly. That and and that's and so my argument that is that, okay, if you need to learn software design thinking anyway, then Apex can provide way more flexibility and scalability than flows. Now I totally Okay. Understand. Well, I wanna give Tim a chance now because we're move you know, so I I wanna keep it moving and Right. Right. Yeah. So so let's give Tim a chance to talk about, you know, achieving govern parity with testing, debugging, governance. What are your thoughts, Tim? Awesome. Look, I I had a a couple notes. I did just wanna mention I quoted it in the chat. There was something Pablo said, that I a 100% agree with that. I wanna rebut it all. This is not a rebuttal. The quote was, I recognize that's what I said, but that's not true. I agree. Just my friend. Alright. So Yeah. When it comes to governance. Alright. We're having we're having fun. When it comes to governance, can Flow achieve parity with testing, debugging, static analysis, etcetera? So, look, I I mentioned this before. This is a weakness. Flow I'm not gonna try and tell you Flow as the perfect tool. I think, definitely, there are some weaknesses that Flow have that, Salesforce could, you know and and we are seeing shifts, you know, in terms of making, changes towards a more, we'll call it governance friendly flow. Okay? Testing did not used to exist. We didn't used to have flow testing at all. If you look at what flow was back in the the Cloudflow designer days to what it is today, there's a lot more in place that's designed that's designed to help you make better flows. There's the tips section down the bottom going, hey. You know, here's a couple of things you could be doing differently. I suspect in the era of AI, we're gonna see that really take over. And, you know, you'll you'll start doing all sorts of things that that flow will go, hey. Hang on. Why doesn't it be done why can't you do it this way? Because it's got a lot more context. You know, we we well, I think a point of discussion that I that I hear a lot is that, you know, it's it's harder to work with actually, I'm gonna not talk about AI just yet. We'll talk about AI later. Catching myself when I'm coming back to it. I think what we need to do in terms of framing the flow versus Apex debate and I mentioned this before. This is an argument that I've got throughout. It's not Flow versus Apex. Right? Again, we're all we're they're just two tools that we use to try and achieve the same goal. Pablo, something that you you were saying as well, you know, there is time to use Flow. The the one of the arguments that you were saying was, well, why not just use Apex? Well, you you know, if you can do it in Flow and you are doing it in Apex equally, why not just do it in Flow? Right? I think I think something that's this is ongoing a little bit off my my initial script, and it was kinda just an idea I had. I'm wondering if the issue, Pablo, that you've got is that when flow when you create a flow, it creates a flow. What if this is a hypothetical thing and totally off my original, plan. What if Salesforce introduced a tool using AI where you could have an option when you build a flow to build a, you know, Flows Plus, let's call it, where you can drag and drop elements onto a canvas that do things similar to what Apex does today, like you said. And when you save it, it saves in Apex, not in XML. That's that's something I I had an idea. I thought, hey. That might be interesting, and that might sort of solve some of the problems that that I know. That that Salesforce would have failed that if AI had come before Flow. I'm That's it. Yeah. If somehow AI had arrived before Flow, they would have failed that for sure. And what's to say too that that as they sort of evolve in in the in the Flow era that that won't change? You know, we're already seeing a lot of change to Flow. We could see that brand new, you know, Flows Plus or whatever tool that You know, exactly. Yeah. We'll see as a context. Tim, it's or Peter, if I'm allowed, I wanna just repeat something very quickly. It's that you said why not do it in flow? And and one of the things that's I'm happy that is actually in this slide is debugging. So debugging is not just like, oh, I could see what the the value of this variable is at runtime. That's one thing. But refactoring, being able to read from top to bottom the entire business logic of an Apex class, if it's well written if it's hardly horribly written, then you have no no hold. But if it's well written like in this book, I can't see it because of that background. There you go. If you have clean code, I find it a lot easier to read from top to bottom a set of methods that I can understand. Okay. So with this, this, this, and that. And if I need to change something, I can do a simple control f and final replace, change a few things, maybe refactor, use a bit of AI to say, hey. Can we refactor this method and split it into two different things because it's a bit too long? I I have all these tools for understanding the logic with AI editors like Cursor or GitHub Copilot Mhmm. We factor in tools that are on the IDE itself and just kind of my own body of knowledge to understand and parse that knowledge that is embedded in in the flow in the Apex code. When I see a flow that it that's that I have to scroll up and down or zoom out five times to be able to see the whole thing, there's no way for me to understand what the hell is going on. And and that's, to me, that's the biggest problem that, okay, it's very easy to write, but then as it starts going and growing, then it becomes a a real, maintenance nightmare. And so that's my argument. Why not write it in flow? It's because it's just a quick dopamine hit. But six months later, if it grows and grows, it's gonna be a a very painful experience. So that's really interesting. Tim, if you wanna take a minute and then we're getting you know, so we're at about quarter you know, the it's about, well, 08:45 my time in here in the West Coast. I wanna get it to to to the AI topic. So Mhmm. Yeah. Look. I I I wanna come back to really, really quickly, give me, like, thirty seconds here. The key statement was the flow count survive as an automation tool on Salesforce because it's like a guardrails blah blah blah blah. I'm not denying at all that, you know, you can do a finder replace in Apex that you can't do with Flow. It's actually a really cool idea for again, if we're using Flow in the AI world, why couldn't Salesforce enable something like that? Hey. I wanna find all the instances where I've used this value, this variable, and I wanna replace it with something else inside of a loop and blah blah blah blah blah. Why not? That's a really, really good idea as a as a find, replace, you know, that sort of thing. When you're talking about, you know, it's nice and easy to look at a a list of, Apex methods and and just be able to see top to bottom of your code. Salesforce flow done right is the same because you can use subplots. Now Apex done wrong is where you've got a trigger and you've got everything inside of the trigger rather than a trigger that calls method. Absolutely. Right? So it I think it's it's I wouldn't attack the tool so much like it flow or and I'm equally I'm not trying to attack Apex. I think what it is is we're all on a journey of learning, you know, to get into that development mindset as you call it. Something that's coming up in the chat. And like I said, I 100% agree with you. You're a genius. You're brilliant. Somebody said, you know, I can't compete with a genius. I don't have the the, you know, the the mega mind that that Pablo has and all that. I'm I'm I'm certainly under you in that perspective too. You're you're you're absolutely brilliant when it comes to, you know, understanding the way that things should be. Where was I going with that? I think I was just trying to buddy you up a little bit. I can't do it. I think I think you can stop it. That that was a pretty good argument. Yeah. There we go. Tell over, guys. It's end end there. But do you know what, Pablo, what that means? Is if if I gave you an org where there was no Apex and I only gave you Flow Builder, I know that because of your mind and what you've learned, you would build good flows. So it's not a problem with flow. It's a problem that we are we are all learning. We're all on a journey, and we need to learn. And we as you and I, as influencers, we need to share these best practices. We need to help educate. Salesforce equally should should put in place some optional guardrails, like I said, where, you know, new orgs, that's been up from, you know, 01/01/2026, should not be able to build flows in prod, you know, and we should require testing at a certain level before they can be deployed into prod, similar to Apex. Obviously, not enforced for all, orgs that have existed in the past, but something that should be optionally enabled once you've had a chance to update your flows and add testing similar to how, you know, Lightning rolled out, for example. I'll wrap up there because I'm conscious we got a lot to go through. Yeah. So thank you both. Those are really, really good comments, and I think some of the comments in the the, the discussion have also been very, entertaining, but, like, also really thoughtful. I wish we could talk more about that, but I do want to get to this topic here. What is the impact of AI on both Apex and Flow. And, this time, Pablo, you went first on the last one. Tim, I'm gonna give you a chance, to kind of, you know, stake a case here on on this one. Is it is it because I keep injecting root ball where I shouldn't? I'm I'm Oh, it's it's going both ways. It's all good. That's all good. It's all good. Friendly fight. Friendly fight. But the the impact of AI and I think we've kind of injected it into earlier conversations just because that's the kind of world we live in today. It's impossible to ignore AI. Right? Even if, you know, we've done planning for this call. We knew AI was coming. It's still impossible to ignore it in in, you know, talking about governance, talking about feature parity, and all that sort of thing. So I think AI is impossible to ignore if you're still, oh, AI is everywhere. You know, I know Salesforce talks about agent force a lot. We're kind of all a little bit, you know, agent force and AI exhausted a little bit, so to speak. It is still important. Right? There's no denying that. It is still a growing, extremely, extremely powerful, you know, piece of our lives, including in the, the process automation debate. So a Agent Force leverages Flow, and I posted a link in the chat before, about Flow being sorry. Flow empowering agents in the world of AI. So the way I look at Flow, it's not, hey. Flow is killing off, Apex or it's not Apex killing off Flow or whatever. Like I said, they got two different they achieve similar goals, but are are tools for different people. But both can be used to empower human beings. Right? When we when we, as human beings, do our work, flow benefits us. Whether it's record trigger flow, whether it's screen flow, whatever it is, it benefits us and it helps us as human beings make our lives easier. Same with agents. Right? Agents only have as much power to do things as you give them. And, you know, if I if I go in, you know, in in the future in, like, you know, two years' time or whatever when we got actual physical AI robots and all that, I say, go build me a table. It's gonna be like with what? I don't have any tools. You know what I mean? I give it a hammer, and suddenly it can hammer. That's brilliant. I give it a saw, suddenly it can soar. Right? Agent Force, we are just giving it tools. Whether that is through Apex, whether that is through Flow, whether that's through another tool, all it is is we're giving agents a tool. We're not replacing AI I'm sorry. We're not replacing Flow or Apex by using Agent Force, for example. I'm using Agent Force as like the key big AI fancy tool that Salesforce has at the moment. So it's not being replaced. We are using our existing tools that we as humans use, and we're going, hey. Robots, enjoy these. These are great. Flow and Apex both are fantastic. I mentioned, well, Flow, just like Apex, is a tool that is as good as how you leverage it. Okay? So like we talked about before, you know, you were saying it's great to look up and down a a a piece of Apex, whether that's trigger or or class or whatever, and see a list of clean methods, you know, you can do, find, replace. Equally so, poorly written Apex, as, you know, an author of some poorly written Apex because I'm a little more of a declarative, you know, automation person myself, All the way with Apex is terrible to to work through, to to work on, to follow-up. So I apologize to everybody who's following my some of my Apex in the early days. You know, and it's the same with Flow. You know? Some of my earlier Flow I've got I love keeping old developer orgs because, man, some of the stuff that I go back and look at number one, proud of our Firehub in in the decade or so that I've been working with Flutter. But I can see okay. Cool. As somebody who didn't understand some of those concepts at the beginning, I can see how I got there. I can see the problem. So I think in the world of AI, we could see tool we could this is all, you know, safe harbor. Not even this is an idea that, you know, idea, not Salesforce looking at it. But you could see a world where AI is injected deeper into the flow builder where people will build a flow and they'll go, okay. Let's put in a loop and let's put in an update, and then the AI go, hang on a second. Here's a better way you could do it. So instead of just pointing out that's a pink element inside of a loop, which is bad, it could go, hey. Do you want me to refactor it for you? So instead of a find and replace or whatever, the AI can read your flow because it's just this XML behind the scenes, and it can recognize that, hey. This is not great. And it can take action on your flow. Just like today, you can have AI, you know, by coding, create your code, whether it's Apex or another language. That's where I'll end my initial settings of AI. Yeah. Sounds good. And we are just gonna have about time for you to talk about your thoughts on this, and we're need to vote again soon. So it's almost five minutes to the end of the hour. Pablo, any thoughts on this? Just very few just because we're running out of time. I agree that if we had kind of an AI embedded in the flow builder, that would be that would be pretty good, especially if that AI can guide people to think more about, again, design and boundaries and where responsibilities end and others start. Like, right now, my bias code in flow is I use cursor, and I use it a lot. And I do write code, but I I also let cursor write a lot of code for me, and then I just kinda review it. And if I see something that that is nonsense to me, then I I fix it myself or I have a discussion with it and try to work through that. And so I I've told people, like, you know, like, I'm not ashamed to say that I use AI coding a lot because I wrote a book on Apex code, and I've been writing code for, like, ten years. So I deserve a break. You know? Like, I've I've never loved coding. Like, to me, coding in and, again, that may sound surprising given that I spend so much time talking about it, but it's always been a means to an end. And the end is value customer value. Right? Can you deliver value to your customers? That's it. And so you may have perfectly clean Apex that satisfies the wrong requirement. And so then what's the point? Right? And so right now, I'm kind of enjoying this, kind of, by coding era because I can just throw a bunch of code and just iterate super quickly. And if I realize I'm solving the wrong requirement, then, okay, I throw it away. And I did not spend all this time writing a perfectly clean code for the wrong requirement. I don't think the same is true with flow today. Like, you you you could open cursor and open the flow XML, but you wouldn't get that feedback immediately because the flow is actually in Salesforce. And so the visual feedback would you have to go back to Salesforce and see kind of what cursor created. And so the feedback loop is just very awkward. So if but if Salesforce created like an AI agent built into the flow UI, I think that could be very powerful, especially if it helps people think very carefully about what they are doing. But that's my only argument right now. Very good. And there's so much more that we could talk about. I really I I almost wish we had another half an hour. But, I mean, I think my favorite comment so far was this one. Flows are spells cast by sorcerers and Apex is spells cast by wizards. I really wish we have the time to debate that, actually. I don't know if either of you play D and D. I used to, but I I I don't even know what I would say to that. Alright, everybody. Huge thank you to Pablo and Tim for bringing this discussion to this forum. Like I said, we did have some other topics to go through. There was this one. Does flow introduced more technical debt or does it empower teams? And, we wanted to take some audience questions as well. And we had these ones as overflow in case we needed more questions, which clearly we didn't. So with that, we, I think, unfortunately, don't have time for closing arguments. What we need to do is move on and do our vote. So, again, just to refresh our memory of the statement flow cannot survive as an automation tool on Salesforce because it lack of its lack of guardrails, struggle to provide information to make it usable by AI, and the lack of documentation and general structure around it. So I am going to I need to stop sharing my screen. There we go. And Sima has put the poll up. So people, please go and make your vote. Do you agree with the statement or disagree with the statement? While we're doing this, you know so I have always thought the best way for flow to exist would have been, similar to there's an environment called MakeCode that comes with the BBC micro bit, which is a a learning microcontroller, that BBC made here in The UK and, like, I used to teach it in my code clubs with my, secondary school kids, that I used to volunteer with. And what was super cool about it is you could program in blocks and then you could click a button and it automatically converted it to another programming language. And I think it was it would either do JavaScript or Python. So, like, it literally was like flow and it was literally the exact thing, Tim, that you described, which was, you know, underneath the covers, the blocks that you created were actually code. I've always thought, like, you know, had had I designed flow from the ground up, I would have made flow actually compiled to Apex directly. I mean, it is, like you said, just a different abstraction. So I think that's fascinating. Alright. So let's see. Saima, are we all set? Oh, let's see where are are we closed now? I'm just looking for a confirmation for Saima that the poll is closed. Okay. So, previously, we had 16 votes for agree. Sorry. We had 21 votes for agree, and we now have 16 votes for agree. And we had, well, that's interesting, 56 votes. So percentage wise well, percentage wise, we went in the direction of disagree. So, Tim, you walk away with the win on this one. So there we go. This has been super fun. Pablo, Tim, I want you to thank you both for being such great sports and bringing this. I wanna thank everybody in the audience for your amazing discussion and ideas, and actually even features. I think we could pull this chat out and send it to Apex, sorry, to the Flow product team and see if Alex Edelstein can build any of these, ideas that you have. So, yeah. So great is the community and the sharing. I love it. It's so good. Yeah. Everybody, like, the spirit of this, this talk has been fantastic. So yeah. Pablo, thank you. Thank you so much. And I had a great fun, and I will consider writing CleanFlow, the book. CleanFlow, the book. You heard it here, folks. And now I'd love to see that. That'd be great. Announced on the Salesforce webinar stage here. And, Tim, thank you very much. No. Thank you. And, Pablo, I stand by what I said, mate. You are a genius. You are brilliant. You're you're the way your mind works is just fascinating. I love it. I would genuinely be interested if you wanna do, like, a a further discussion of podcast at some point. I think there's definitely a lot of value to that. There's a lot of of of of value to you. Yeah. Yeah. I'm pretty happy with the discussions, and the comments. I way more than I expected. So Oh, yeah. Great job, everyone. Thank you so much. Thank you so much. Alright. And with that, we're gonna close down this edition of Salesforce spending webinars. I wanna thank again, Kim, Pablo, and of course, our producer, Saima, in the background making this all work so seamlessly. Thanks everyone and have an amazing weekend. Bye bye. Happy Friday.