In this episode, Jennifer Lee and I talk about her experiences as a Lead Solution Designer at John Hancock. There are a lot of considerations when it comes to adding Flow into Salesforce applications and today, Jennifer helps us navigate through the different kinds of Flow and relevant use cases for them.

Jennifer is also one of the most ardent fans of Trailhead. Tune in to hear her experience with that program and her insight on all the different aspects of flow. 

Show Highlights:

  • How Flow fits into application design.
  • A description of Flow from a technical point of view.
  • The different high-level ways we can invoke a flow.
  • When to use screen flows, when to use Lightning Web Components, and when to use both.
  • What unofficial SF is and how it’s useful.
  • Good use cases for flows triggered by record actions, flows triggered by platform events, and scheduled flows.
  • UI interactions that can kick off a flow.

Links

Shout Outs

Episode Transcript

Jennifer Lee:

So what my team does is we provide consultation to all our other Agile squads and they also come and present their design solutions for our eight production orbs.

Josh Birk:

That is Jennifer Lee, the lead solution designer over at John Hancock. I’m Josh Birk, a Developer Evangelist for Salesforce, and here on the Salesforce developer podcast, you’ll hear stories and insights from developers for developers.

Josh Birk:

Today, we sit down with Jennifer and talk about her experiences as a solution designer when it comes to considerations of adding Flow into your applications. But first, I wanted to talk about a topic that is near and dear to both Jennifer and myself, Trailhead. And for some context, Jennifer’s one of the oldest and most hardened fans of Trailhead, now having just about 950 badges, and almost certainly more than that by the time you listen to this and so I wanted to ask her how Trailhead had impacted her career.

Jennifer Lee:

I think it’s been very helpful because without Trailhead, there are a lot of aspects of Salesforce that I would not touch just naturally because I’m in financial services and we don’t touch those things.

Josh Birk:

Right.

Jennifer Lee:

Just being able to go out and set up a Trailhead playground and play around with things or even like the soft skills piece, that’s a plus as well. Yeah.

Josh Birk:

That’s really satisfying to hear because definitely one of the early emphasis was I would talk to developers and they simply weren’t experienced with something like Apex REST because their job had never given them an excuse to do it. Right. So there was no loop for them to be like, well, today I’m bored, I’m just going to go build an Apex REST class kind of thing. And so that’s really good to hear because it’s definitely always a goal to let people kind of just sort of play around, to go into the playground thing.

Jennifer Lee:

Or like you might have, or I might have a requirement for Omni Channel. Well, I’ve never done anything with Omni Channel and I can go into Trailhead and say, okay, is there a module on Omni Channel, and I could just figure out the basics and follow through and know how to configure something, just to get it out the door.

Josh Birk:

Right, right.

Jennifer Lee:

Yeah.

Josh Birk:

Okay. Well, our main topic today is Flow and when to use it. You are, I’m correct in saying that you’re a self affirmed Flow addict. Is that accurate?

Jennifer Lee:

I am.

Josh Birk:

Kind of from a high level, so you’re talking about reviewing design and all of this kind of stuff. How does Flow kind of fit into like from an architectural purpose? Like what is it good tool? How is it a good tool, but then application design itself.

Jennifer Lee:

So at our company, our guiding principle is use as much out of the box capabilities, really leverage the platform as much as possible, before you go custom code. So as developers come and they present, here’s my business requirements, here’s my solution, and if I see LWC or Apex or Trigger, whatever, and I know what Flow is capable of doing, I will then challenge them and say, “Have you looked into Flow and why can’t Flow do what you need it to do?”

Josh Birk:

Gotcha.

Jennifer Lee:

There are obvious reasons why sometimes you do need to go with custom code and that’s perfectly fine, but I do want the developers to consider the abilities of Flow, especially as they’re rolling out more and more of the enhancements with the recent releases. A lot of the capabilities, which you could only do before in Triggers, you can now start to do a bit of it in Flow.

Josh Birk:

And I’m going to kind of go on a limb here and, or let me kind of, because that suggests to me, I guess is what I’m trying to say. That suggests that the amount of maintenance required to keep Apex and LWC in an org is not necessarily worth it if it can’t justify its existence. Is that an accurate paraphrase?

Jennifer Lee:

I would say so.

Josh Birk:

And I want to make a distinction here from low code, because I think when developers think pro code, they think programmatic, and then we look at declarative tools that there’s this kind of like, well, declarative, I’m a technical person and I do technical things, but let’s make a distinction between low code and technical, like just because it’s low code doesn’t necessarily mean it doesn’t have to be technical. Like how would you describe Flow from a technical point of view?

Jennifer Lee:

Well, a lot of the concepts that you use in Flow naturally is the same type of concepts in code. Flow is just a visual wrapper around being able to code. So you’re not just straight writing lines of code, you’re using point and click tools that then behind the scenes translates into code. So you’re still going to have the same best practices as you do in development and you’re going to still have your variables. You’re going to still not do DML operations within loops, right? So all those things still translate into Flow, like those are still the same concepts. So a lot of times even when developers create things in Flow, I kind of have to remind them, Hey, in code, when you do a loop, would you do these things that you are doing in Flow?

Josh Birk:

Right. Which is, that’s an interesting inverse from the conversation I had with Adam Olshansky where he’s like, Hey admins, you’re really doing coding. And it’s like, Oh, I might have to go look it up for the post podcast interview. Somebody I think framed it really well, like don’t think of it as low code, think of it as visual code, that you’re just kind of coming in through a different door in order to code it. And so I think that’s good to hear the developers can bring their technical developer mindset to make sure that they’re actually creating good applications within Flow.

Jennifer Lee:

Yeah. And then even when they’re building things in Flow, and let’s say you need a little bit more power, I’m like, well, then build a LWC component that you can use in Flow, or do an evocable Apex to do the more powerful things, but still do most of it in Flow because ultimately admins can maintain what you build in Flow, but they can’t in code.

Josh Birk:

Right.

Jennifer Lee:

So you just do enough, like do the components, build the components so admins can configure it and have them maintain it. Right? And then you do all the heavy lifting, the cool development stuff.

Josh Birk:

Which limits the amount of times that a developer’s going to need to be brought in just because there Trigger broke something or something broke their Trigger.

Jennifer Lee:

Mm-hmm (affirmative).

Josh Birk:

Now, a lot of developers are still focused and think of Flow as a UI creation tool. It’s really how it got its start and for the longest time there was kind of Flow versus Process Builder. Now we see that Process Builder is being sunseted. It’s moving towards its end of life.

Josh Birk:

So the first thing I want to do I think is actually let’s just do a quick breakdown of the headless ways that we can interact with Flow. So like what are the different high level ways that we can kick off with Flow?

Jennifer Lee:

You mean the different things in Flow that you can configure or the ways that you can invoke a Flow?

Josh Birk:

Yeah. The ways we can invoke a Flow, like a scheduled flow versus a record action flow.

Jennifer Lee:

Yeah. So we still have the Process Builder being able to invoke a Flow, so an auto launch Flow. There’s now the record triggered Flow so that you can do things to the record before the record is saved, after the record is saved, which is equivalent to Process Builder. And then with Winter 21, forward looking statements, you can do the before record delete Flow trigger. So that’s cool. There’s also the ability to create a Flow once a platform event message is received and then there’s also the Screen Flow.

Josh Birk:

Got it. So let’s walk through some of those and kind of have like let’s talk use cases and distinctions for developers. I think the use case for Screen Flows is pretty obvious, but the less obvious part now is like when do you Screen Flows and when to use LWC. And as you pointed out earlier, like when do you use both? Like how often are you putting together a solution and the UI needs can be solved through Flow alone?

Jennifer Lee:

I would say, for the most part, as a box, we could use the standard screen components probably about 75% of the time.

Josh Birk:

Gotcha.

Jennifer Lee:

A great resource, and I’m going to plug unofficial SF, because a lot of times if I have something that I want to do in a Screen Flow that I can’t, unofficial SF is the place that I’m going to go to see if there are community built components that I could just install in my org without having to bother my developer. But then a lot of our use cases for community require specific UI and functionality so a lot of times we’ll start with the Flow and out of the box and where we can’t, that’s when we’ll go LWC and bring that in.

Josh Birk:

Got it. So, yeah, let’s kick off a little tangent there. What is unofficial SF and how’s it useful?

Jennifer Lee:

Okay. So unofficial SF is the unofficial website that is managed by the Salesforce process automation product management team. So it’s unofficialsf.com and there’s a lot of great things out there. If you haven’t been there, definitely go out there. There’s things about Flows, blog posts, anybody who builds a community shared component. There are component galore out there. There’s information about next best action. And then there’s just overall like Flow resources, if you want to learn Flow.

Josh Birk:

Got it. Nice. We will definitely try to get that into the show notes for people to hop over to. Now, okay, so as a developer, I might say, okay, Flow doesn’t require code, it’s easier to maintain, but as a component, I have so much flexibility with CSS and styling. How does Flow kind of compare to LWC with that? And is there a tipping point? And I think you just hinted to it with communities, but is there a tipping point where LWC kind of wins out?

Jennifer Lee:

So I want to point out there is an architect guide on triggered automation that talks about when to use Screen Flows and Screen Flow plus LWC and when to use complete LWC and it’s when you want the ultimate control over like the pixel perfect look, that’s what LWC or the really highly complex events.

Josh Birk:

Sure, sure. And so anything that’s more like a rich user interface, something that might require a lot of complicated UX between the human and the UI. Got it. Okay. Let’s move on to Flows triggered by record actions. What’s a good use case for that?

Jennifer Lee:

As I mentioned, anything that’s after record save. So any of the things that you can do Process Builder, eventually you should be able to do with Flow. There are still some gaps that need to be filled in, but I would highly recommend if you have a use case where you’re making changes to the same record that fired off that automation, to have it in a before save record trigger Flow, because it’s just so much faster than a Process Builder.

Josh Birk:

Interesting. Are there other things that right now that like, I guess I’m thinking back to my early days with Process Builder and we kind of touched on this earlier. It’s like my pitch about Process Builder was look, these are vanilla triggers. They’re very basic triggers. You don’t need to write that code anymore. But then for the really complicated things, you can go back to Apex. Are there still good edge cases where that’s true for Flow as well, where we really want to go back to a Trigger?

Jennifer Lee:

So you would want to consider the number of records that you’re interacting with in a transaction, because you don’t want to hit those governor limits. So I still think there are use cases where if you’re touching so many records, that it really makes sense to do a trigger or any or anything that’s really sophisticated in terms of the automation logic. Apex is the way to go.

Josh Birk:

Got it. So if like I’m acting on the actions of one record, but I’m also going and getting like it’s 15 siblings and it’s parent and making a family and then restructuring the family and then putting it back together again, it’s astonishing that I can actually think about that code in my brain right now, but that’s kind of still where we’re Apex is king. That makes a lot of sense.

Jennifer Lee:

Yes.

Josh Birk:

But then there’s this interesting educates where it’s like you can have Process Builder and within your process, you’re going to kick off an Apex class. Are there certain situations where Process Builder, after a record event can do most of the work, but Apex can just kind of come in and help and give it that extra oomph?

Jennifer Lee:

Yeah. I think he could still even do the same thing and Flow to call the Apex.

Josh Birk:

Oh, sorry. Flow. Yes. Yes. So same question replacing the noun.

Jennifer Lee:

Yeah. I would say there are situations where it still makes sense to use Apex, like if you need to do things that require a map, you can’t do that in Flow right now.

Josh Birk:

Oh, interesting

Jennifer Lee:

So you’re going to need to use Apex to do something like that.

Josh Birk:

Oh. So if it’s kind of like half of the scenario you just described where Process Builder can do a lot of stuff, but like halfway through, it’s like, Hey, Apex, give me a map and then tell me the results of that. Interesting. Okay. Let’s move on to scheduled flows. What are some good use cases for that?

Jennifer Lee:

So I recently built one using scheduled flows where I have it running daily and it basically looks at people who haven’t logged into the org in the last 90 days and essentially deactivates them. We have a process at first, like a week before, we’ll send them a warning to say, Hey, by the way, you’re going to be deactivated unless you log in to reset that counter.

Josh Birk:

Nice.

Jennifer Lee:

So that’s a good use case where it’s basically, think in Apex terms, it’s basically a batch that you have running, but you built it declaratively.

Josh Birk:

Right. Right. And I would assume because I’ve tinkered around with a lot of scheduled and batch Apex, you know, the good old days, shall we say, and it’s very powerful, but you almost have to be a programmer just to even look at the class and understand like where to begin executing on it. And if you’re trying to make changes to it, like the structure of the class is kind of an impediment that. I’m just going to go out on a limb here and suggest that scheduled flow, that maintaining that and knowing how that’s working is so much easier in Flow than it would be an Apex.

Jennifer Lee:

So I wish the bugger would work better in scheduled flow. So right now it just takes one record and it finds, I think, like the oldest record and it runs through your Flow. But otherwise what I’ve been doing to actually unit test my scheduled flow is running it on like a single record and I’ll change, I’ll tweak the filter so that I narrow it down to the one record that I want to see it follow through. And then I’ll go into the hideous debug logs and try to figure out what’s going on.

Josh Birk:

Got it. Are those kinds of tricks or things you need to do in other kinds of flows?

Jennifer Lee:

No. For the most part, the debug button in Flow works for everything except for record triggered flows.

Josh Birk:

Got it. Okay. Okay.

Jennifer Lee:

And it goes through and it like shows you the results of each of your Flow elements.

Josh Birk:

Got it. All right. Now through the magic of podcasting time travel, this will actually be airing after Northeast Dreaming, even though we are talking for Northeast Dreaming. So our audience can pretend that they’re actually listening to you after the fact. And I believe for your presentation at Northeast Dreaming, you had a really detailed use case of using platform events to trigger a flow. Can you go into those details?

Jennifer Lee:

Yeah. So I have a real life use case and I want to give a shout out to Charlie Issacs who helped me with that.

Josh Birk:

Nice.

Jennifer Lee:

So this is a medical equipment firm and what they do is they give these patches that monitor a patient’s vital signs, right? So the patient goes in, the doctor prescribes whatever the procedure is, the nurse or technician basically registers the patient into this tool and then basically gives them a Salesforce login, right, to start tracking their vitals with this patch that they install, that they put to their body. So in this automated solution using platform events, so this is basically a IOT example.

Josh Birk:

Yeah. I was just going to say, this so sounds like Charlie Issacs.

Jennifer Lee:

Right.

Josh Birk:

I can’t even say, yes.

Jennifer Lee:

Right. So the patch machine will then send a platform event, receive in to Salesforce. Salesforce will then decide whether that patch monitor has been registered as an asset. And if not, then it’ll go through the process of registering it. Then it basically goes through and checks to see if the patient’s information is in there, adds the patient’s information or basically updates it, checks to see if that patch monitor piece is online or offline. If it’s offline, it could be the battery’s low, or it’s just not turned on. That will send a message for someone to follow up with the patient to just make sure that the thing is online. And if it is online, then they’re going to check the temperature of the patient, make sure, things are normal. If it isn’t, then they’re going to open a case for the caregiver to follow up with the patient and just make sure they’re okay.

Josh Birk:

Got it. So, first of all, I love the fact that even though we’re living in effectively a virtual world these days, I still run into Charlie Issacs.

Jennifer Lee:

Do you? Really?

Josh Birk:

Well, no, no. I mean just like now, like it’s like walking into a user group and Charlie’s there. It’s like, of course.

Jennifer Lee:

He’s everywhere.

Josh Birk:

He’s everywhere. The man is everywhere. But what I love about that use case is that it is also, it is so Charlie, because it’s also very so IOT, because when I used to talk about IOT, IOT had a lot of like, well, you want most of your data to be boring because usually IOT is invoked when something goes wrong kind of thing. And so I’m now thinking back to a lot of the code that I have, which is very similar in structure to what you just described, like kickoff something from a platform event, call in a bunch of APIs, see what’s going on and then write some business logic in order to react to it and if you have to call a human. So as I’m thinking about that kind of in my head, let me just ask how much of that use case was Flow and how much of it was programmatic?

Jennifer Lee:

So everything up until the platform event drops, is all Flow.

Josh Birk:

Got it. So basically just kind of like leaving the hooks is really what the programmatic side of it is doing right now.

Jennifer Lee:

Mm-hmm (affirmative).

Josh Birk:

Got it. Okay. So the one thing we haven’t really talked about that much is, I believe it’s referred to as like an auto launched flow, where it’s a flow waiting for some other kind of like UI interaction. What are some of those UI interactions that can also kick off a flow?

Jennifer Lee:

That type of flow can be launched from like all different things. There’s so many.

Josh Birk:

Gotcha.

Jennifer Lee:

Well, let’s see if I can list some off. This is a quiz.

Josh Birk:

Okay.

Jennifer Lee:

So from a process, from Apex, from a visual force page, from a custom button, from a quick action, from I think that utility bar. I think that’s it.

Josh Birk:

That sounds about right. And again, this will be after your presentation. So, if the audience members wish, they can go, they can check your slides.

Jennifer Lee:

Fact check me.

Josh Birk:

Fact check you, right. And so, I mean, is it worth asking like what’s a good use case for that? Or is it just sort of like, what is the action that occurs after whatever the human was doing in the first place?

Jennifer Lee:

I mean, it’s essentially if you want someone to do like a button click to start it or it’s anything that’s not a record triggered flow.

Josh Birk:

So it’s not like asynchronous in the background or automatically triggered off, but the human wants to be able to invoke it in some way?

Jennifer Lee:

Mm-hmm (affirmative).

Josh Birk:

Cool. All right. So in general, do you have any other tips or tricks when it comes to developing with Flow?

Jennifer Lee:

So if you’re a beginner, I know it could be overwhelming, but less so now than years ago. Like when I first started, it was that old visual Flow UI cloud designer. That’s the name. And I just remember opening up that blank canvas and I was like what?

Josh Birk:

What?

Jennifer Lee:

I have no idea what I’m supposed to do with this and I automatically close that. I just, so I would say if you’re learning Flow, definitely Trailhead is a great place to get started. There are a lot of Trailhead projects that really take you step by step on how to configure it. Nowadays, it’s almost like you don’t even need to know what a variable is.

Josh Birk:

Gotcha.

Jennifer Lee:

But for me, I use different blogs for people who gave like step-by-step. So my blog, I try to model after that as well, because I like picking use cases that I could resonate with. And then I’m like, okay, I understand what this thing is trying to do and now let me try and build it.

Josh Birk:

Got it. And you’re also involved in, is it like, do you have a webinars series, Automation Hour, or something like that?

Jennifer Lee:

Yes. So Automation Hour, we’re a free webinar series.

Josh Birk:

Okay.

Jennifer Lee:

You can find out more on automationhour.com. So I cohost that with two other MVPs. Rekesh Gupta, who a lot people might know as the automation champion and David Lynn, and we either present or we have guest presenters from the community. MVPs present their use cases and process automation solutions. So we run the gamut of all skillsets from beginner to like highly advanced. Some people might even have automation with code. So it’s all over.

Josh Birk:

Got it.

Jennifer Lee:

And all our recordings are on our YouTube channel. So YouTube Salesforce, Automation Hour, and you can access it, all our episodes.

Josh Birk:

And that’s our show. Now, before we go, I did ask Jen after her favorite nontechnical hobby and gang, I’m starting to sense a theme that COVID-19 is changing our lifestyles.

Jennifer Lee:

With the whole COVID situation, we’ve been going on hikes my dog, my little Pomeranian.

Josh Birk:

I was just going to ask what kind of dog.

Jennifer Lee:

Yeah. You would never have thought a little Pomeranian can go on six mile hikes, but this dog loves the outdoors. She loves swimming.

Josh Birk:

I want to thank Jennifer for the conversation and the great information. Of course, I want to thank you for listening. We will have links to the relevant material in the show notes for this episode. And if you want to learn more about this podcast, head on over to developer.salesforce.com/podcast, where you can hear old episodes, read the show notes and have links to your favorite podcast service of choice. Thanks again and I’ll talk to you next week.

 Get notified of new episodes with the new Salesforce Developers Slack app.