Jeffrey Kranz, who joins to talk about Salesforce Flow, is a Product Manager at Riskonnect.
Main Points
- The mindset of “building for flows” v.s. “Building with flows”
- Flow is the future
- The cool features of flows
- How to debug and test flows
- The fast evolvement of the flow
- Flow features: Apex-Defined Data Types, External Services, Custom Property Editors
Links
Video Teaser
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:13] Hello, everybody. This is Xi Xiao. This is yet a new episode of Salesforce Way podcast. Today, I'm sitting with a new guest. His name is Jeff Kranz. Hello, Jeff. Hey Jeff, nice to be on here with you. This is really exciting. Nice to have you on the show, Jeff. Would you like to introduce yourself to our listeners? I'd love to. Yeah. So my name is Jeff Kranz. I work for an OEM Salesforce partner, and what that means is we build our own software on top of Salesforce, and we sell it to our customers. And they have their own special instance. They don't use it for CRM capabilities or anything like that. They use it for our software and. So we offer risk management software. There's a whole bunch of different products we offer, and my role within that is as the platform product manager. What that means is anything that's kind of shared across our product lines, kind of falls down to me. So, customers often need implement custom implementation things, and so we offer generic components that are shared across our product lines. We have utilities that are used in flows. That are shared across our product lines, and then I'm also kind of guide our best practices around how to use the various Salesforce technologies to leverage the capabilities so that our customers are happy. Okay, that's cool, and and Jeff, you are here
[01:44] to coach me about flow. Actually, in the past, we had a couple episodes talking about flow. That's all cool, but flow is Salesforce is spending a lot of time, effort, really to improve the tools. And it's been maybe already two years. I'd love to hear from you again. Like, what's the new features and what are people's attitudes toward flow in the ecosystem? You know, in the past, it wasn't that easy, especially for developers to pick it up. We tend to think it's a bit clumsy, slow, or doesn't really handle really complex situations. We want to see where they are and if we can change our slightly negative attitude toward flow, right? And you talk a lot with developers. You know, you know how to deal with us, so. Yeah, I and I, you know, I, in my role, I I work with everyone. So, you know, I've got every day I. Get up at seven, have our stand up with our developers in in India and the UK, and then we spend the rest of the day working with working with customers, working with our implementation folks, our admins, and our developers here in the states. And so I speak with everybody that's involved, and so I get a bit of that perspective from everyone. And I'd say. That internally we've I think we've had pretty good willingness to to try to you know to understand
[03:14] flows from our our development side, but and out in the ecosystem I I do notice that there is a lot of being unhappy with them or you know discontent I think might be a good way to describe it and I don't think all of it is unwarranted. I I do think that if you think of flow as when you're coming as a developer and you think of it as a way to do the same thing that you're used to doing just visually, that could lead to a lot of discontent because I I don't think that that's its real intention. I also think see a lot of discontent around how and and. By expanding the the capabilities of flows and lowering the barrier to entry to start building flows, but also making them very robust, there's a lot of concern around disrupting a process that that you may have in place. So you You know, building a record-triggered flow. You know, if you don't incorporate that into your tests, you know, that could blow up all of your tests, right? Yeah, that's that's true. Salesforce platform is kind of how do you say mixed with different layers. We have the UI, which has the flow. We have the code. We have some other validation rules on the database. So all these things are set into the same platform. So, if we build flow
[04:45] or the declarative tools, we need to understand what's the impact towards the code I have been done in the past. Otherwise, it breaks all those tests. We need a person, at least one person, sitting on the top to understand everything. But that person is really hard to find. Even architects, most of architects, they don't really do this kind of hybrid solutions. So it's it's not easy to do. Yes, absolutely. I think that that's where things could you have a lot of room for growth. There is that hybrid understanding, and I and I think hybrid might be one way to maybe. Improve that is to change how we think about flows. When you're designing solutions, it's often seen as these two separate things, and they are. But how is it that they connect? And and you want to reduce the unexpected ways that they connect. So you want to have a better understanding of. How they connect, and I think one of the ways that you can think about it that I think helps a lot is instead of thinking about.
[05:56] Using flows to build with flows, and when you're thinking about it as a developer, think about flow building for flows, because what I see as a real big advantage of flows is its extensibility. With invocable actions and custom screen components, and local actions, and the ability to subscribe to platform events, and the ability to connect to external services, that if you look at flows as the interface. To the declarative side of things, as more than looking at flows as another thing I have to build for and account for alongside what I'm building, I I think that's what starts to move. Things in a lockstep with that declarative side. That's that's really interesting. So we should think of it as like building for flow. So flow is definitely first class citizen in the platform, right? We can surround it with all the coding features. But all the features that just mentioned for flow, you mentioned like external services, a screen was a flow screen or something like that, a custom screen component. All these things I have really little knowledge about,
[07:26] so we can we can go through that. Maybe you can already give me some ideas what those things are. Yeah, absolutely. So if we're thinking about building for flows, so when you let you know, let's chunk it up into like invocable actions. I think is is a real powerful way to interface with flows. And so when you're talking about automation. When you're thinking about building, you know, you have some requirement that you need to be automating some, some activity when records get created or updated, and so you go to triggers and you, you know, you you have your trigger framework and you you, fit it in to, whatever else is going on. If you're building things right to a developer, you can kind of see, you know, one of the goals that you have as a developer is to be able to look at your code and understand, kind of abstract way, what's happening under the hood to see, okay, this is the the from a business perspective, what is happening and in what order, and so. Put in these frameworks and take these different approaches to try to get that level of abstraction to be able to make your code readable. Yeah, in the in the world of automation and declarative code. That is another layer of abstraction. You can see it, and if you see it in that way,
[08:56] I think that unlocks a lot because what you can do is you. Have an invocable action. You piece out what all needs to happen, and if you expose that as an invocable action, you can use record-triggered flows to order it and declare how it should work and in what order it should work at the level of the business. And so, if you're working with admins, that's where it's really a lot of value. Because then they can, you can work with them to say, "Hey, here are the pieces that you'll need to deliver on what we need to do for this customer." Then the the the more complicated logic is abstracted away in Apex, but the business aspect of it is this chunk of work that you can incorporate into the flow. So the flow could decide how and when it can invoke the Apex, and we give the heavy lifting of that to the Apex to do the job, right? That's absolutely how we we split it. Okay. Which this one I've used it in the past. I know Flow can call Apex to run whatever logic, and then maybe in the end can even return the result back to Flow. Exactly right. It looks cool. But I don't know because I've never really used it in a big business requirement. I don't know
[10:27] does it have limitations? You know, these things I've never touched. It's actually pretty robust. They've done a very good job. My head is off to the the flow team and the Apex teams for coming a long way. Whenever a record gets updated and it and and a record triggered flow or some kind of flow and gets executed, that results in a flow interview, and that's an an instance of a flow. And when those are run in the same transaction and it's the same flow. They get bulkified together, and and when it comes to building your invocable Apex, I think it's it's it you know it's very similar to building a trigger where you're accepting multiple you know up to two hundred records at a time. You'll be accepting the inputs from up to two hundred flow interviews at a time. If you're used to building triggers to be bulkified, it's not a big leap to build your invocable Apex to be bulkified and performant. And I think there's a lot of carryover frustration from process builders. Where under the hood they they are flows and they have the same kind of bulkification, but there's a lot of CPU overhead. In yeah, it was very easy to build a process builder. You know, you just wanted to update fields on the same object that triggered the process builder, and process builders
[11:57] could only issue DML, and so it would. Cause all these recursive transactions. I mean, for us, for developers, the things that in the past we will guide it to try flow and with not flow, maybe process builder to call Apex. But in some situations, it doesn't handle the things that well, as you just mentioned. Maybe the the heaps are used too much, memories or the CPU is is like hitting the the threshold. And we then fall back to the code, and the code has been our best friend. It always guarantees it will work. Right? We don't want to take a different route, and then we hit the wall. We come back, which takes much longer time. And we have tried that, and we kind of failed, even though Salesforce. Say is this the best tool? The clever tools everybody should use that. But in our heart, we have this different voice. But now you are telling us the flow trigger really can handle the bulkification smartly. Yeah, and a big, a big, there are a couple of big advancements that really help that out a lot. And and I and I and I think what I know about there is like those CPU limits that you were hitting were a lot because because of the overhead involved in process builders and the recursive transactions that like that process builders kind
[13:27] of. Guided admins to build that that they would cause, and one of the big things that record-triggered flows now have that. Help lower that you know cost in a transaction for to for existing is the before save record triggered flows. So there you can build a record triggered flow that runs before the save, like you got before triggers, and it actually runs prior to Apex triggers being, and so. You're very limited in what you can include in a before save record triggered flow, and all you can do is you can run a get, which is a SQL like the equivalent of a SQL statement, and you can update fields on the record that triggered the flow. So you're not issuing a DML on it. You're just assigning values to that record that is going through the save process. And so, a lot, a lot, a lot of the declarative use cases involve just needing to update fields that are on that record that's going through the save. The vast majority of workflow rules—that's what they do. And the vast majority of process builders—that's what they do—and both of those automation tools issue DML statements on those updates. And this
[14:57] is a a brand new thing that in the declarative world on Salesforce is that you can now declaratively update a field on. Save or update on create or update, and have it not issue a a DML and and that. Alone makes you know quite as fast as Apex, but it is effectively as close to Apex efficiency as you can get. Way better than even workflow rules. Yeah, here there are at least three things: is a workflow, process builder, and flow. The thing you advocate most is the flow, right? Yeah, workflow rules process builders are going away. They're they're on a deprecation path right now. When I'm talking to to admins and and declarative side of things, you know the vast majority of use cases of things they were doing were just to to update a field on that record that was going through the save by going through flows to do that. Not only are you do you have more capability to evaluate other records on the in the database before you make that change, but also but making that change is just way faster, way more performant, less side effects than either of those tools. I got it. Okay, no problem for me. I can go with flow if if that's the future. The
[16:27] issue I usually hit is the how to debug. Do we have the good diagnostic information, and how to test? Those things are much easier on the code level when you really see the raw code. Yeah. So I think so. Testing and debugging. I would say you know they're they're kind of two sides of the same coin. You know, debugging is kind of when you're trying to figure out what's going wrong, or and and testing is just validating that. Hey, my what I intended to do is what it does, and that moving forward, when I make a change, it'll continue to do that. So, as far as debugging, there are some good debugging tools now available. It's getting better. Recently, they they offer now the ability to use the debug in builder debugging tool on record triggered flows. And what you can do is you can pick an existing record and. Use that as the the record that's going to run through your flow, and you can tell. And it depending on what context you the the flow is supposed to run in, you can say, hey, this is going to represent an insert or an update, and then it steps you through each step of your flow, each element in the flow, and tells you what are the values at this step. What is it doing? Where where are what are all of my resources are at the stage of the flow? We can tell you what your where your limits are at each stage of the flow.
[17:58] And then at the end, it rolls it back so it doesn't make an actual commit to your database. Okay, where do you see this information in the UI or? It's right in the builder. Yeah, so in the flow builder, there's a debug button. And that'll launch in a new browser tab, and it'll ask you to some setup information around the debugger. It's available in other types of flows as well. So if you're building a screen flow, you might have some input values that the screen flow accepts, or an auto launch flow might have some input values, and so it'll ask you, "Hey, what values do you want to use as your inputs?" On the flip side of for testing, I am aware that the flow team is working on, but it's not out yet, and I haven't seen it. But this idea of flow based testing. So right now you can write an Apex test, and it'll incorporate whatever happens in the flows. Haven't seen used very often, but I think would be really helpful in that scenario where you want to enforce the the the test coverage of your flow automation. Is there is a way to enforce that? You can enable flow coverage requirements, and what that means is that in order to deploy an active flow, that You'll need certain a certain percentage of coverage, and you can define what percentage that is.
[19:29] Coverage from an Apex test. Okay. Oh, that's that's the first time I hear about this. It's a. It's it's not. Well known, I don't think, and and it's a very powerful feature for those organizations that want to incorporate automation into an already well-established process that you've got. And I I think that a really nice enforcement mechanism. Indeed, if the organization has already spent a lot of time to develop the flow, it gets more complex. Definitely have some test coverage. is is really good. And in flow, I know that there are some good new features, but not many developers knows about it. For example. The Apex define the data type, and also one thing you mentioned external services. Could you quickly brief us what are these things? Yeah. So, and when you're in Flow Builder, you can define variables, and as you know, you can say, "Hey, it's a you've got a lot of primitive." Of data types available, and you can also say, "Hey, I want a record variable." One of the really big advancements is was the ability to define an Apex-defined data type for flows, and really that's done by just defining a class structure in Apex, and and and making it Aura enabled. It's
[20:59] a way. To then, when you, when once you have that, when you're in the Flow Builder, you can select that as a data type, and you can create a variable with that class structure, and so all of the properties of that class are now available as fields in that data type to populate in that flow. So, okay, yeah, because in the past I know only the primitive data type those are allowed, but now we can really just like in Apex, you can define a class with our custom data type and bring that instances into the flow. That's what you mean, right? Exactly right. So, and then they they've taken this few steps further. It's really nice. So. You define an Apex-defined data type, and let's say you've got a string property that you've exposed there, so that shows up as a text field that you can populate in an instance of that. They then they said, okay, you can do a subject. You can do like a a record property, and so you can populate a record as a field on an Apex-defined data type, and then they took that a step further and made it so you can do a generic S object property. It can be a generic S object, and in the end, you can cascade it out into account or opportunity, depends on the real, real type underneath. Okay, we use that a lot and in our product because
[22:31] you know we're as I mentioned, we're kind of we're features that are used. Across different product lines, and so we we have to be very generic, and so take advantage of that capability quite a bit. That's cool. You also mentioned external services. What what's that? Okay, so. This is really cool. You know, we we interact with third party systems all the time, right? So there's an API out there that you want to you know hit you want to hit that API endpoint and get some data back. And there's a certain data structure that it expects. And so you build a you build your Apex class structure. You know, a common approach this is you're going to build an Apex class structure to construct that data to send back, and you're going to have another Apex class structure to To be able to serialize and deserialize the data for communication with this endpoint, external services. Makes it so you don't have to build out that structure. It generates that structure for you, so you don't even need to write one line of Apex code at all. Not one single line. It is incredibly cool, and it it is the real deal. And I highly encourage people to check it out because it. I was blown away. I thought I was a little skeptical in how well that could actually work, and it actually it it works. Okay, it's it's very impressive. I'll definitely take
[24:01] a look, and maybe I will ask you to get the URL to that feature and put it in our show notes. I will. Okay. Cool. There's a feature that we didn't talk about at this point yet, but custom property editors, the admins. You know, you want to make it real clear as to what they can configure for a particular action or a particular flow screen component. So, across the platform, when you're building components and things like that, it's been a very flat way of defining the configuration attributes, and it's I think that's been a challenge everywhere, not just flows. And something that the flow team did that I think takes that to Kind of pushes them out ahead of everyone else on the platform is this idea of a custom property editor, which is not possible anywhere else on the platform. So if you've got a lightning component for App Builder for a digital experience, you only can do those kind of primitive attributes, and it's just. Flat attributes. You you you don't have any way of kind of designing a custom experience for configuring your components, right? In Flow Builder, you can design and build and bundle with your screen components and with your invocable actions a custom property editor. And what when you do that, it replaces
[25:32] that standard list of attributes. With what you've built as your custom property editor, and so it it's a it's a feature that allows you to make a very custom configuration panel that guides the admin to provide exactly what they need in the language and in the format that they needed to make it very intuitive. We have talked about the new feature flows such as Apex-defined data type, external services, and now you mentioned this custom property editor. The last one is the most challenging one for me to understand, but I'll put the link into our show notes for everybody to check. Yep. But and it and I really encourage people to look at that custom property editor capability because it it really helps make that if you're working with admins and part of the Challenge is getting to understand how to configure it right. It's a really nice way to customize that configuration experience. Okay, I'll definitely take a look and put it in our show notes. Okay, I think we have talked a lot. We start from the conceptual level that we should think as like building four flows, right? We need to shift our mindset a bit. Then we talk about the flow. It's the future. I shared our complaints from development point of view, how to debug, how test
[27:02] those things. Actually, are really really in our mind. So thanks a lot, Jeff. I think we covered a huge amount of information, and thanks for coming to the show. I don't know. Do you have something else you still want to add at the end? No, I just wanted to thank you for having me on. I mean, this this it's a one of the challenges with this type of thing is it's evolving fast. Yes, it is. Yeah, the the summer release is not far away, so you know there might even be things we talk about now that are going to be outdated already. Yes, so I I just. You know, I want to encourage people to to to keep up with it. You know, if nothing else, to keep up with the capabilities. You know, everyone you know doesn't have a lot of time. You know, everyone's got lots of things going on all the time. But this is if there's one feature to to kind of keep up on, this is one because there's a lot going into it, and every release, it's it. I'm getting more and more impressed, and so that's what I would add. Yeah, thanks a lot, Jeff. Thank you so much. This is this is a pleasure. So talk to you next time. Bye bye. Bye.
