Optimize Subflows for Efficiency with Christina Nava

Salesforce Admins Podcast

Today on the Salesforce Admins Podcast, we talk to Christina Nava, Director of Salesforce Strategy at Gaggle.

Join us as we chat about making flows more manageable with subflows.

You should subscribe for the full episode, but here are a few takeaways from our conversation with Christina Nava.

Creating flows to save time on business processes

In the biz, Christina is what we call a long-time listener, first-time caller. She’s been listening to the podcast since 2014, back when I was known as the ButtonClick Admin. And while I’d love to toot my own horn, Christina has come a long way since learning Salesforce from a podcast. She’s an 8x Salesforce Certified Professional, an experienced software consultant, and she recently appeared on Automate This! to talk about how she uses subflows.

At Gaggle, Christina uses Salesforce to help her users match patients with mental healthcare providers. It’s a tricky process because both groups have different characteristics, like gender, specialty, and availability, that need to match up. She uses screen flows to make this process much quicker, but it’s her subflows that make all of this possible.

How to simplify flows with subflows

When she’s building a flow, Christina is always on the hunt for how she can simplify things for herself with subflows. One major tell is if she finds herself rebuilding a process she’s already written. That’s when she knows she might need to write a subflow. That gives her to option to call it in multiple flows, and simplifies things if she needs to make changes.

Christina gives the example of how she needs to update the same records in three different scenarios: if they get new information, at certain regular intervals, and if some other piece of information changes. To do this, she calls one subflow in three different ways. If it needs to happen immediately, there’s a screen flow. But there’s also a record trigger flow and a scheduled trigger flow to handle the other scenarios. All three are super simple, they just each call the same subflow a different way.

Using more subflows doesn’t make a difference to your users in terms of what they see, but it’s cleaner and easier for you. Think of it as a gift to yourself.

Christina’s process for gathering requirements

The key to structuring flows and subflows well is to be thorough when you’re gathering requirements. Christina’s process begins by sitting down with a user and asking them to show her what they do. Any time they do something, she asks them why they did it. Why did they set that filter? Why did that provider not work? Why did they pull up that provider instead?

The next step is to see if she can do the process herself. If she can’t do what they did, she wants to figure out why that is. The goal is to be able to write instructions for how to do the process as if they’re for someone who has never worked at her company before. That’s when you know you’ll be able to write a good flow.

There’s a bunch more that Christina shares in this episode about why she uses one master flow per object, how she debugs, and her tips for naming conventions, so be sure to take a listen. And if you haven’t caught up yet, check out her episode with Jennifer Lee on Automate This!

Podcast swag

• Salesforce Admins on the Trailhead Store

Learn more

• Christina on Automate This!: Work Smarter, Not Harder with Subflows

Admin Trailblazers Group

• https://sfdc.co/admintrailblazers

Social

• Christina: https://www.linkedin.com/in/christinanava/

• Salesforce Admins: @SalesforceAdmns

• Mike on Threads: https://www.threads.net/@mikegerholdt/

• Mike on Tiktok: https://www.tiktok.com/@salesforce.mike`

• Mike on X: @MikeGerholdt

Full show transcript

Mike Gerholdt: This week on the Salesforce Admins podcast, we are talking with Christina Nava, who is an 8 time Salesforce certified professional, a ton of experience in software consulting, and hey, she started listening to the podcast back when I began the podcast in 2014. So talk about full circle from learning Salesforce by listening to the podcast to being on the podcast to teach us more about flows and sub flows. She was recently on an Automate This live with Jennifer Lee. So if you're listening to this, be sure to check out the call notes and notice below the link to watch that on YouTube because that's super cool. Now, before we get into the episode, I just want you to do one thing and that's make sure you're following the Salesforce Admins Podcast wherever you get your podcasts, whether it's Spotify or iTunes or iHeartRadio. That way when a new episode drops like this one, which is amazing, it's downloaded right to your phone. So when you hop in your car or you jump in the transportation to get to work or you walk your dog, all you got to do is press play. So really cool there, but let's talk about flows and sub flows with Christina on the podcast. So Christina, welcome to the podcast.

Christina Nava: Thank you. I'm really happy to be on here.

Mike Gerholdt: Yeah, well, if everybody is diligently following all of the awesome admin stuff that we're putting out, they would've watched Automate This yesterday and saw some of the amazing flow stuff that you were doing there. But before we get into that, let's learn a little bit about you. So how did you get started with Salesforce?

Christina Nava: So I'll say that I'm probably within the vast majority of people and I got started because I was an also admin or an accidental admin. Back in 2014, I became the director of tech support for a SaaS company and it's like, "Hey, what's this thing called Salesforce that we've been using for our support team?" And so I started looking into it and I'm like, "This is great." Of course, this was before Trailhead, so trying to learn was fun. And fun little tidbit is one way I started learning is I listened to all the different podcasts I could and one of them was the ButtonClick Admin. And so thank you for helping me learn Salesforce in the beginning. So I started listening and started learning the terminology, Googling and just playing. And so that's how I got into it. Then I did that on and off for about five years, and then in 2019 I made the leap and I made Salesforce my full-time career. And so I've been doing it full-time since then.

Mike Gerholdt: Wow. Well you're more than welcome and I'm glad to have somebody full circle come on the podcast from listening all the way to now you're teaching.

Christina Nava: It's exciting.

Mike Gerholdt: Eventually in the next 20 minutes or so, no pressure.

Christina Nava: No pressure.

Mike Gerholdt: So I teased out with Automate This, which is really cool YouTube series that Jennifer Lee does and she live-streamed it yesterday. You can probably watch it on our YouTube channel. And you were on there and you were talking about flows and specifically the thing that I kind of want to dive into a little bit of sub flows. But if people haven't watched it, I don't want them to feel left out about what we're going to talk about. Can you summarize a little bit of what you talked about on Automate This yesterday?

Christina Nava: Yeah, of course. So I built this flow for Gaggle. Here at Gaggle, one of the things we do is we help provide therapy and coaching for students. So the way we do that is when a student comes to us needing services, we match them with a provider. Well, the client has a lot of requirements including why they're being referred, what times of day they can meet, if they want to, male or female providers, lots of different criteria. And then on the other side of it, we have providers who have their own criteria. When they can provide services, their areas of specialty, obviously if they're male or female, what languages they speak, all of it. So when we first started and we had a client come in, a student come in, we needed to match them. It could take five to 10 minutes to find the best match for them. And you can imagine we're getting 5, 10, 15 students a day. That was taking a lot of time. So I decided to create a screen flow that we can run from the student record that would give our internal team a list of providers that were the best match and then they can just click on the button, automatically assigns them, good to go. Ended up saving our internal team 5 to 10 hours a week.

Mike Gerholdt: Wow. And the match was done based on criteria that you put in, right?

Christina Nava: Yes, exactly.

Mike Gerholdt: Okay. I mean, I asked because everything's AI now.

Christina Nava: That's actually funny you asked because I was on Automate This previously and the flow I did for that one was how their providers actually add their criteria in.

Mike Gerholdt: Oh, okay.

Christina Nava: So had a flow for that as well.

Mike Gerholdt: This flow is rockstar flow. But God, man, I'm thinking back to the days I was on the platform and I wish I so could have used this for about a million other things. One part that you talked about is creating a sub flow, and I'm not good at creating flows like Jennifer Lee is, which is hard to be on team with her because it's like being on, I don't know, the Olympic team and you're like, "Oh, well I just have to go against this gold world-class Olympian every time I build a flow." But one thing that I am really trying to wrap my head around more is I don't have to create the entire flow every single time. I can reuse components of that and that being sub flows, and then when I do so then it's one place to update things as opposed to, "Oh, we changed this email template, now I got to go into these 20 different flows and update it with this new email template."

Christina Nava: Exactly.

Mike Gerholdt: Help me understand how you come about creating some of your sub flows.

Christina Nava: So I would like to say that I'm the kind of person who listens to my users, sits down, draws it all out and knows exactly what they're going to build when they sit down a flow builder.

Mike Gerholdt: You're not perfect? Come on.

Christina Nava: I'm not, don't tell the people I work with.

Mike Gerholdt: Don't listen. We'll cut that part out.

Christina Nava: Exactly. So a lot of times I'm getting in and I'm building a flow and I'll find myself building the exact same loop and I'm like, "Wait, wait, wait. Why am I duplicating my effort here?" So for me, I build a sub flow in a couple of different instances. One is when again, as I just said, I'm in the same flow and I just rebuilt the same code. That's a waste. Let's take that out and make it a sub flow. There are other times when I do sit down and I'm doing my design, I'm thinking in my head and I'm realizing, "I need to actually call this multiple ways." And so as you all know, we have screen flows, we have record triggered flows, we have scheduled triggered flows. I actually have one sub flow that I call three different ways. So for this one, what I'm doing is I'm populating the opportunity team members and I need to do it at specific times. So I will have, well, if I need to do it immediately on the fly, obviously I have a screen flow, we click a button, good to go. There are other times when I need to do it on a record triggered flow when certain criteria happens. So because I don't want to have to reduplicate my effort, what I'm doing for both of those is with my record trigger flow, my entry criteria, I just start it, I immediately call a sub flow. That is all I'm doing in this flow is I'm calling a sub flow. With screen flow, exact same thing. I am, just click a button, call my sub flow. And then I'm doing the same thing with my scheduled triggered flow as well. So I have three different flows that all they do is call one sub flow and I loved that.

Mike Gerholdt: So how much of that sub flow, I guess are you setting criteria way before that so that sub flow kind of knows what it's adding those team members to? How complex is that sub flow? Is it very simple, I'm guessing?

Christina Nava: So on a scale of say one to five, it's probably at a one, maybe 1.5. It's a fairly simple flow. All I'm doing is I'm sending it the record ID of the opportunity and then it's doing all of the different decisions inside of it.

Mike Gerholdt: No, I like that. I always feel like use cases that are easy to identify looking back. You probably were on what your third or fourth flow and you're like, "I need to rebuild this." Right?

Christina Nava: About that. I think I was in probably my third or fourth iteration of the first one. And realized, "Wait, wait a minute. I need to give them the ability to actually do this manually as well. Hold on. I don't want to recreate this whole thing. I'll do it in the sub flow." It's kind of had that light bulb moment popped up.

Mike Gerholdt: So then kind of walking people through this, I'm assuming at this point I would be thinking, "Oh, I could really go through and kind of do a flow audit and look at some of the stuff that I've built and see if there aren't parts that are replaceable." Have you done something like that? And what would be your process for looking at all of your flows and then finding sub flows that you could build?

Christina Nava: Honestly, that's on my to-do list.

Mike Gerholdt: Oh, is it? 2024, here we come.

Christina Nava: With the new flow stuff that's come out, a couple of things with the whole new validation that's coming out, well tonight for me and some stuff that came out last year, which was when you send an email actually being able to attach it to a record. That's on my list of going through and updating all my flows, just haven't gotten down to it. So as of right now, the way I handle it is if I'm going into a flow and modifying it anyway, I'm making those updates at the same time.

Mike Gerholdt: So it's kind of an as needed, but not house cleaning, shut everything down and redo all our flows kind of thing.

Christina Nava: Exactly. Because your end users don't see these changes for the most part, especially with the sub flows. What you're doing is you're making things a little bit faster, but you're mainly making things cleaner and easier for you. So because we all live in the admin world and our users come first, what's easier for us gets pushed down on the bottom of the list.

Mike Gerholdt: Get cobbler's shoes. Right.

Christina Nava: Exactly.

Mike Gerholdt: I hear you. Okay, so this was a thing that Jennifer has taught me, and I'm horrible at this, but do you have a naming convention or do you have a way that you always name your sub flows?

Christina Nava: I do have a naming convention.

Mike Gerholdt: Please share. Please share.

Christina Nava: So it goes with the object name first. And by the way, I stole this from... See if I knew you were going to ask this question, I would have the name.

Mike Gerholdt: I mean everybody steals stuff. So you copied it.

Christina Nava: I'm sorry, I copied this because it was amazing. So the first word is the object name. Then it's dash and then either SF for screen flow, RTF for record trigger flow or STF for schedule triggered flow. Then dash. And then if it's for a record triggered flow, you'll have new or new and update and then after or before. And then if it is a master flow, because I am a big believer in having one flow for one object, if you can, I'll have the word master. If not, it'll be dash what it's for, for example, account RTF new and update after master. I can immediately look and know just from the name what this is going to be for and how it's called.

Mike Gerholdt: I love all of that. That needs to be on T-shirt.

Christina Nava: So when I have someone new I'm training, I'm like, "Can you rename your flow for me?"

Mike Gerholdt: Yeah, because it doesn't work.

Christina Nava: Exactly.

Mike Gerholdt: I'm going to only slightly deviate. We're going to take a quick exit off the highway. Because you brought up a subject that I have been asked a lot and you said, "I like to have one master flow per object." Can you explain that? Because I've been asked many times, "Should I have one that does everything? Should I have 20, should I have five, should I have three?" And I say yes to all of those answers because yes is correct, but I would love for you to take me into your world of how you manage that one master flow and if there's times that you've ever had to deviate from it.

Christina Nava: Okay, so that is a really good question. I still personally Google that about once every two to three months. "Am I doing this the right way?" Because everybody does have their own opinion. So for me personally, I have a lot of flows. I'm a flow addict. I love flows. If I could sit and do flows eight hours a day, I think I'd be the happiest camper imaginable. So that being said, I have a lot of flows in my orgs. And once you get up to 50, 100, 150 flows, it's hard to find what you're looking for. So that almost is, I don't know, maybe a third of the reason why I have one flow where I can just because one place to go to. And of course the old way when I started with process builder and people are thinking, "The old way? I did workflows."

Mike Gerholdt: I know.

Christina Nava: I can hear that.

Mike Gerholdt: I did workflows.

Christina Nava: I know. But with process builder, it was definitely one per object because that was the only way you could control the order of things. Well with flows, now you can actually control the order and how they're called, but I got in the habit of that one master, but it's so much easier for me to pull up this one flow and even if it's fairly large, which by the way another reason to use sub flows is to actually pull code out and make your master flow cleaner. So you're looking at less. So side note there, we took a deviation to the deviation.

Mike Gerholdt: It's okay.

Christina Nava: Thank you.

Mike Gerholdt: Sometimes you have to pull around back of the truck stop.

Christina Nava: Exactly. So I like being able to pull up this master flow and it's like reminding me, "Oh yeah, this is everything that happens when an account is updated." So that's another reason I like to use one master flow, but there are plenty of times when I have more than one flow, even more than one record trigger flow. So for example, for my cases, I have one that has to do with sending pending emails. So when a case is put in pending, I send an email after one day, three days, seven days and fourteen days. Well I'm obviously not going to have that in my master flow. So I have one flow that just handles kind of those scheduled things after a while just to kind of keep my flows cleaner and it's easier to look at and I have to change that flow a little more often than I have to change others. That was a long answer.

Mike Gerholdt: No, it's okay. I was listening and digesting. I'm still just feeling the like here we go, one master flow per object situation. So I'm not saying it's wrong, because you can totally do it and you do. It's just a lot of testing, I feel.

Christina Nava: It is. It's a lot of testing.

Mike Gerholdt: One thing to get us back on the highway.

Christina Nava: Darn it.

Mike Gerholdt: Well, we stopped, we had some beef jerky, we looked at the map, we know where we're at and you're like, "Oh look, there's a campground off to the side."

Christina Nava: I got some Doritos, I needed my Doritos.

Mike Gerholdt: There's always a campground by rest stops. And you're like, "Whoever camps there, why would you want to?" I don't know. I would love to know. So taking requirements for screen flows and sitting and walking through and I'm looking at yours, which was the decision loop of helping pair those students up faster, right? That's the goal, right? Because 15 minutes to pair somebody up, you can obviously do the math and like, "Well here's how many people we need staffed 24 hours a day in order to handle this, right?" What was the level of requirements gathering and how detailed did you have to be when you were building that flow? Because I've worked through decisioning elements before with people and there's in their head they expect how it should work and then there's actually how it works and actually what they told you. I'm curious, what was your requirements gathering like?

Christina Nava: I do want to say another really quick side note on this flow. What I showed in the demo and what you see in the blog post is maybe about a quarter of the size of my real flow. If I had the whole thing, it would've been way too big. And so just keeping that in mind, there were a lot of, not necessarily requirements I needed to get for my end user, but a lot of fields that we needed to match up. So going back to the requirements gathering, obviously you have this business process review, you sit down with your end users and you're like, "First thing is show me what you do." And so you watch them pull up this student and pull up all their providers and you start watching them match. And that's when it's like, "Okay, why did you set that filter? Why did you set that filter? Why did that provider not work? Why did you pull this one in?" It's a whole lot of why questions. And so once you get to that, what I kind of like to do afterwards, it's like, "All right, let me reproduce what you did." And so I am now pulling up the student and using what they showed me trying to find a matching provider and I can't find one. Well, how come I couldn't find one? "Oh, we forgot to tell you this." Or I pulled up five instead of, and these four wouldn't match. Well, how come they wouldn't work? "Oh, we forgot." So one of the things I love to tell people is if you can write instructions for someone who has never worked at your company before and it is step one, go here and pull up this record. Step two, click this, and if you can literally give me step-by-step instructions, and if step five is not use your gut, then I can create a flow for you. But you have to be able to give me those steps. Either you give them to me or I develop them working with you, but we have to be able to know exactly what to do at every step in the flow.

Mike Gerholdt: That makes sense. I also think it's funny just, "I just go with my gut."

Christina Nava: You'd be surprised at how many times I hear that from people.

Mike Gerholdt: No, I know. I had a contract routing process that I had to do once that was just kind of like, and then I get it down to four or five and I go with this one and why? Well, it was Wednesday? And that one looked good. Awesome. Let me work that into criteria. So I guess thinking through this with screen flows and with this kind of decisioning element, did you ever create, for lack of a better term, like a backdoor of a, "I can't find anything" and run so that if somebody, because I mean you deployed this to, I don't know how many users and if they run into an issue, they can't just raise their hand and you come running and then that way it would also give you a chance to look at the decisioning criteria that led there to be, "Oh, well it looks like we need to append this flow." Do you have something like that?

Christina Nava: No, actually I don't. That'd be a good idea. I'm going to steal that. What it is just if it finds no matches, it pops up a screen saying we couldn't find any. And it's usually because they're just truly isn't a provider that matches those exact requirements and that is when they go use their gut. But what do you mean I can't just come running when they snap their fingers? Is that actually something I cannot do?

Mike Gerholdt: Well, just saying there's probably an occasion where maybe you're sitting recording a podcast and then a user can't-

Christina Nava: Good point.

Mike Gerholdt: Get your attention right away. No, I just happened to think through it as I was looking at what you were building and also thinking through some of the processes I had built where it's, "No, we actually, it's not that I didn't gather all of the requirements, it's that we actually just found a new outlier to a process." And you try to hit the 98 percentile of stuff. But I happen to think because then you'd want to capture stuff like that, especially in a screen flow.

Christina Nava: Yeah, that's a good point. I probably do need to make more of a process as to why could we not find a match with this? Maybe these providers got to 98%, but there was that one that we couldn't find a match on.

Mike Gerholdt: You mentioned emails in a few of the flows that you've created, and I'm sure there's quite a few emails your flows send out. How do you manage that? I bring this up because I feel like it's always a requirement that admins take and then the four days after you deploy something, you immediately get, ironically an email or a knock at your door and be like, "My inbox is full." Well, criteria that you said for emailing you. Are there red flags or questions you bring up or alternatives to email that you offer?

Christina Nava: Absolutely. So we use four different kinds of notifications here. Obviously email is one of them. Another one is the bell notification, just popping that up. The third one would be Chatter, do a Chatter post, which also kind of does the bell notification and email at the same time, but that gives us a record on the record. You know what I'm trying to say.

Mike Gerholdt: Yeah, a receipt.

Christina Nava: Yeah, there we go. We can actually say that, "Hey, we did notify you." We can look back a year later and actually see all of that happening. So that's one I use quite a bit. And then the fourth one that we don't use a lot of, but we do somewhat is Slack notifications because we are a Slack shop as well.

Mike Gerholdt: Oh. How do you decide between those?

Christina Nava: I let the user decide. I basically say, "Hey, here are the fourth things we can do." There have been times I've pushed back on, "You're getting a lot of emails, are you sure this is what you want?" And I get told, "Yep, absolutely." Like, okay.

Mike Gerholdt: Me too. And I've been told that before. I just like, sometimes you sit down and you do that worst case scenario with people and you're like, "You know, there's 50 contracts that could come through and times two steps. That's a hundred emails I might send you in a day."

Christina Nava: And half the time I'll get, "Yep, because my inbox is my to-do list." I'm like, "Really"?

Mike Gerholdt: I know. Yeah. But to your point, when you or they get promoted, then that inbox now becomes a grave because now there's no to-do list and we got to pull that from somewhere. So I like the posting to Chatter or something as kind of a receipt for what needs to get done. I'll end on this one question, which is fairly simple. If a user is feeling intimidated with flow, where would you suggest they get started?

Christina Nava: So if they've never ever seen flows before, first place is obviously going to be Trailhead. Go through the trails, build your own. But if you have a little bit of experience, you've done that and you're in your own org and you need to build something, the first thing I'm going to say is write out the steps I talked about. Actually write down, "Go to the account record, then click on this field, edit" step by step exactly what you need to do and then go to flow and try to build it that way, and then build the bare minimum first. Pull up, do your GI account, do your debug, did it work? Then do your next step. Update your account. Do your debug, did it work? Do step-by-step, debug it because if you try to build out 20 steps and then you debug it and then it fails, you're going to get very confused and you're going to get very frustrated and you might want to quit. If you do it piece by piece, not only can you debug smaller bits, but you're going to feel the satisfaction of the win each time it works and it's going to build your confidence.

Mike Gerholdt: No, I like that. That completely makes sense. I've certainly gotten not too deep into flows, but far enough that I wish I would've done the little bites at a time kind of situation and just testing to make sure it works. It also feels good. I mean, you don't have to sit for weeks building a flow and then pressing the button and being like, "huh." It feels good if you spend 10, 15 minutes and then you click something, it populates the field. You're like, "Yes."

Christina Nava: Exactly. Never forget the power of debugging. If this is a record triggered flow and you can't figure out what's going on because you can't put up a debug screen, write a debug to your description field. Create a temporary text field that you can write information to. Don't forget those little tricks when you're debugging.

Mike Gerholdt: Right? Oh, there's always a ton. Christina, thanks for coming by the podcast to help me understand sub flows and flows and decisioning.

Christina Nava: Absolutely. Very happy to be here.

Mike Gerholdt: I appreciate that. And we will link to the Automate This in the blog post below.

Christina Nava: Sounds great.

Mike Gerholdt: It was a great conversation with Christina. I had a lot of questions because I've been building some flows like you and I've been wanting to reuse things, and I really just need to know how people's heads work sometime, and she's really dialed in with some of the stuff that she's doing with flows and decisioning stuff. I think it's really cool. So I hope you enjoyed this episode, and if you did, could you do me a favor? Real simple, could you share it with somebody? Now, if you're listening on iTunes, all you have to do is click on the three dots and click share episode. Then you can post it social, or you can text it to a friend. Maybe you've got a friend that's building a flow and you'd be like, "Hey, listen to Christina. She's got it going on. She can help you build things." And of course, if you're looking for more great resources, your one stop for everything admin is admin.salesforce.com, including a transcript of the show. And be sure to join the Conversation Admin Trailblazer Group that is in the Trailblazer community. Link is over in the show notes. I know there's some flow questions in there. So until next week, we'll see you in the cloud.