Salesforce Admins Podcast

Today on the Salesforce Admins Podcast, we talk to Brandon Van Galder, Technical Consultant at Arkus, Inc.


Join us as we talk about his tips for getting started with Flow, how omni-channel automation solved a big problem for him, and his tips for breaking into a Salesforce career.


You should subscribe for the full episode, but here are a few takeaways from our conversation with Brandon Van Galder.

Tips for your first Salesforce interview

Before Brandon had ever heard about Salesforce, he was an elementary school PE teacher. When he was feeling burnt out and looking for new opportunities, he happened to hear about Trailhead and the Salesforce Admin role and pretty soon, he was off to the races. He spent about a year as an admin and is now currently a technical consultant with Arkus, Inc.


Going from doing a bunch of online training to sitting in an interview and proving that you have the skills to actually be an admin is a big step, and one that many people struggle with. “I would recommend building a custom app in Salesforce,” Brandon says, “find something in your personal life that you can potentially track in Salesforce and build some automations, and then you can talk about that in your interview.” For example, Brandon built a mileage tracker to help him with training for a 5K race.

Mastering the learning curve for flows

Brandon will be appearing on Jennifer Lee’s Automate This! YouTube channel soon to talk about omni-channel automation. “When I first was learning, I was deathly afraid of flows,” he says, “but now I can’t look back, I can barely even use Process Builder after being a Flownatic for the last year or so.”


One important thing to keep in mind as you get into flows is that you’re going to get better at it as you go. When Brandon first started, he was trying to send email notifications with flows and it took him about eight hours to get everything working correctly. These days, he can build the same sort of thing and fully test it in a single hour.

Why you should always read the release notes

Brandon had chats coming in from three different sources and a lot of them were getting missed, especially around shift changes. They really needed to know who was online and when. And it just so happened that Salesforce had recently added custom components that could get the availability of agents. It just goes to show that it’s worth it to keep up-to-date on the release notes!


You can learn more about how Brandon solved his problem with automation on Automate This!. And make sure to listen to the full episode to hear his tips for getting started with flows, what to look out for when you’re implementing automation, and more.


Podcast swag

Learn more:


Full Transcript

Mike Gerholdt:  Welcome to the Salesforce Admins podcast. We talk about product, community, and career to help you become an awesome admin. And this week we are talking to Brandon Van Galder, who is a technical consultant at Arkus, but previously a Salesforce Admin and staying on that theme of automation, little bit of omnichannel, little bit of career switching in this. So it's like a chopped salad. There's a lot of little bit of everything in it. That's what I'm going to call this. With that, let's get Brandon on the podcast. So Brandon, welcome to the podcast.

Brandon Van Gal...:Hey Mike. Thanks for having me.

Mike Gerholdt:  Let's get started. For those that don't know who Brandon is, tell me a little bit about Brandon and how Brandon got into the Salesforce ecosystem.

Brandon Van Gal...:Well, that's a good story. I'll start. Before I even knew what Salesforce was, I was a teacher and I actually taught elementary PE for most of my career. And then just got burnt out and I heard a podcast where they talked about becoming a Salesforce Admin and how you can make pretty good money, and the training for that was pretty simple, and they had this thing called Trailhead and just signed up for Trailhead after listening to that and fell in love with it immediately because I love badges and points. Fast forward two years later, still teaching. I landed my first role as a Salesforce Admin at a company called Scale Computing, and I worked there for a little over a year, and now I am currently a technical consultant with Arkus, Inc.

Mike Gerholdt:  Wow. Okay. Was it my podcast? You could say it's my podcast. If not, that's okay.

Brandon Van Gal...:It was not. It was the ChooseFI Podcast.

Mike Gerholdt:  Darn it. Okay, that's fine. I'm going to listen to that now. So that PE, we're going to have to talk about that at the end of the show. You realize that because I think Foursquares should make a comeback because that was a huge PE game for me, but spending that time starting off as a career change before we jump into all the flow stuff, because I know that's what people want too. What was the learning for you moving from being an educator to getting that first Salesforce job? Was this nights and weekends you were just one or two modules or here or there, or was this very deliberate? You set a goal of within two years, I'm going to be out of education. What was that time period for you?

Brandon Van Gal...:It was semi deliberate. I did have a two year plan where I did use nights and weekends and more during spring break, fall break, Christmas break, and especially summer break. I would get a lot of my learning done then, and then transitioning into the business world quite different than the education world. I had to learn that at my first role as well. Just the nuances of business and how it differed from education and that first role was a great learning experience. I landed with a great team. Shout outs to Kelly and Rebecca, if you're hearing this, thanks for all the healthy [inaudible].

Mike Gerholdt:  Of course they are.

Brandon Van Gal...:They really took me under their wings and showed me how to do things.

Mike Gerholdt:  So I get a lot of questions and I'm spending a lot of time on this. I get a lot of questions like, man, that had to have been a hard interview because you're sitting across the table from somebody and you're like, look, I've just done a whole bunch of stuff online. What was the contributing factor or what was one piece of advice you'd give new admins that are looking to make that career change and going through that path into landing that first job?

Brandon Van Gal...:I would recommend building a custom app in Salesforce. I built out a mileage tracker app for running. I did it during COVID and I started training for a 5K, so it aligned with what I was doing in my personal life. So you can just find something in your personal life that you could potentially track in Salesforce and build it. Built out some automations and then you have that you can demonstrate during your interview and talk about and share your experiences of what you did on the platform.

Mike Gerholdt:  I like that. I've done that quite a bit actually in some of the stuff. So you mentioned automation. Let's get into that because I know on Jennifer's automate this episode, you are going to talk about omnichannel, which is very specific. I will say very specific because we've had a lot of her guests on the podcast, but what got you into automating with omnichannel and doing some of that?

Brandon Van Gal...:Yeah. Well, when I first was learning, I was deathly afraid of flows. I was like process builder all the way. I'm going to ride this till it dies, and now Salesforce is basically not supporting it as much anymore. So had to learn pretty quick how to do flows and now I can't look back. I can barely even use Process Builder and look at it and debug it anymore. Trying to figure it out. It just doesn't make sense to me after being flown addict for the past year or so, and then specifically omnichannel at my role in scale computing, we had chats coming in from three different places and a lot of them were getting missed. Hence, the deep dive into omnichannel flows.

Mike Gerholdt:  What was the hook? What made things click? And I asked this because I know I've done a previous podcast with Eric Smith and Gworth and they said, "Start with screen flows," and screen flows are a great way to get your teeth into flow. Was the screen flows that got you or was it something else?

Brandon Van Gal...:For me, it was more sending email notifications using flows just because that's what I was doing in the business and I know you can do it just with email alerts, with workflows and things like that, but we had some unique use cases where we couldn't use flows for that. I mean the first time I built it probably took me eight hours to do one, and then as I got better, I could whip one out in less than an hour, completely tested. And just seeing that learning curve speed up is really helpful and encouraging to myself to use it more.

Mike Gerholdt:  Yeah. What is one area when you're sitting down with a business, and this can be in your previous job as an admin or your current job as a consultant. What are some of the key words that you feel other admins should listen for when determining how much or where to add automation?

Brandon Van Gal...:When someone says, 'We do this all the time and manually," that's a good spot to look for. In some cases you can't automate it, but in a lot of cases you can just with the power of Salesforce. So that's what I look out for when asking questions to clients and business units.

Mike Gerholdt:  So then conversely, because we love to automate all the things, what are red flags that you listen for as well when you're like, I could do this, but it means you're going to get 500 emails

Brandon Van Gal...:When they say, I want to email every time, If you hear the word every time or on every status update or something like that, that is definitely a red flag where you can say, "Hey, let's pump the brakes here." Maybe having a report that shows these and then it gets emailed out once a day or once a week would be a little bit better than getting 500 email alerts in one day.

Mike Gerholdt:  Yeah, no, that makes sense. Are there, because I'm always noodling around in an org, creating stuff. As you look at flows and flows that you've created in the past, are you now seeing just having done this for a while, ways to combine flows together or ways to minimize the number of flows that you're creating?

Brandon Van Gal...:Yeah, absolutely. Early on, I'd never used the invocable flows, but recently I've been using that more where I create at least one section of that flow and can reuse it in multiple different flows, being triggered by different actions. That's been huge. And then I've also used the save as a new flow where instead of having to rebuild it from scratch, you can save a previous flow as a new one and then make whatever minor changes you need off of that, where maybe the decisions might be a little different or the loops might be a little different. Yeah. So I've used those two things.

Mike Gerholdt:  Yeah, no, that makes sense. I know because I'm just looking through at different flows that I've created and sometimes it's so easy and tempting to click that, create new button and you forget all the other stuff that you've added into an org. A little bit back on omnichannel, I think before we pressed record, you were talking about how that got started. Where was some of the omnichannel work that you did and how did that inspire you for automation?

Brandon Van Gal...:At scale computing, we had chat capabilities come in from three different websites, one being like the company's main website, one being the community user portal, and then one being the partner portal. And what was happening is usually during the tier one support agent meeting, they would all log off and then any of the chats that were routed to the tier one agents were being missed. And it just happened to be during that 30 minute window that helped us figure out what to do from there.

Mike Gerholdt:  Yeah. It never fails. It's always right during the shift change or something when everybody presses the little chat button on your site. So thinking through just, you are a school teacher, you moved into the ecosystem, what now do you do to just outside of the daily work to keep up to date with skills, with new features of flow? How do you plan that out?

Brandon Van Gal...:I read the release notes specifically towards flow automation. That's one of the loves. I skip over some of the other stuff I don't necessarily work with every day, but I like to see that. And that came in handy when we were building out this omnichannel flow. We were manually trying to get the availability of the agents and then all of a sudden in the next release, Salesforce had these custom components where you could get the availability of all the agents in a specific queue. And that was really helpful. And knowing that's coming down the pipeline really helps you sustain on top of those. Looking at Trailhead when they update those or make new trails is a good way to stay on top of it too, because it includes that new functionality and then watching some YouTube videos that come out every once in a while via it, Jen's automate this or how I solved it, you see how other people solve issues instead of being just stuck in your own mind, you can see how other people think about flows and use them to solve problems.

Mike Gerholdt:  Yeah, no, that's great. As you build and possibly rebuild flows, what advice would you give on some best practices that you do for user adoption or people really understanding, here's the implication of clicking this button or what this means.

Brandon Van Gal...:Documentation is huge and screen recordings of the steps that are triggering the flow or what happens when you click the button are huge. In my current work now, we record videos and then share them with the clients at times so they can see, hey, when I update this status, something's happening in the background, but this is what it looks like on the front end so they can see the changes that were made.

Mike Gerholdt:  No, that makes sense. Especially with stuff when it's going to just trigger because the record was saved. I think behind the scenes maybe sometimes a user doesn't always know everything else that cascades out as a result of that. So that's good to know. What part of flow and automation is a little bit, lack of a better term here be dragons for you. It's a little unknown. You need to learn it, but it's still off in the distance.

Brandon Van Gal...:I'd say some of those newer components that I just haven't touched yet because I haven't had the business use case to use. And then when you open your mind to everything on the app exchange, what's available out there, be it from unofficial Salesforce, they have some great flow components that I just haven't used, but I've seen in other people's flows. Just trying to wrap my head around what is possible. I think I'm 25% level right now of knowing what flow can do. I feel there's so much more out there that I just don't even understand or comprehend at this point.

Mike Gerholdt:  I don't know if anybody's at 100%.

Brandon Van Gal...:Yeah. There's a lot of things with outbound messages or platform events, things like that that I just haven't touched that I still need to learn about because those are pretty powerful as well.

Mike Gerholdt:  So I asked this on previous pod because I know we'd done a blog post that was probably, Jennifer did a blog post on this, but how often do you find yourself using subflows?

Brandon Van Gal...:I do it on rare occasions. There's one client I'm currently working with where I did use it where it ranks records based on their score. So if a record is created or updated, I can call it, if a record is deleted, I could call a subflow. That ranks everything. So a couple of different use cases personally that I've done. It's just not something I've had to use that often.

Mike Gerholdt:  Yeah, absolutely. Moving into the world of teaching, did you have a favorite PE activity?

Brandon Van Gal...:Absolutely. I was a dodge-ball fan.

Mike Gerholdt:  You call that dodge-ball in schools?

Brandon Van Gal...:You just call it throwing and catching skills and then it's okay. And I'm not big on having the kids sit out for a long time.

Mike Gerholdt:  They would have to catch your way back in.

Brandon Van Gal...:Do some exercise or whatever to come back in the game and keep it like a nonstop because if you keep it nonstop, then they're having fun.

Mike Gerholdt:  Do you ever do the dodge-ball with... We used to put these boxes in the back of the gym and so in addition to getting all the people out, you also had to knock the boxes down.

Brandon Van Gal...:Yeah. We had you use cones or bowling pins on the back. We'd call it pinball bombardment, but same thing, dodge-ball rules, but the real objective for the game was knock down the pins. If you do that type of thing.

Mike Gerholdt:  You win. You get the whole thing. Yeah. Even if nobody's out, you can knock both pit. We did that. Yeah. Of course, immediately when somebody says dodge-ball, I go right to the movie Dodge Ball.

Brandon Van Gal...:It's classic.

Mike Gerholdt:  Yeah. Well, this is great. I feel like we delved into some automation and even touched on little career stuff as well. For people looking to make that switch to go from A to B, whatever A is to either getting into consulting or looking at an admin or consulting job, what was one thing that kept you going?

Brandon Van Gal...:I just really fell in love with Salesforce. Once I started digging in. I didn't know what it was when I heard the podcast, I'd listened to the podcast twice, Google what it was, look at what Trailhead was I had, I didn't know what a CRM was when I first started, but I'd say, "Yeah, just give it a try." Jump on Trailhead, do a couple of modules, and then if you feel that itch and you like it, just keep going because there's a position out there for you.

Mike Gerholdt:  Yeah. No, that's great. And then ball house fails, we can always get a game of dodge-ball together.

Brandon Van Gal...:That's right.

Mike Gerholdt:  Awesome. Brandon, thank you so much for being on the podcast.

Brandon Van Gal...:Yeah, thanks for having me, Mike.

Mike Gerholdt:  So it's fun to have Brandon on the podcast and talk about automation and the way he approaches things. And also it was learning journey. I couldn't help but dive into that. And it wouldn't be the Salesforce admins podcast if we didn't talk about something fun like dodge-ball or Foursquare. Did you have a favorite game while you were in school? I like foursquare. But I'd love to hear it. So send me a tweet, let me know. Also, if you still play that game, good for you because I would love to mark out some chalk on my driveway and get a Foursquare game going. But anyway, I digress.
 If you want to learn more about all things Salesforce Admin, go to to find more resources, including any of the links that we mentioned in this episode as well as a full transcript. You can stay up to date with us on social. We are @Salesforce.Admns on Twitter. Gillian, my co-host is on Twitter. She is @GillianKBruce. And of course I am at Mike Gerholdt. So with that stay safe, stay awesome, and stay tuned for the next episode. We'll see you in the cloud.

Direct download: Brandon_Van_Galder_on_Automated_Omni-Channel_Routing.mp3
Category:general -- posted at: 3:00am PDT

Today on the Salesforce Admins Podcast, we talk to Melissa Shepard, Salesforce CTA and CEO of Lizztech Consulting.


Join us as we talk 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.

Simple questions for automations

Melissa started as a Salesforce Developer, working on integrating Salesforce with some of the other systems they were 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 to rebuild

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.

Asynchronous automation

“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.


Podcast swag

Learn more:


Full Transcript

 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.


 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.


 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.


 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.


 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 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 Gillian is on Twitter. She is at GillianKBruce. And of course I'm on Twitter as well. I am at MikeGerholdt. So with that, stay safe, stay awesome, and stay tuned for the next episode. We'll see you in the cloud.

Direct download: Melissa_Shepard_on_Well_Architected_Automation.mp3
Category:general -- posted at: 3:00am PDT

Today on the Salesforce Admins Podcast, we talk to Tom Leddy, Principal Evangelist, Architect Relations at Salesforce.


Join us as we talk about how admins can build well-architected automation solutions.


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

Salesforce Well-Architected

Tom is here to tell us about a new program the Architect team created, Salesforce Well-Architected. It’s a framework organized around the principles you need to understand what healthy solutions look like in Salesforce. “There’s a lot of great information there regardless of what your role is,” Tom says, “I think the lines between what admins do and what architects do are blurred these days.”


The Well-Architected Framework will help you get a handle on how to think about the big picture when it comes to making decisions in your Salesforce org. For example, how to put together a security model that is strong, scalable, and meets everyone’s needs over the long haul.

What makes something well-architected?

One of the things they cover in-depth is how to create well-architected automations. How do you make something that will scale and will actually add value to your business? Because, as powerful as automations are, if you’re automating a process that doesn’t make sense in the first place then you might be hurting your business more than you realize.


What needs to happen first is business process optimization, asking questions like: Why do we need to do things this way? What other business processes does this affect? Is this process repeated elsewhere in your org? Only when you’ve gotten all that straightened out do you start to build.

Why you need to remediate technical debt

This is especially important as everything is moving over to flows. We have the opportunity to look at things that might’ve been over-built in Process Builder and rethink them moving forward. There’s an architecting term for that: technical debt.


Every org will accrue technical debt over time. Maybe you’ve acquired new skills and that you didn’t have 6 months ago. Maybe Salesforce has added a new feature that makes everything easier. Whatever the reason, you need to make business stakeholders aware of the long-term benefits of remediating technical debt—building a foundation for better solutions in the future. And, like any debt, you need to pay it off little by little or it’ll just grow even bigger in the future.


Tom will be appearing on Automate This with Jennifer Lee later in April, so be sure to tune in for more how your automations can be well-architected.


Podcast swag

Learn more:


Full Transcript

Mike Gerholdt: Welcome to the Salesforce Admins Podcast where we talk about product, community, and career to help you become an awesome admin. And this week we're talking with Tom Leddy, principal evangelist, architect relations at Salesforce about how admins can build well architected automation solutions. And we did get into a few other things like documentation best practices, and really some tips that architects can give admins. It's a super fun conversation. Tom and I had a chance to catch up after TrailblazerDX, and of course Tom will also be on the Automate this series with Jennifer Lee later in April. So if you're listening to this early in April, hang on for later in April because he's also going to be on Automate this. And if you're listening later, obviously go check our YouTube page. But fun conversation. There is a question I asked Tom at the end about some fun stuff that he does, and I promise you you don't know the answer. So with that, let's get Tom on the podcast. So Tom, welcome to the podcast.

Tom Leddy:Thank you. It's great to be here.

Mike Gerholdt: Yeah. Well, we had a chance to catch up at TrailblazerDX, which feels like not that long ago, but for anybody listening that doesn't know you or ran into at a big event, tell me what you do at Salesforce and how you came here.

Tom Leddy:Sure. So I am an architect evangelist. I'm part of the architect relations team. And what I do at Salesforce is my team is responsible for creating tools and resources to help architects be successful at their jobs. And I help to make sure that our ecosystem is aware of those tools and knows how to use them and where to find them.

Mike Gerholdt: Very succinct. So what'd you do before Salesforce?

Tom Leddy:Before Salesforce, I worked at a variety of different customers and partners and I've been working in the ecosystem for a little over 10 years and used to lead digital transformations. I had big Fortune 500 companies and worked for a partner for a little while and then got the call from Salesforce.

Mike Gerholdt: Yeah. That's how it works. Boy, I think back to the last, I don't know, 10 years. You said 10 years. And digital transformations to me feel like we were going from steam powered engines to electric cars overnight to some degree.

Tom Leddy:When I think about tech as a whole, but specifically the Salesforce platform and what it looks like now compared to what it looked like when I first started working with it, it's night and day for sure.

Mike Gerholdt: Yeah. I remember page builder having to double click because it wasn't even wizzywig. You just double clicked and move stuff. Yeah. Anyway. So we chatted at TrailblazerDX and stuff. I saw a lot of people at TrailblazerDX and probably in the community have heard about this, but I want to get up to speed. Tell me about what well architected is.

Tom Leddy:Sure. So Salesforce, well architected is a framework that we created. Then it's available on the Salesforce architect's website, which we can share the link in the show notes. And it is a framework that is organized around the principles that you need to see what healthy solutions look like in Salesforce and where to spend your time and what to focus on as an architect.

Mike Gerholdt: What if I'm an admin?

Tom Leddy:You know what? Actually, there's a lot of great information there, regardless of what your role is. And I think there's honestly the lines between what admins do and what architects do are blurred a lot really now compared to, again, when we go back to what it was like to work on the platform 10 years ago compared to today. It's hard to put people into specific roles I think now compared to maybe early on. So there's a lot of great information for everybody on the site.

Mike Gerholdt: So help me understand that because I feel like I can't speak for everybody, but I've lived in the admin world my whole life and I've always seen what architect's done, and I feel like, wow, that's super way more detailed than where my brain is at. But you said there's a blur there. What do you see in that blur?

Tom Leddy:Well, I'll take security for an example. So that's one of the topics we cover in, well architected, how do I physically configure a sharing rule, which is obviously good to know, but then how should I even be thinking about putting together a security model so that it's going to be stronger long term for my organization? It's going to scale, it's going to meet everybody's needs. And that's the guidance that we really put in well architected, which is how should I even be approaching this and what should I look for to know if something is set up the right way or if it's bad and there's something maybe I need to refactor. We have some of that prescriptive guidance and then some tables that have what we call patterns and anti-patterns where a pattern is something you can physically see in an org of if you see your security model set up like this and it has these characteristics, good job, keep going, you're doing great.
 And then an anti-pattern would be okay if you see these things, hold on, stop what you're doing and let's maybe rethink this. And you may have to even have a conversation with your business stakeholders where you're going back and saying, you know what, before we keep building something on top of this that's going to cause more issues down the road. Yes, it might delay this next project, or it might be a little bit more expensive, but it's going to pay off a lot more in the long run.

Mike Gerholdt: Then you're not building something on a house of cards?

Tom Leddy:Exactly.

Mike Gerholdt: So let's take that one step further because I know later in April you are going to be on Jennifer's Automate this YouTube series. So plug there.

Tom Leddy:Looking forward to it.

Mike Gerholdt: Which would be fun. But let's talk about what is well architected automation.

Tom Leddy:Sure. So automation, that's one of the other topics we cover and we talk about how to design good automations that, number one, will scale and we'll also, we'll actually create value for a business because I'm sure everybody has seen this at one time or another where somebody will come and maybe they'll ask you to build a flow or whatever it is. And they'll describe a process and you'll be thinking in your head, "Okay. Why are you even doing this way in the first place?" And then you push back and maybe ask a few questions, and really it comes out, well, nobody really knows why we're doing it this way, but we always have and now we want to build it in Salesforce. And then you want to be thinking, "Well, do you really want to automate something that you're not even really clear on why you're doing it in the first place?"
 So that's the first topic that we actually cover in well architected, is that business process optimization piece. And then we go in a little bit deeper into, okay, now you've figured out it's okay to build this automation, it makes sense from a business perspective. Now how do we actually build it in a way that is going to be scalable and sustainable over the long term? And that's where we start talking about things like data integrity and transaction handling and asynchronous versus synchronous patterns and those types of topics.

Mike Gerholdt: I hear you, because the crazy thing is, I'm thinking about some of the conversations I had at TrailblazerDX with customers that are looking at their automations, and of course, we're moving everything to flow now, which right fits really well with this well architected thing because I feel like we're architecting things even better now. We being the royal we of admins. But in terms of this is a good opportunity for us to look at, hey, what is some of the stuff that we might have overbuilt and process builder and move it over into flow?
 What is your approach for when stuff, I don't want to call it end of life, but the features degrade and something new comes in? Because often, especially when I was starting as an admin, the joke was you talk with a developer and they'd a few years later, six months later, look at the code they wrote now having skilled themselves even more and been like, "How could I have written this bad code?" Do you often find that you look at automations or work with people in automations? It's like, "How could I have automated this? Why did I build six pages of process builder?"

Tom Leddy:Yeah. All the time. And I can say I work people with people that would say something like that, but I would also say something like that myself. Because if I think about some of the automations I built maybe early on in my career, I'm even looking at myself going, "Did I really build that? What was I thinking?" And you're right. And we call that, we have a term for that actually. We call it technical debt, which is something that could be created for a variety of different reasons. One is I built something that now that I know a little bit more, I maybe I could have done it better and there was a more efficient way to do this. Another reason it can be created is because Salesforce comes out with a feature that maybe you don't need that automation anymore because it's available in as the standard part of the platform now.
 And there's a variety of reasons that you would do that. And the recommendation that we give is that to involve business stakeholders in any technical debt remediation, because if you make that just IT's problem, then what ends up happening is the admins are going, "We really need to fix this. This is not the best way to be doing this," and all you really have to go back to your business stakeholders with this. So if we fix it's pretty much going to work the same way that it works today from your perspective, but it's just going to be better "technically." And a lot of business stakeholders will say, "Well, we don't want to pay for that."
 So what we recommend is making sure that business stakeholders are aware of the long-term benefits of remediating technical debt, which is that it's building a stronger foundation that you can build even better things on in the future, and that they're willing to make that part of projects and things that they're willing to pay for throughout the course of the year, and that they're aware that it's necessary to do that, to keep your system healthy.

Mike Gerholdt: Yeah. I feel like that's the hard conversation to have is why aren't you building new as opposed to how come all you're doing is maintenance stuff? That was always a discussion that I had to have with my stakeholders was, here's the three features I can deliver because I also need to maintain the other stuff. What is your advice on conversations like that? How from an architect standpoint would you advise an admin to balance that?

Tom Leddy:Would be working to make sure that you've got a governance structure or is use the term COE, that includes both business and IT stakeholders. And when anybody is estimating how much is a project going to cost, how much is this implementation going to cost? Like you said, everybody wants to build new, but if you factor in the, okay, we're going to build this and here's how much it's going to cost to build it. Also, we're going to be maintaining it for the next X number of years realistically, how much is it going to cost per year to maintain and how much time are we going to need? And making sure that, that information is gathered and communicated upfront so that it's not a surprise down the road is probably the best way to handle that.

Mike Gerholdt: Yeah. No, that makes sense. I feel like the best intentions, whatever that saying is slips my mind, but I feel like when you sit down, one thing that I've always admired about architects is I feel like they have this very holistic view. And sometimes as we operate in a world that doesn't give us everything, I sat down with a couple admins at TrailblazerDX, and they didn't have the full business view yet, but they wanted to build for that scale. How do you work through that? What is an architect's mindset knowing... I always envision a house... knowing I have to build a house, but possibly five more additions to it.

Tom Leddy:That involves a lot of communications. Usually at the executive level too. And I think one of the unfortunate things that happens a lot to admins is you get put into a position where people expect to just give you a set of specs and say, "Okay. Go ahead and build this." And by the time that gets to you, the discussions about what are we going to be building in the future have maybe already been had. And then you don't have the opportunity to come back in and say, "Okay. This looks like it's going to meet maybe a short term need, but are you sure this is really what you want to do?" And I think the biggest thing to do there is don't be afraid to push back when you see scenarios like that where you're curious about it.
 And I think one of the things that you had mentioned a minute ago when you were asking the question is, well, what if we don't even know? And some of that comes with experience too, is knowing the right questions to ask. And I feel like that sounds like a consulting type answer, but the truth is, the more you work, more start to think about things and I feel like your mind goes there naturally. Because when I think about earlier in my career, when I started out, I was in that role where it was people would give me a spec and I would be like, "All right. Okay, whatever. I'll build whatever you tell me to build."
 And as time went on and I started to see what was happening as a result of some of the things that people had asked me to build 18 months ago that are now coming back to bite us as an organization, because what we built was really shortsighted over time, you get and you get that experience where you start to realize, "Okay. I need to be asking these questions first." And then it really comes down to when those questions start to pop up and you're not getting good answers, don't be afraid to hold off on something and keep pushing back until you feel comfortable.

Mike Gerholdt: Yeah. And unfortunately, that can be the hard part to do. What can happen often is admins come into a role and previous admins vacated it. And I want to talk a little bit about documentation here because as an architect, I always feel like you're in this room of blueprints and every wire and diagram and everything's methodically planned out and the admin's in a little bit of a messy cave, but maybe that's just the world I live in. What are some of the things that you would advise, especially around automation? And I bring this up because not too long ago it was process builder, all the things. Now it's flow, and we have Orchestrator. Plus we also have MuleSoft. We have a lot of other ways to integrate. What are some of the best practices that you feel architects could give to admins around documentation, especially around automation?

Tom Leddy:Actually, I'm glad you asked. So we have in our various well architected chapters, there are some links at the bottom to additional resources. And one of the chapters is called Simple and Simple, the way that we tell it, the overarching pillar is easy. And then Simple, talks about not over-engineering, and I like to tell people, easy doesn't mean that it's easy for you as an architect. It means that as an architect, you've made all of the hard decisions to make it easy for your business to get value out of your solutions. But underneath the easy/simple chapter, we've got a list of tools and resources, and there are some templates for documentation.
 So we've got a template that you can download for things like design standards, so naming conventions and specific processes that you might want to follow. And then we've also got one to download just simply for documentation and what fields do I need to be filling out and what information do I need to be providing to make sure that if I walk away from this project and hand it off to somebody else, they're going to have all of the information that they need. And I'm not going to be getting phone calls every five minutes to try and explain things that I don't necessarily even want to talk about anymore because I've move on to something else.

Mike Gerholdt: Yeah. Wow. Yeah. Or you're somewhere else.

Tom Leddy:Yeah. Or you've physically gone to a different company and they can't call you.

Mike Gerholdt: I've seen that actually a few times at user groups where they'll walk up and, "Hey, used to work at... Can you tell me what this thing meant?" I didn't explicitly write that down enough. Sorry about that. Tom, outside of drawing diagrams and writing incredible documentation and building templates for admins, what are some of the things that you enjoy maybe outside of Salesforce, hobbies, VTO, stuff like that?

Tom Leddy:So let's see. So I have run at least a half-marathon in all 50 US states and on all seven continents.

Mike Gerholdt: What?

Tom Leddy:Yeah.

Mike Gerholdt: First of all, I didn't even know that all 50 states had a half-marathon. I feel like first the Rhode Island ones basically just run across the state.

Tom Leddy:Yeah, it's pretty close. Yeah.

Mike Gerholdt: Wow. Okay. All 50. I haven't even been to all 50 states.

Tom Leddy:Actually worked out nicely. It was a good way to see the country and then the rest of the world as well.

Mike Gerholdt: Okay. That's really cool. And is those number things that come from it, or, I'm sure you have pictures too?

Tom Leddy:Yeah. I've got a bunch of pictures and yeah, I've saved my race numbers and medals and everything that I've gotten over the years.

Mike Gerholdt: Wow, okay. That's a trivia question answer, I would've got wrong. For sure. And all seven continents too.

Tom Leddy:Yeah. Actually, it was about a year ago now, but went to Antarctica and did continent number seven.

Mike Gerholdt: What?

Tom Leddy:Yeah.

Mike Gerholdt: Okay. Very cool.

Tom Leddy:Thanks.

Mike Gerholdt: Wow. You might win of all the answers for the rest of the year now.

Tom Leddy:Thank you.

Mike Gerholdt: I don't know how to top that. Yeah, okay.

Tom Leddy:It was a really cool experience too. And Antarctica in particular was number one because it's Antarctica, but number two, because I was actually supposed to go back in 2020 and the trip got delayed and then delayed again and delayed multiple times because of COVID. It ended up, when I finally got to go, it was the grand finale for this big long-running journey that I had started. It took me about 15 years total to do.

Mike Gerholdt: I mean, maybe there was nothing but it was there something that kicked off this like, "Hey, I'm going to do this in all 50 states and all seven continents?"

Tom Leddy:It was funny. So I had done some local races and then I had some friends that lived in other states, and I would go to visit them and just look to see if there was an interesting race to do during the weekend that I was going to be there. And after a while I got to a point where I realized, "Wow. I've run in 10 different states. That would be cool to do all 50." And then from there, I started actually making plans specifically to go to states around the races that I wanted to do in those states.

Mike Gerholdt: Okay. So do you have a favorite that stood out?

Tom Leddy:In the States, it would be Alaska, I think.

Mike Gerholdt: And why is that?

Tom Leddy:So it's during summer solstice.

Mike Gerholdt: Okay. So the sun never sets.

Tom Leddy:Exactly. And the way that it works is you do the race at around 8:00 AM, which is around the same time most races are, and the race is awesome too because it goes through downtown Anchorage and then out into the wilderness for the second half. So I got to see a moose standing alongside the course and it was pretty cool. But then when you come back, the idea is because it's light out all night, you go back to your hotel, take a shower, get something to eat, sleep for a few hours, and then starting in the evening, there is an all night festival in downtown Anchorage where they close off pretty much all of the streets in the city, and there's dancing and food and everything. And it's summer solstice fest that goes all night. And you don't even realize it's like two o'clock in the morning because the sun is still out. And it was a fun weekend.

Mike Gerholdt: Wow. I was going to ask, I mean, I wonder if you're sleep equilibrium or whatever they call that, it was way wacky?

Tom Leddy:It when I got home. I definitely noticed it because then I had to go back to my normal schedule of sleeping in the evenings. But when you're there, surprisingly, I don't know what the specific word is for the effect that it has on your brain, but because it's sunny out and it looks like it's two o'clock in the afternoon when it's really two o'clock in the morning, for some reason, your brain doesn't think that you're supposed to be tired right now.

Mike Gerholdt: Yeah. It's I think back to some of the shows when they're in space for so long. Can I just see gravity? Yeah. You get back home, you're like, "Darkness."

Tom Leddy:Yes.

Mike Gerholdt: Wow. That's really cool. Well, Tom, thanks for being on the pod and enlightening us on being well architected. I think some of this is so cool. I can't wait to see what you're going to talk to Jennifer about.

Tom Leddy:Thanks. Yeah. I'm looking forward to that for sure. And we'll actually some of the topics we talked about earlier with automated, and then we'll do a little bit of a deeper dive into actually building some automations too, so it's-

Mike Gerholdt: Because, I mean visual.

Tom Leddy:Yeah, exactly.

Mike Gerholdt: Great. Well, thanks so much, Tom. This is fun.

Tom Leddy:Thank you. This has been great.

Mike Gerholdt: So Tom wins half-marathon in all 50 states and seven continents. That's pretty cool. I mean, that's one of the fun takeaways I had from our conversation. There was so much in there, and it was really interesting to get that architect's perspective around thinking through business process and how we automate solutions and how we architect solutions and really that planning process. Some of that can be super exciting to get into. At least I find it exciting.
 Now, if you want to learn more about all things Salesforce Admin, go to to find more resources, including all the links that we mentioned in this episode, as well as a full transcript. You can stay up to date with us on social. We are @SalesforceAdmns. No I, on Twitter. My co-host Gillian, is on Twitter. She is @GillianKBruce, and of course you can give me a follow. I am @MikeGerholdt. So with that stay safe, stay awesome, and stay tuned for the next episode. We'll see you in the cloud.

Direct download: Well-Architected_Automation_with_Tom_Leddy.mp3
Category:general -- posted at: 3:00am PDT