Today on the Salesforce Admins Podcast, we talk to Melissa Shepard, Salesforce Certified Architect and CEO of Lizztech Consulting. Join us as we chat about how to approach automations in your org and why asynchronous processes are so powerful.
You should subscribe for the full episode, but here are a few takeaways from our conversation with Melissa Shepard.
Melissa started as a Salesforce Developer, working on integrating Salesforce with some of the other systems her org was using. “I like to think of integration as a backbone for the bigger, more robust automations that you can build,” she says. And if you think about it, bringing in data to Salesforce and sending it out to other platforms is at the core of what you’re trying to do with automations.
In the first phase of a project, Melissa recommends getting a firm grasp on what you’re trying to accomplish. Those simple questions are so important: what is the process? What is the end goal? “It’s not even thinking about the technology but understanding what’s the problem you’re trying to solve, first,” she says, “and then you decide how you’re going to solve that problem with the technology.”
When you’re coming into an org that’s been around for a while, Melissa recommends getting a good lay of the land. Understand how everything was built and why it was built that way. If you’re missing documentation, make sure to do that as you go to make things easier later.
You should especially be on the hunt for processes that are similar but with slight variations. Sometimes you can really simplify things by turning that into one flow with multiple paths. And if you come across something that’s being used multiple times, it could be a good candidate to break out into a subflow.
“You can do so much in Flow nowadays that you could do with Apex,” Melissa says, with looping, updating records, and doing things in batches. And there are some great tools like Orchestrator and MuleSoft Composer that make integrations easier than ever before.
Melissa feels that asynchronous automation is one of the most overlooked features in Flow. You can get a lot of benefits from running a process outside of normal operating hours, including more processing power and better performance for your users. She actually has a presentation coming up on this very topic, so if you’re interested in learning more you should catch her talk.
Melissa will be appearing on “Automate This!” with Jennifer Lee later in April, so be sure to tune in for more about how your automations can be well-architected.
Mike: Welcome to the Salesforce Admins Podcast. We talk about product, community, and career to help you become an awesome admin. And this week we’re talking with Melissa Shepherd, who is a Salesforce CTA and CEO of Liz Tech Consulting. Well, you know about Well Architected automation. If you haven’t picked up, we’ve got a little bit of a theme going. These last few episodes, we’ve talked last week with Tom Letty about Well Architected automation, talked about some new Trailhead classes around Flow and hyperflow. And coming up, boy, there is some really good stuff coming later in April and early May around cool Flow solutions and some omnichannel stuff. So I’ll just tease that out. But of course, Melissa is also going to be on the Automate this series, which is Jennifer Lee’s YouTube series, so be sure to check that out. I’ll also post a link to it. We get her on the podcast first, so by the time you get to watch her on the video, you’ve already seen a podcast star, but enough of me talking, let’s talk automation and some really cool stuff with Melissa. So let’s get Melissa on the podcast.
So Melissa, welcome to the podcast.
Melissa: Thank you.
Mike: We’re talking a lot about automation and I think it’s appropriate to have you on. But before we head into that, give us a little bit of a backstory. How did Melissa come to Salesforce and join the Trailblazer ecosystem?
Melissa: Well, thank you for asking. That’s an interesting story. I actually just wrote a really long blog post about all that because a lot of people don’t know my journey or where I came from. It actually started back in 2006. So I was a developer and I was brought into the IT department of a small but kind of startup company to help build some customer and partner portals in .net to interface with Salesforce and also do some other customizations written in .net. And one of the systems I had to work with was Salesforce, so I had to build these portals and also I saw an opportunity to integrate Salesforce with our other systems to help the users not have to do double entry to help alleviate errors with information they were entering into the system.
So this is actually a form of automation. I like to think of integration as a backbone for some bigger, more robust automations that you can build. So that was how I was introduced to Salesforce. And I really loved working with it and decided to keep working in that space and ended up at an integration middleware company working on the Salesforce adapter and the core software. It was written in multiple languages, so I was still in that development role, but still touching Salesforce. And then when I left there, I just went off and did Salesforce consulting around 2009, 2010. And that’s what I’ve been doing ever since.
Mike: Wow. I think you’re the first person I’ve had on the podcast that has been doing Salesforce since ’06, like me.
Melissa: Oh wow.
Mike: Yeah, you said ’06. I was like, oh, do you remember those days of page builder where you used to have to select and then select where the component went and it wasn’t wizzy wick and it took you hours to do the simplest thing?
Melissa: Yeah. And I also remember not having sandboxes, and then when we finally did have sandboxes, we had to build things in the sandboxes and then rebuild them all in production.
Mike: Yeah, I get a lot of grief for that when I talk to people and tell them. Early days, I would build things two or three times. Why? I mean, I remember chain sets coming out and thinking, oh cool, I’m so used to just building and rebuilding things now that I think I might be faster.
Melissa:Yep.
Mike: Oh, interesting. So I think you’re so spot on that integration is really a form of automation. A lot of the podcast that I’ve had recently where I’ve spoken with people, we’ve always talked about automation just within Salesforce and broadening that even bigger to automation outside of Salesforce, just bringing in data from another system as a way to do that, yeah, I’m on board with that.
Melissa:Or pushing it out to another system. So instead of user having to enter something in Salesforce and then going and enter that in the other system, your backend integration’s going to push it from Salesforce to that other system. And that’s an automation,
Mike: Right. A 100%. I mean a lot of it is, how do we get things just done in Salesforce, but it’s also what are the other systems that people live in? So yeah.
Melissa:Someone that’s in an architect role, a CTA role like me, we care about that. We care about the other systems that interact with Salesforce and how all these automations within Salesforce are affecting these other systems or the data that’s coming into Salesforce are going out and not just on platform.
Mike: So tell me and help everyone think, when you sit down with somebody, where does your mind go for automation in terms of planning, even just your first app or the first phase of a project?
Melissa: So I always like to understand what it is they’re trying to accomplish. So it always starts with the user. The user usually needs to do something. So having an understanding of what it is they’re trying to accomplish, what is the process, what is it that they need to get to? What’s that end goal? Or sometimes it isn’t user, usually it is, but sometimes it isn’t. Like I said, sometimes it could be that backend process that’s performing some sort of automation behind the scenes and that could be done with things like Flow or code. So it’s not even thinking about the technology, but understanding what’s the problem you’re trying to solve first and then you then decide how you’re going to solve that problem with the technology.
Mike: Yeah. So step two, and one of the things that I asked Tom was I think it’s very easy once you have apps built and you kind of have things going to jump into Flow and create these little one-off Flows. You mentioned as an architect, I’ll dive deeper into that. As an architect, how do you resist that urge to keep adding rooms or keep adding closets to a house and really thinking methodically about how you build that automation solution?
Melissa: So understanding what you already have built is a huge part of that and where you need to maybe add on or modify. So instead of just adding something new, you have to understand the house that’s already built and maybe there’s something you can already use and just modify it a little bit or take advantage of something that’s already existing. So sometimes you’re not always the architect that built that house, so you have to gain an understanding of how it was built. I actually just went through this before talking to you how I like to sit down and understand current state. So what’s the process? What are the processes like now? What do they look like and what supports those processes? And is it in flow, is it in Apex? Are there triggers? What is going on behind the scenes and what was built to understand what’s there? And sometimes there’s documentation, sometimes there isn’t. If there isn’t, then it’s a good idea to document all that because then you have that to refer back to when you do need to go and add in new functionality or make changes. And that’s the best practice.
Mike: Oh man, I would love to see documentation everywhere and unfortunately it’s kind of like when you go on a road trip, you forget how you got there ’cause you were in such a hurry to get somewhere.
Melissa: Exactly.
Mike: You mentioned processes and kind of getting an idea of current state. I think a lot of people right now are trying to get an idea of current state because they really want to migrate off of process builder and into Flow. As an admin or developer architect looking at current state, what are places that you look at that maybe are the first stop because they’re over automated or they have overly too many things that could really be migrated into a simple Flow?
Melissa: Yeah, that’s a good question. So it is those areas of process builder and current flows where you want to look at how you can maybe combine things together. So looking at things that are similar processes, but maybe some slight variations. I’ve actually had to do this exercise before in an org merged scenario. So multiple orgs getting merged into one, lots of automation built in each org that was very similar. So there was an exercise of going through everything and understanding the logic. So this was actually workflow and process builder that I was analyzing, understanding what each one was doing, the processes that were happening and then seeing where everything could be combined, but where there was just some slight variations, then you would have different paths to take within your Flow.
Mike: Yeah, I think oftentimes there’s so many paths that cover over, I’d be curious. I mean anecdotally, I’m sure you run into this a lot where you find processes that update processes that have other processes that re-update them.
Melissa: Yeah. You have to be careful with that too, right? Because you’re in an infinite loop of updates. So yeah, definitely. You’ve got to be careful there and I always like to look at things that are very similar and then where it makes sense to break something out into a subflow, something that’s maybe being used over and over multiple times, that is a good candidate to go into a subflow.
Mike: I was just about to ask you, how often do you use subflows?
Melissa: Yeah, where it makes sense.
Mike: Where it makes sense.
Melissa: It’s actually the same concept as development in Apex. So you have things like functions that get called for different purposes and you put them in maybe helper classes. So they get called by all kinds of different code. So when you see something that is getting reused, you want to push that out into your helper class that can then support your other code. So that’s the same idea as a subflow.
Mike: Oh, I like that. Subflow is like a helper class.
Melissa: Right? Exactly.
Mike: I had a lot of fun discussions at TDX and I’m sure you’ve had a lot of fun discussions maybe even just today. How often should somebody go back and revisit Flows or processes that they built in order to make sure that they actually reflect the way that the business does business?
Melissa: That’s actually a good question. That’s going to depend on how often the processes within the business change. So if a business has processes that stay pretty much the same, I couldn’t see that as being something that’s really critical. But if it’s a business that’s growing and changing and their processes are changing or they’re acquiring other businesses, you absolutely need to go in and look at those processes. So mergers and acquisitions, that’s something that at a more higher level, global level that someone like a CTA is caring about. We care about how these mergers and acquisitions are affecting current business process and how it’s affecting the current technology within Salesforce and also in the entire enterprise. So those are the scenarios where you’re going to really need to go back and evaluate current processes against newer processes that are coming in. I’ve had to do that to support organizations that were merging together, their processes were different, had to really go in and look at everything, what can be merged together, what needs to be separate, and just understand how that all can live within the same system.
So yeah, I guess it’s going to depend on the business. The business is going to drive that.
Mike: Yeah, understandably. And hopefully the business keeps you up to date.
Melissa:Right.
Mike: So I’ve had that as an admin too where three months later you’re looking at something like, we don’t do things that way anymore. Since when? Since you have told me?
Melissa: Right, exactly. Yeah, and that’s interesting. So I think that’s where the admin still has to play that role of advisor as well. When the business is not telling you things, you get to be more liaison with the business, have a point of contact that you can go to, maybe sit down or review things with. As companies grow and get bigger, they create these centers of excellence that are overseeing these types of things. But when you’re just in a lonely admin at a company, you don’t have that kind of structure in place, you kind of get to play that role yourself.
Mike: Yeah. You have to be a thorn in their side. That’s the way I always looked at it
Melissa: Yeah. And play that role of advisor. So maybe instead of waiting for them to come to you, maybe trying to find out what’s going on or things changing, how are things going and how are the processes working for you and just check-ins.
Mike: Okay, so in looking at Flows and a business process changes, at what point do you think I need to modify and add on and build a more complex Flow or should I build a new Flow?
Melissa: I would say if the process is very different. So you look at the current process you’re building for and the existing processes that are covered in your existing Flows, and a way that I like to do that is having process diagrams. So there are tools out there that can help you create those process diagrams so that you can understand your current business process that you don’t have to go through and understand every single detail of the flow. And really understand what they’re all doing so that you can decide if one of them is similar enough to what you’re building for. If there’s enough, and it’s hard to really pinpoint that point where it’s enough. So I always like to say if you see at least a few similarities in something, then maybe that’s a good candidate to build off of. If there’s not enough, it also depends on how big it is too. So that’s a hard question.
Mike: Well, and a lot of times there’s no right answer, right? I mean, for sure I’ve looked at Flows and thought we could add on to this, but at what point is it going to be so incredibly hard to troubleshoot and to debug?
Melissa: Yeah, exactly. And got to look at, am I going to make this one Flow too complicated? Does it make sense to just put this new process into its own Flow? Is it small enough to where it’s just a slight variation and it’s similar enough that it’s not going to overcomplicate. So I’ll just add on and modify the current one. So that really does take some analysis. Like you said, there’s no right or wrong answer there.
Mike: Yeah, because if you’ve been working in Salesforce since ’06, you remember workflows and how little we could do with those, but it still felt like a lot.
Melissa:Right.
Mike: And then we went to Process Builder, which was like an animated process diagram and now we’re in the new Flow builder. What about Flow now for you is the most exciting?
Melissa:I would say the fact that you can do so much in Flow that you can do with Apex nowadays, that’s exciting.
Mike: Such as?
Melissa: Just some of the logic that you can build in and then you can even call invocable actions in Apex. So if there is something that some complex logic that you need to run that you just can’t build and flow, you can then just call your Apex there. But just a lot of the things you can do like looping and getting records and updating records and doing stuff in batch. And there’s just so much power in the Flow now as opposed to what you could do with Workflow or Process Builder that you don’t need to just go to Apex to do some of these more complex business processes and error handling and things like that. You can even build tests for your flows, which is great. So it’s a little bit more like building tests for your code.
Mike: Because we started talking about integration and then we got off that a little bit. What is some of the biggest stuff that you are excited about looking at? We now have Orchestrator as an option.
Melissa: So yeah, there are some great tools like Orchestrator, MuleSoft Composer that are helping to build an integration. So a couple of the things that are exciting with Flow is there’s HTTP callouts, so you can make direct callouts to endpoints from within Flow. There’s external services, that’s another way you can integrate. There’s also platform events. So you can create platform events with Flow or not create them, but write records into your platform event, which can then be subscribed to you by something like MuleSoft. There’s so much integration capability out of the box now within Salesforce. And because there is a lot, you want to understand which one you would want to use for each of the different types of use cases. What’s a fire and forget versus what’s a request and reply? And those are patterns that architects really care about. So you have certain use cases for certain patterns and then you have the technology that you want to use that’s the best solution for each of those patterns.
Mike: Two questions as we wrap up both ends of the spectrum. I think the first one, it’s very fortunate for people, the longer they’re around the technology, the more they see it evolve, the easier it is to kind of grasp the concept. But for you in understanding Flow, what was the one hook that made everything click?
Melissa: So I really got into it when I had to build a custom process off of opportunities to interface with Field Service Lightning. And I can say really got hooked because I had to build this custom process and it just made it so easy to build it and get it done, didn’t have to go to code. It made it so fast to get it done and delivered the functionality that was expected and needed.
Mike: So conversely, thing that got you hooked, what do you find or what do you think is the most overlooked feature in Flow?
Melissa: Now? You can do things synchronously and asynchronously within the same flow and maybe the asynchronous stuff is probably the stuff that’s most overlooked. And I actually speak on asynchronous automation specifically, and I actually have a presentation that I’m going to do specifically on all the ways you can automate asynchronously with Flow. Because that’s even something that’s not well understood and there’s different ways to do it. And being able to understand when you’d want to use one versus the other I think is very powerful. So that probably is an area that is overlooked and not well understood as to when and why you would want to use it.
Mike: Yeah, I mean, without seeing your presentation completely understand, I mean I think with Flow we think of how do we make something happen right now? When this either record happens or field changes or something, how does it happen right now as opposed to not right now? I guess is the easiest way to put it.
Melissa: That doesn’t have to always be instant gratification in something that you learn as you grow as an architect is you really like to take advantage of asynchronous processing. There’s reasons for it. You get more power out of the platform, you can allow more for your users so you’re not tying up resources for them to get their jobs done. So where I was going with this is now we’re talking about Salesforce Well Architected and Well Architected is telling you that you really want to try to use asynchronous processing as much as possible.
Synchronous when you absolutely have to, and there’s certain times when you have to use synchronous, but there’s also certain times when you have to go asynchronous and there’s ways you can do that with Flow. So that’s an exciting area and that’s where I like to start talking about what are these well-architected concepts, how can we start applying them? What are the different ways we can build them into our automations? And that that’s actually one of my presentations I actually did at Dreamforce, asynchronous automations presentation. I do that at some community events and like I said, I’m also going to be doing one specifically on how to go asynchronous with Flow.
Mike: And we talked a lot last week with Tom Letty about Well Architected. So I’ll be sure to put a link to the previous week’s podcast, keep people listening in the show notes so they can listen to that.
Melissa: I think admins should get to know Well Architected as much as they can because it’s just going to help them become better admins and grow into architect level if they so wish.
Mike: Absolutely. In fact, we’ve had calls with that team because the goal is to build the best possible application, right? And fun fact, in May I have Gorav, Seth and Eric Smith on about their Flow solutions. And Gorav has a very similar one where it was actually a reporting thing that we talk about because we don’t need that constant… I’m sure you’ve heard or been across the table from some sales manager that had to get an email every time an opportunity closes. And it’s like you don’t want 600 emails. That doesn’t help. You really want one email that’s summarized of the hundred top opportunities and you don’t get that by firing off an email every single day or every single time. Exactly.
Melissa: Yeah, that becomes more noise. And then you can even take advantage of things like notifications as well within the platform if you don’t want to get too many emails.
Mike: Right, yes, exactly.
Melissa: Which can then have your records.
Mike: So I’ll end on this question for you, Melissa. If an admin or anybody listening is ready to get into automation, and this is similar to a question I ask Gorav and Eric, what should be the first thing they should look at?
Melissa: As far as to how to automate?
Mike: I leave that very open for a reason because I think it’s important to understand businesses definitely need to automate processes and there’s automation in Salesforce and as we’ve talked, integration is also automation. But it’s one thing to build an app, I think it’s the next thing and take that app to the next level and start adding automation to it. Where did you start?
Melissa: Usually you look at where pain points are for your users, where maybe they’re doing things multiple times or there’s repetitive tasks. If you can bring value to your users and your business, that’s where you want to look and that’s where you want to start trying to build an automation. So you really want to understand those processes, look at where you can alleviate some issues in the process and then figure out the right technology to bring in, whether it’s Flow or something else that’s going to be developed like Batch Apex or something because you can automate with Apex as well. It’s not always just Flow. Sometimes there’s better use cases for going to something like that, but Flow is such a powerful tool like we’ve talked about that you just really need to understand the process to know which tool to use, if that makes sense.
Mike: It absolutely makes sense. And thank you so much Melissa for spending time with us today. I appreciate you coming on the podcast.
Melissa: Yeah, no problem. Thank you for having me. Really enjoyed our discussion.
Mike: And of course, we appreciate Melissa taking time out of her day to talk through Well Architected Automation. Only took me an entire episode to get that out verbatim, but boy, it has been a trip. Talk and flow these last few episodes and automation. I hope you enjoy it. It’s more to come. And of course, if you want to learn more about all things Salesforce admin, go to admin.salesforce.com to find more resources, including any of the links that we mentioned in this episode, as well as a full transcript. Now you can stay up to date with us on social, we are at Salesforceadmins no I on Twitter, my co-host Jillian is on Twitter. She is at JillianKBruce. And of course I’m on Twitter as well. I am at MikeGeralt. So with that, stay safe, stay awesome, and stay tuned for the next episode. We’ll see you in the cloud.
Today on the Salesforce Admins Podcast, we talk to Lynn Guyer, Manager, Salesforce Practice at Forefront Telecare. Join us as we chat about how she was able to build a no-code, out-of-the-box solution for one of her organization’s biggest operational challenges. You should subscribe for the full episode, but here are a few takeaways from […]
On this episode of the Salesforce Admins Podcast, we’re featuring a conversation with LeeAnne Rimel and Farhan Tahir, VP of Product Management at Salesforce. We discuss the key product features that help you put design features into action. Join us as we talk about the future of declarative app-building on the platform, and what’s coming […]
On this episode of the Salesforce Admins Podcast, we’ve got Sarah Pilzer, Director of Operations at Country Dance and Song Society and Golden Hoodie winner. She tells us how she uses automation to serve her users. Join us as we talk about why it’s always best to start with standard functionality, how to borrow from […]
