Today on the Salesforce Admins Podcast, we’re back with the monthly retro. In this episode, we go over all the great blog posts, videos, and all the other Salesforce content from April.

You should subscribe for the full episode, but here are a few takeaways from our conversation between Mike and Gillian.

Blog highlights from April.

For Mike, “What Admins Need to Know About Salesforce Releases” was a must-read this month. It gives you the release timeline, links to resources, and everything you need to get ready. Gillian points to Mia Pacey’s blog about delivering business value.

• What Admins Need to Know About Salesforce Releases
• 6 Ways Salesforce Administrators Can Deliver Business Value

Podcast highlights from April.

Mike had a blast talking with Mark Ross about how he and his team make Flow documentation. If you haven’t checked out his podcast, the Wizard Cast, it’s worth taking a listen. Another great episode from this month is our episode with Jen Lee about strategy and how to roll out new automations in your organization.

• Flow Documentation with Mark Ross
• Automation for Admins with Jen Lee
• The Wizard Cast

Video highlights from April.

LeeAnne Rimel’s Expert Corner is a great new series that gives you the experience of meeting with a subject matter specialist at Dreamforce or TrailheaDX. You should also check out No Silly Questions, where Gillian tries to answer any question submitted by the community or brings on an expert to help her get to the bottom of it.

• Expert Corner: Build Integrations with Clicks with MuleSoft Composer Product Manager Ashley Simons
• No Silly Questions: How Do You Create Sandboxes in a Professional Edition?

Social

• Salesforce Admins: @SalesforceAdmns 
• Mike: @MikeGerholdt
• Gillian: @GillianKBruce

Love our podcasts?

Subscribe today or review us on iTunes!

For this episode of the Salesforce Admins Podcast, we want to pull back the curtain and explain our process for prepping Release Readiness Live.

Join us as we talk about the questions we ask as we go through release notes, why it’s important to use different modes of communication to present key information, and how to find the throughline to tie it all together.

You should subscribe for the full episode, but here are a few takeaways from our conversation with Mike and Gillian.

Our Release Readiness Live prep process.

We thought it might be useful to talk about our own process for how we prep for Release Readiness Live content. “It’s one of the more fun parts about our job,” Gillian says, “it gives us an excuse to get tighter with our product organization and look through the incredible breadth of the platform.”

The first thing we consider is whether a new change or feature is something we’ve talked about before with admins. Some areas, like automations, have a bunch of new things continually added while others are one-offs or completely novel. We also consider if it’s an enhancement or something new. Finally, it’s important to highlight improvements to processes that can save steps along the way.

How to communicate changes and new features to your users.

Once we’ve done some processing from the release notes, we work with our content teams to get the information out there. That’s Release Readiness Live, but also demo videos, blog posts, and, of course, this podcast. You might not have the same resources that we have access to, but the important thing is finding a way to accommodate all the different ways people process information and get the key points across.

Most importantly, we’re always looking for a throughline—a story we can tell to put everything together. For example, you do a Slack post that updates a record that fires a new Flow that has a decision in it that does something else. In short, find a way to help your end users relate to the changes and understand how it impacts (and hopefully improves) their day-to-day.

We also wanted to highlight a few key dates for the Summer ‘21 Release:

• April 15th: Pre-Release Signup (it’s not too late!)
• May 6th: Sandbox Pre-Release signup
• May 7: Summer ‘21 Trailhead module goes live
• May 11th: Release Overview Deck is available
• May 21st: Admin Release Readiness Live
• June 4th - 12th: Summer ‘21 Release

Links:

• Admin Release Countdown: Get Ready for Summer ‘21 blog post

Social:

• Salesforce Admins: @SalesforceAdmns 
• Gillian: @GillianKBruce
• Mike: @MikeGerholdt

Love our podcasts?

Subscribe today or review us on iTunes!

Today on the Salesforce Admins Podcast, we talk to Jen Lee, Lead Solution Designer at John Hancock, six-time MVP, and Salesforce Platform Champion. We’re continuing Automation April to learn how you can bring automation magic into your Salesforce instance and make your end users’ lives easier.

 

Join us as we talk about why you should go with the simplest automation solution for each problem, why you shouldn’t only think about the “happy path,” and how to learn more about Flow.

 

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

 

Automation for Admins.

 

“I like being able to talk to the business users, understand what their business processes are, and then be able to automate those processes for them,” Jen says. She does just that in her day-to-day work as a Lead Solution Designer at John Hancock, but also in the content she creates for the community. Jen is the host of Automation Hour, a series that gives people a chance to present how they’ve used automation to make things easier in their org.

 

One important thing to realize is that automation doesn’t just impact user productivity—it can also be huge for admin productivity. Jen recently implemented a solution that goes back and removes a deactivated user from everything a week after they’ve been deactivated, saving admins from having to wade through public groups and permission sets and the like. “The admin doesn’t have to remember to do these things, the system remembers for them,” Jen says.

 

New Flow features.

 

Jen is excited about several new features that have come to Flows in recent releases. The first thing she highlights is improved functionality behind Record Trigger Flows, which will help you move processes to Flows. Another huge change is the inclusion of a link to Flow Builder in your dreaded Flow Fault email to help you pinpoint what’s going wrong without having to into debug logs.

 

If you’re looking to get started with Flow, Jen recommends getting started with the projects in Trailhead that focus on Flow. There are also some really great blogs out there that can help you along the way, and we’ve included her recommendations below. The community is generous and happy to help, so if you’re ever stuck make sure you reach out.

 

How to implement a new automation in your org.

 

When Jen is thinking about a new process or building a new automation for her org, she starts by talking with users to find out how they currently go through their process. It’s especially important to get them to break down how they know they need to do each step because that’s what you’re trying to automate.

 

Once you have the business process mapped out, you need to ask yourself: what is the simplest configuration you could use to implement it? “What fires off the process determines which path I take,” Jen says, “understand what triggers the process and then determine the best Flow or Process Builder option to take.” Keep in mind that you need to not only think about what happens when everything goes right, but also plan for and troubleshoot for what happens when everything goes wrong. As Jen put it, “don’t just think about the happy path.”

 

Jen also shares some ideas for how to train your users to work with new automations and show them how to integrate them into their daily routines, so make sure you listen to the full episode for more tips and tricks.

Links:

• Jen’s Blog
• Automation Hour
• Automation Champion

Social:

• Jen: @JenWLee
• Salesforce Admins: @SalesforceAdmns 
• Gillian: @GillianKBruce
• Mike: @MikeGerholdt

Love our podcasts?

Subscribe today or review us on iTunes!

 

Full Show Transcript

 

Gillian Bruce: Welcome to the Salesforce Admins podcast, where we talk about product, community and careers to help you be an awesome admin. Today we have another Automation April guest for you, because we are going to still focus on how you can bring automation magic into your Salesforce instance. Because as admins it's one of the most important things we can do, is help make our end users lives easier. And we can do that because we've got the tools with Salesforce to make that possible. Today, we are going to be talking with Jen Lee. Who's a lead solution designer at John Hancock. She's a six time MVP, a Salesforce Platform champion. She's also got lots of Salesforce certifications. She has a blog. She helps co-host something called Automation Hour, which we'll talk about. So without further ado to help talk more about automation in this month of April. Let's welcome Jen to the podcast.
Jan, welcome to the podcast.

Jen Lee: Thanks for having me.

Gillian Bruce: It's been long overdue to have you back on the pod. It's been been a while, so happy to have your voice back on the pod. Jen I'm sure many people, many listeners already know who you are, but I'd love to give you a chance to introduce yourself to maybe some listeners who aren't familiar with you. So Jen, can you tell us a little bit about who you are and what you do?

Jen Lee: Sure. I'm Jennifer Lee. I am based in Boston and I am a now six time MVP. So excited about that. I love automation. So we'll talk about that in a little bit, a little bit more about that. I currently work for John Hancock as a lead solution designer. So I work with all our agile squads to set best practices and governance standards for all our orgs and I review designs and review built solutions before they go to production.

Gillian Bruce: That is awesome. All right. So you said you love automation. I would love to hear a little bit about why you love automation.

Jen Lee: I like being able to talk to the business users, understand what their business processes are and then be able to declaratively or sometimes with a little bit of code help, be able to automate those processes for them. So taking manual steps and just with a click of a button, or if they make changes to record, be able to save that and then it does all the things for them. So that's just cool being able to help them and boost their productivity.

Gillian Bruce: Yeah. I think that's one of the core elements of being, what we like to call an awesome admin, right? Is being able to make our end users lives easier and help them do their jobs with less tasks involve. So let's talk a little bit about your expertise in automation and what you are doing in that space. So I know you've done a lot of content for the community on automation. Can you talk to us a little bit about kind of some of the main things that you do within the Trailblazer Community focused on automation?

Jen Lee: Oh, I forgot to even mention my blog in the intro. How did I forget that? I have a blog, jenwlee.com. I also co-host Automation Hour. So in Automation Hour, for example, we give people a forum to present automation and how they solutioned for the audience. So different skill sets, but we cover all things like Process Builder and Flow. But particularly what I focus on is, more so now, on Flow Builder and all the cool features that I could build with flow. I focus on things like the administrative side of things, the user maintenance side. For example, when you're deactivating a user, a lot of times admins don't go back and clean up all the other things that the user is part of. So like public groups, permission sets, cues, all those things. And at John Hancock, I built a solution that once we deactivate a user and a week afterwards, just to make sure that the user doesn't need to be activated again. We go and have an automated scheduled flow that goes through and removes them from all the things.
So that an admin doesn't have to go to public groups and remove from permission sets and licenses and all that sort of thing. So it's really focusing on building up the productivity. So someone doesn't have to remember to do those things.

Gillian Bruce: So I think I love that story because what I hear this is like a automation that works for admin productivity, as opposed to just end user productivity.

Jen Lee: I even do things like, if we know certain users meet a certain criteria, we could add and remove permission sets accordingly or permission set groups, things like that. Again, the admin doesn't have to remember to add these people to those things. The system remembers for them.

Gillian Bruce: Oh, I love that. I love that. Less manual labor is always a good thing. So Jen, you mentioned, flow is definitely something that we are focused on here in Automation April as I kind of dubbing it. What are some things that are kind of newer in flow that you think admin should pay attention to because they either make you excited or you see some great value props from them?

Jen Lee: Yeah. And I want to give props to the PMs of automation because they continue to add such great features with each release. So some of the things to look out for is now there's a lot more functionality behind record triggered flows. So now you can take your processes and start moving them to flows because Flow Builder's going to be the end state automation tool. So you can now remediate that tech debt, where you have all these processes and start moving them to flow. They've done a lot in terms of helping out with debugging flows. So one of the most recent changes in the last release was now when you get that ugly looking flow fault email, it includes a link to the Flow Builder. So you click on that. It takes you directly into Flow Builder where your flow faulted. And so now you could visually see where the record went and then it stopped.
So it just adds to the whole troubleshooting, being able to quickly troubleshoot and not have to go into like debug logs and things like that. And then some of the other features when I compare to when I first started learning flow. Now in Flow Builder, you don't have to set all the variables, because way back when in Cloud Flow Designer, for everything that you needed to hold data for, you're creating a variable. And now this has really helped speed up the learning curve on flow, because you can have Salesforce Flow, create those variables for you. You could still create them if you want to, but it's just speeds up the development process of creating flows.

Gillian Bruce: So I vividly remember Jen, the first time that I tried to use flow and it was the old Cloud Designer. Oh my goodness. And I remember, I didn't even understand what a variable was. And I was so confused because I felt like I was having to create six things in order to just do a two or three step flow. Especially not being from a developer background, I didn't even understand these concepts. I'm like, "What is an SObject? What is a variable? Why do I need to set these things? What is this language I'm using? I don't get it." So when you mentioned that, with the new version of flow, which is amazing. The fact that Salesforce automate some of that, might make it a little easier for anyone who got a little intimidated by flow in previous years to kind of maybe think about diving in to flow land. I keep naming different lands on this podcast. I don't even know how many there are at this point.
But can you talk to us a little bit about, maybe somebody who's new to flow or is a little hesitant. Can you talk a little bit about how they might think about or approach flow land? What are your tips and advice for people and why they should do that and how they should approach it?

Jen Lee: So I had a very similar experience to what you had when you first started with Cloud Flow Designer. I opened up that blank canvas and saw variable. What's a variable? What's the SObject stuff. And I immediately closed the browser. I'm like, "I don't know what this is. I have no idea." And I eventually kept at it and I am where I am today because I was persistent. But I totally understand if you started off with that and you looked at that, you're like, "Okay, this is so complex." You really did need a developer mindset to understand what it was that you needed to do. So I would say, "Okay, now is the time, where it's okay to go into Flow Builder."
So now instead of understanding SObjects, you have just one Get Records and one Update Records, and one Delete Record. You didn't have to know whether this was a fast update or a regular update. And again, I mentioned not needing to create variables, all that stuff is done for you. And it just makes it so much easier to use the tool. So I would recommend, if you haven't played around with the projects in Trailhead that focus on flow, I would recommend going and doing that. Because it goes through step-by-step on how to create something in flow. I would also recommend reading the blogs of people who teach flow. So my blog, Rakesh Gupta's Automation Champion blog. There's so many out there right now. But really taking one of those that have a use case that you could connect with and actually go through the steps of building it and then just keep at it.
And the community is just so great that when you have a question, whether it's on Twitter or it's on some Slack channel or on the Trailblazer Community, you post that question, people are so helpful that even if they can't do it within the Trailblazer Community, because it might be a little bit complex going back and forth. I've seen people post messages, like "I will jump on the phone with you and I will help walk you through it." So I'd say, try it. And if it doesn't work, keep trying, but reach out for help. Because there's so many people willing to help out and eventually it will connect. It will connect for you.

Gillian Bruce: I love it. Yeah, the generosity of the Trailblazer Community always blows me away about how people are so willing to spend their time to help someone else learn. Just a simple little thing or troubleshoot a simple issue. And then it just grows from there. It's incredible. It's incredible. So Jen, can you also talk to us a little bit about your overarching strategy. You talked earlier about, the use case that you had, automatically removing a user, a deactivated user from processes. When you're developing a new process, or thinking about bringing a new type of automation into your org. What are kind of the first steps that you take? Maybe even before you start building it. How do you figure out what you need to build? What kind of teams and meetings and stuff do you set up? Talk to us a little bit about that.

Jen Lee: So if it's benefiting the user, I would typically talk to the user and have them show me the steps that they currently take to do X, whatever it is, that they're doing. And literally step through the process and I'll say, "How do you know you had to put this value in there." Because sometimes when they're clicking, they're not talking through the things that they determine in their head. Because ultimately when you're building out automation, you need to be able to know those things and tell Salesforce what they need to do or how. Or I need to get this account information. How did I know which account to get?
So those are the things that you need to... Like on paper, write down, here's what the business processes, or here are all the manual steps that need to happen in decisions. Write it down, map it out in some process diagram, and then get consensus. Like, this is what I heard you. And then this is the pieces that I'm going to automate and how I understood the process to be. Get consensus, and then that's when you then go into Salesforce and actually build it out.

Gillian Bruce: I love that. I liked the verification step that you just mentioned too. First you kind of do your investigation with asking the user the very detailed questions of why did you put that there? Where did that come from?

Jen Lee: With the five whys, why did you do that? Why? Why?

Gillian Bruce: Right. Channel your inner toddler and just drive them a little crazy, but it'll work. It'll make them happier in the end. And then the verification of showing them the process that then you've mapped out based on what they've showed you. And then getting the like, "Yes, that's what we do." Or maybe, "No, you skipped a step." Or "That's not how that's related." I think that's really important to think about.
So the next step then Jen is, how do you then start thinking about how to put that into Salesforce? How do you figure out what features to use? Maybe even from when you start building it to. Whatever tests and stuff you do, and then even through rollout and getting users to start adopting it. Can you talk us through a little bit about how you do that?

Jen Lee: So once I understand the requirements or business process, then I'll think through, what's the simplest configuration that I could use. Maybe it might not be flow. Maybe it's just a quick action that takes you to the page with fields, and then that's how you submit it and save it. So if it is automation, then I'll figure out, do I go the Process Builder route? Is it something that's a record change? And then it does other things, or can I start in flow directly. Figuring out what fires off the process, determines which path I take. So if it requires collecting information then I know that, that's a screen flow. If it's something that happens on a schedule basis and that's scheduled flow. So it's like understanding what triggers the process and then determining the best flow option or Process Builder option to take.
Then when I build out my flow, for testing purposes, you need to consider not only the happy path when everything goes right, but also the other things that could potentially go wrong. And then in testing you have to build in controls that might prevent those errors from happening. So for example, if your process looks for a value in the field, and then it does these other things, well, then you need to put in a check. Does this field have a value before you go in or else your flow's going to fault. So then you need to put in those extra measures to check for that. And then also in your testing, you need to do negative testing and make sure that those things don't happen as well.

Gillian Bruce: I love that. Don't just think about the happy path. It's very important to remember. Because I think sometimes we work so hard to build something and you just are so focused on how cool that is and it works and it's so great. But you got to remember, users are going to do all kinds of stuff and you never know.

Jen Lee: Exactly. And you're like, "Why did you do that? I didn't even think of that situation." So then you have to go back and build that situation in. Yep.

Gillian Bruce: Yeah. Again, kind of going back to a toddler analogy since I have one. It's like thinking about all the possible things that they might do to destroy something, right?

Jen Lee: Exactly.

Gillian Bruce: You got to move the sharp objects, another shelf up, or you've got to put the door knob protector on there, all of the different things. So let's then talk about kind of rolling a new automation out to your users. So you've got it built, you've tested it, it works. What are some strategies? Because you don't work at a small organization. Tell us a little bit about how you roll out a new feature set or a new process to your user base.

Jen Lee: So depending on how many users we're touching, we might in our release, provide release notes to let folks know, hey, there's a change coming. Sometimes when it's automation, it might be just transparent to them, and they shouldn't need to know that something's changed behind the scenes. But if it's something that's taking manual steps and automating it, we would typically maybe do a video clip and send it out to the users, or on Lightning, you could use that in-app guidance. And for a period of time, if they're going on a page where you have that automation, give them a heads up. Here's what's different now, to let them know.

Gillian Bruce: Yeah. It's a very good point about the in-app guidance. It's a great tool for any admin looking to roll out anything. So Jen, I would love to kind of, before we wrap, have a little fun. So Jen, you have been in the Salesforce ecosystem for a while and in the Trailblazer Community. I would love to know what is one of the most interesting or funny, maybe use cases or demos, that you have seen from either in your own that you've built as an example or somebody else in the community who shared something that kind of made you giggle?

Jen Lee: I know I saw someone build automation where they use it to play a Blackjack game. And I thought that was an interesting thing. And I forget if it was Dreamforce or it was a webinar or something. But yeah, I thought that was an interesting use case to build with automation. I wouldn't have ever thought about that.

Gillian Bruce: I wouldn't either. There you go. I like it. That's great. All right. So any kind of last parting thoughts or pieces of advice you love to leave our amazing, awesome admin listeners about automation in general? Before we wrap up today.

Jen Lee: Create that automation because that's really using your awesome admin powers to help out your users and increase their productivity.

Gillian Bruce: I love it. Simple, great, powerful. Jen, thank you so much for joining us on the podcast today. I really appreciate it. And I so appreciate all the work you do with Automation Hour and your blog. I know it helps thousands and thousands of awesome admins in the community. So thank you.

Jen Lee: Thanks Gillian for having me back.

Gillian Bruce: Well, huge thanks to Jen for taking the time to chat with me. It's always great to catch up with her and of course talk about all things automation. So for my top takeaways from our chat with Jen today is first of all, when you're thinking about implementing or designing an automated solution for your users, go with the simplest path possible. As Jen says, that is going to set you up for success in the longterm. It's also going to make your job easier. So really think about what type of automation is needed. Is it something where you need to capture information, in which Jen suggests using Screen Flow? Is it something where when a record changes, other actions need to happen? This is where you really determine which type of automation you are going to build.
Next, think more than just about the happy path, as Jen says, thought this was great. You know, we really love to get proud of ourselves. We build complex awesome, beautiful automated solutions, but guess what? People are going to do all kinds of things to that process. So make sure you try all of the different ways in which that process may or may not break. As I said, think of it as childproofing your process for any parents out there, you understand what I'm talking about.
And then finally, when you're trying to learn about automation and flow, I really like Jen suggestion of trying to find a use case, an example, that you can identify with, that you can relate to. There's plenty of content, we've got projects on Trailhead, there are examples in both Jen Lee's blog and she mentioned some other resources which I'll put in the show notes. Find a use case that speaks to you that maybe is more relatable to your job function, or maybe even something fun, not related to your job, but that you understand. That will really help you as you follow along and build that on your own to help understand how the tool works and how the features can really do some amazing stuff.
So those are my three takeaways from speaking with Jen. I hope you enjoyed listening to the pod. As always, if you've got a review for us, we'd love to hear it. So make sure you go on over and leave us a review on Apple Podcasts. And if you want to learn more about all things, awesome admin, make sure you go to admin.salesforce.com for all kinds of great content, blogs, Trailhead, the live events, podcasts, even some fun videos and make sure you check that out. You can follow us on social at @SalesforceAdmn no I. Our guest today Jen Lee is on Twitter, she is @jenwlee. And you can find myself @gilliankbruce and my cohost Mike Gerholdt @MikeGerholdt . With that, I hope you have a wonderful day and we'll catch you next time in the cloud.

For this week’s episode of the Salesforce Admins Podcast, we’re joined by Mark Ross, Senior Tech Writer at Salesforce. We ask Mark how he approaches documentation and how you can make a difference for your users.

Join us as we talk about what goes on behind the release notes, what’s important when you write your own documentation and the importance of learning your variables when it comes to Flow.

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

The Salesforce CCX Team

You might recognize Mark’s voice from the WizardCast. At Salesforce, however, he works on the CCX team (Community, Content, and Experience). They help with Trailhead, documentation, and more, and Mark specifically focuses on automation services: Flow, Process Builder, Workflow and Approvals and even IoT.

“I’m someone who is a very technical-minded person, but I never learned to code—not really,” Mark says, “Flow can do all these things that, ordinarily, I would need code to do and it opened up a whole new world for me.” In other words, Mark is a certified Flownatic and he wants to share that enthusiasm with everyone and teach them how to harness the power of automation.

Mark’s keys for writing good documentation

So how do you write documentation for new features? It starts with sitting down with the engineers to actually go over everything and look at any text that might be a part of the UI. Next, Mark and his team turn to the release notes. “Believe it or not, release notes are the most-viewed documentation of Salesforce,” he says. They want to not just communicate what’s happened, but why it’s useful.

When Mark is prepping Flow Release Notes, he starts by going through the headers to see what will affect his current customers or users. Sometimes, that also means noticing new features because it gives you the ability to let people know what’s on the way.

“If you release something for your users and you don’t write down how to do it, you’re automatically doing them a disservice,” Mark says, “even if you train them face-to-face, that’s not the same as them having something they can come back to later.” Especially if you can keep things simple and use screenshots to help point people in the right direction.

There’s a lot more in this episode, including what Mark and his team think about when they write error messages, and an adorable special guest.

Links:

• Flow Builder Documentation
• The WizardCast

Social:

• Mark: @MarkRoss__C
• Salesforce Admins: @SalesforceAdmns 
• Gillian: @GillianKBruce
• Mike: @MikeGerholdt

Love our podcasts?

Subscribe today or review us on iTunes!

Full Show Transcript

Mike Gerholdt: Welcome to The Salesforce Admins Podcast, where we talk about product, community and career to help you become an awesome admin. This week, we're talking with Mark Ross, who's a technical writer, about flow documentation and how we learned about flow and it's features. Now, you might have heard Mark on another podcast, he's also the cohost of The Wizard Cast, which is a big fan favorite of everybody that records this podcast, so shout out there. And, he's also given a ton of Dreamforce presentations around flow. So this is very exciting, I'm so glad we got Mark on the podcast. So here we go, let's bring Mark on the pod.
So Mark, welcome to the podcast.

Mark Ross: Thanks, Mike. It's good to talk to you again, it's been a little while.

Mike Gerholdt: It has. And, for those community members that perhaps are like, "This voice sounds familiar," you're also on another podcast. We'll start there as your introduction.

Mark Ross: Well, that is true. There's a little podcast that's out there called The Wizard Cast, and despite it's name, we actually talk about Salesforce. We don't have too many episodes going out lately because pandemic stress and all that. But yeah, we're out there on all the major platforms for podcasts.

Mike Gerholdt: Now, when I think flow and Salesforce flow, and dare I say flownatics, I think of Mark Ross because I know you've been on stage at Dreamforce talking flow. Gillian and myself have done a lot of content around flow. Let's start off with what you do at Salesforce and how that relates to flow.

Mark Ross: Sure. Well, I am on the community and content experience team, CCX. We specifically are responsible for creating the content that is customer visible. In this case, specifically that's going to be documentation. But we also help with Trailhead, our particular team, and a few other things that are out there, that are community facing. Not everything that's customer community facing, but we still have quite a bit of it.
I specifically am on the CX team, as we say, for automation services. In other words, flow, process builder. Even workflow and approvals, and even IoT.

Gillian Bruce: Just a few things to cover in your scope.

Mark Ross: Just a few things.

Gillian Bruce: Not too bad, right?

Mark Ross: Right.

Gillian Bruce: So Mark, I would also love to maybe just give a tiny bit of background into how you came into this role, because you've been at Salesforce a couple years now, maybe?

Mark Ross: Yeah, I started in January '19.

Gillian Bruce: Okay. And before that, we talk about flownatics, most of the context in which I think Mike and I are very familiar with you and your work is actually pre-Salesforce days, when you were not part of the company but you were an end-user, and an MVP and a leader in the community. Can you talk to us a little bit about how you became a flownatic?

Mark Ross: Back in 2010, I attended my very first Dreamforce. And, we as a company, the company I was working for at the time, we hadn't even really started using it yet. But my company sent us all to Dreamforce to say, "Hey, you're going to start using this Salesforce thing, you might as well go learn about it."
And I attended a session on the desktop flow designer, and it was literally an executable you had to run on your machine that saved .flow files that you then had to upload into Salesforce, and I was absolutely entranced. As much as I had drunk the blue Kool-Aid at Dreamforce in general, my very first Dreamforce, flow to me was the big takeaway. I immediately went back to company to start figuring out all the things I could do with flow. Every new position that I took at the same company or different companies, I was always flow, flow, flow, flow, flow. Until the point where I realized, I love flow, I love flow. Why is nobody else talking about flow? This is an amazing thing, nobody in the community's every talking about flow, so I decided I'm going to start talking about it. That's basically how it happened. I met Brian Kwong at another Dreamforce, and he and I became fast friends and flownatic buddies. He and I basically became partners in crime.
From there on, I basically had a lot of different positions. And at some point I'm just like, "You know what? I'm done with at the very least the consulting thing, and not feeling the admin thing as much any more. I wonder if there's something I could do for Salesforce?" I started talking to people, I started looking around, and eventually ended up at Salesforce.org, where I was writing documentation for some of their gift entry products. And then, last year the flow documentation team, the automation services CX team, reached out to me and said, "Hey, we have an opening, we hear you love flow." I was like, "Man, I love Salesforce.org, my team here is really great, but it's flow! I can't say no to that," so I made the jump. That's the story.

Mike Gerholdt: So flow caught fire for you. Why do you think it really clicks for some people like yourself and not everyone?

Mark Ross: I think, for me specifically and I'll branch this out into how I think other people probably feel about it just from my guess. For me, I am somebody who is a very technical-minded person, but I never really learned to code, not really. Learning Apple Basic in grade school isn't the same thing as sitting down with Apex and whipping out a whole bunch of functions and triggers. It's not the same thing. So I had the programmer's mindset, but I didn't have the experience. Every time I tried to sit down to learn it, it became a prohibitive thing. I even went to Apex training, and it just, for some reason, wasn't clicking.
But when I sat down in front of flow, it clicked. To me, it was this is the things that I would normally need to do, especially when you go back to 2010, 2011 when I first saw this. Flow can do all these things that, ordinarily, I would need code to do, I would need Visualforce to do, and that was a big, big deal. All of a sudden, it was a whole new world without actually singing the Disney lyrics because that would get us in trouble. It was I now have more power than I know what to do with, and anybody has previously considered, without needing code. I think that was part of the big allure at first, it was this ability ... I can do things workflow can't, and I don't need to write a line of code.
That is incredibly attractive to people, maybe they are Salesforce literate, they've been doing Salesforce for a long time. But code, the hurdle's just a bit too high without hitting your toes on it. To be able to still have a good measure of that power, to be able to do things that your users want and that you want to do for your users, and to make really snappy interfaces as we're starting get better looks for flow now, that's incredibly alluring. That's where I think the draw comes from.

Gillian Bruce: I mean, I think you encapsulate it. Clearly, you hear the flownatic passion in your voice. I think what you outlined is a lot of the reasons why we definitely are focusing on automation and all things flow this month for admins.
I would love to maybe hear a little bit more. Mike said that, basically, you're in documentation land. I don't know why I make everything a land, a feature set in this podcast. Maybe now you have me thinking Disney and I'm thinking, "Oh, we have Automation Land and Documentation Land."

Mike Gerholdt: Land of the Lost.

Gillian Bruce: It's all these happy places, the happiest places on Earth. Or, on the platform. Can you talk to us a little bit about how documentation plays into the arena of flow? And what the role is, how you approach it? What is your methodology there?

Mark Ross: Sure. We have a cycle, just like their developers do. They have a cycle where, any given release, they have to do things in a certain order, and we do as well. When we're presented with the actual things that are being worked on by the engineers, we actually help to do the UI text. We don't just do documentation, we're actually sitting down and saying, "All right, this button should be called this because, unfortunately, the name the developers came with is a little bit misleading." Everything from errors messages, to modals, to the actual clickable interface, if it's got text in it, we're looking at it. That's part of our cycle.
The next thing we look at is release notes. Because believe it or not, release notes is actually the most viewed documentation of Salesforce. That is actually a really important area of focus for us, so we spend quite a bit of time on release notes as well, making sure that they are understandable, making sure they're communicating things, not just what's happened but how it's useful as well to the users. It's not just enough to say, "Well, we've made this." What we also are trying to say, "We made this, and you can use it for this. Or, it improves your life in this way."
Apart from release notes, we also of course do the actual documentation. So you have the help doc, also the dev doc, things like the API docs, metadata API docs, things like that. We don't necessarily touch all the little things that are dev doc oriented, but we do help with those metadata, API focused areas. But the documentation, of course, is a big deal. A lot of that, to be honest, we're going in and we're updating things that need to be updated. But every now and then, we're going to put out a new page. The thing is, the flow documentation started in a bit of a rough spot because it was relatively complicated. Many years ago, it started out relatively complicated and it was difficult to just, all of a sudden, slap down a whole bunch of documentation for that. So over time, a lot of documentation has been added. If you checked out the flow documentation five years ago, it's a very different beast now than it was then.
We're covering a lot more topics. We're covering a lot of things like best practices, how [inaudible] works, limits. Some of those limits docs are my favorite docs. You wouldn't think the documentation that says the things you can't do would be one of my favorites, but it absolutely is. Because I can't tell you how many times I've hit some kind of an error, and didn't know what it was, and somebody pointed, "Hey did you go over your limits?" I was like, "Limits? There are limits?" Yes, there are limits so you have to go check those out. Element limits, sociable limits, things like that. So many of my problems, and so many of the people I've talked to, people in the community, their problems have been solved just by going to look at that. There's all sorts of other really helpful things, more in use cases, example use cases that are out there as well. References for individual parts of flow, all the different screen components, all the different elements, they all have their own individual pages so those are valuable, too.
And then, after of course documentation, there is Trailhead. We don't necessarily manage all of the Trailhead content, but there are certain badges that we definitely help to maintain. There are some that we're having to retire because they're, frankly, out of date. At some point in the future, we're going to have some more flow content coming, and we're definitely wanting to hear your feedback on that as well. Because we know there are some gaps in how the Trailhead badges guide people, we want things to be not too prescriptive but not unhelpful, either. So if anybody has any input on that, we'd very much welcome that.
I think that pretty much covers our doc cycle and everything we put out.

Mike Gerholdt: You hope, until the next release.

Mark Ross: Right, exactly. There's always more, right?

Mike Gerholdt: I'm trying to bounce between being a beginning admin learning flow, and somebody that's been on the platform for a while. You've been around for a while, you remember before Trailhead and only having documentation as a way to learn a product.
I'm going to use the release as a jumping off point. As somebody that's rolled out flow, that has a lot of processes and flows built, and I'm sure a lot of listeners do as well, what are things in the release notes that you look for?

Mark Ross: When you're talking about flow?

Mike Gerholdt: Yes.

Mark Ross: Well, my general behavior for flow release notes is the first thing I'm going to do is I'm going to do a pass, just start reading the headers. I'm looking for things that are going to ... If I'm an admin, in my days as an admin, I'm looking for things that impact my current customers first. Whether I'm a partner, implementer, I'm looking for my customers. If I'm an admin for a company, I'm looking for my company, the things that are in my org or orgs right now. Because there are going to be changes, there are going to be critical updates and those things can have an impact on the things already out there. But, sometimes there's a new feature that came out.
Just two months ago I was telling somebody in sales that I couldn't do this. Now all of a sudden, this is now a feature that's going to be available. It's going to be beta, it's going to be new, but at least I can tell them it's on the way. That's something you can ... Especially if you're working with a sales department, a sales enablement, or whatever department that you're working to enable, just being able to tell them, "Yes, it's coming. It's on the way," will make them feel so much better.
So reading the release notes, and getting an idea of what's out there and what's coming, even if you can't use it, even if you're tied behind procedures that ... I say tied, that makes it sound negative. Even if you're having to listen to procedures that are governance oriented saying, "Well, you can implement something until goes through this change management board," that's great, you always respect the change management board. But at least you'll be able to tell people, "Hey this is coming. I feel your pain and we're going to work to get it implemented as soon as we can," that will make them feel so much better.
Other things to look for in the release notes, sometimes the release notes will have a basic how-to if the feature we're talking about is particularly complicated. You briefly mentioned release notes as documentation, in a sense, they can be a little bit, very entry level documentation. When we're doing help doc, we're going to go into more detail, more information about something, but sometimes if you just need a really quick primer on something, the release notes can be a good place to start.

Gillian Bruce: So Mark, I would love to maybe ask you, switching your mindset a little ... Clearly, you are a documentation superstar. If I'm an admin at an org, and I am building flow processes and all kinds of stuff, how should I think about documentation and incorporating some of maybe the best practices you've learned into my own processes?

Mark Ross: Documentation is really interesting, at least for me. I'm a nerd, obviously. It's interesting because you can do so much with it, with just a little bit of time. I think that's the hurdle that a lot of people feel, is finding the time to sit down and write something. But, if you release something for your users and you don't write down how to do it, you're automatically putting them at a bit of a disservice. Even if you train them in it face-to-face, that's not the same as them having something they can come back to later. So just sitting down and writing the steps out, just do it, just make the time, find the time. Convince whoever's in charge of your hours that it's worth the time because it really is, it will save you so much trouble and will save your users so much frustration. So that's the first step, just do it.
The second step is make sure that whatever you're doing is clear and understandable. And I know that that is easier said than done, and not a very specific answer, but it is really important. If you're using a new term, maybe you've named a new app, use that same term consistently. Don't flop around with different versions of it, it will confuse users.
Hang on, my cat is being demanding. He's being noisy.

Gillian Bruce: I couldn't tell if that was child or an animal.

Mike Gerholdt: I couldn't either, but that's awesome.

Mark Ross: Ah, there. You've had some love, so are you happy now? Okay. Where was I?

Mike Gerholdt: What's the cat's name?

Mark Ross: Twiglet.

Gillian Bruce: Twiglet, that's great.

Mark Ross: She's a fat black-and-white cat, aren't you? Yes. She's a talker.
Using the same terms is important. Also, try to avoid really, really complicated language. If you can keep things simple, that's going to be really helpful as well. Don't use jargon, don't use things, don't assume that they know Salesforce terminology because they might not. Screenshots, screenshots. Again, they take time but they're worth it, because you can literally point someone in the right direction. Anything you can do to help make things more clear, and not be vague, and not be too technical.
Those two things, just do it and be clear, those are the best things you can do.

Mike Gerholdt: Was there something you've learned, now that you've been writing documentation for a while, that you think could be really helpful for admins to know?

Mark Ross: I'm not sure, I'm not sure how to answer that. Frankly, as long as you're ... A lot of what I've learned since coming onto documentation is how to do proper technical documentation. So things like style guides, where there's established written Wikis, or Confluences, or books like the Chicago Manual of Style, which professional writers have to use. That's the difference between what I as an admin had to do, writing just documentation for my features, and then becoming a professional writer and having to write up to a certain standard, there is a bit of a gap there. I don't think that gap is necessary to be bridged as an admin, I think it creates too much pressure and too much expectation.
I think, again, if you're just writing something and you're trying to write it clearly ... That is definitely one of the things we look at, when I'm having my editor look at things, is clear. It has to be clear, it has to be understandable. Is it possible that however I wrote this could be interpreted in a different way? You would think the innocent pairing of words couldn't possibly mean anything else, but it turns out, oh wait, this could actually be meant as something entirely different. So going back over your text after you've written it, and maybe making new versions of it. We call it iterating, on the team.
So I wrote something, but I'm not feeling that great about it. That's fine, move on, come back. When you read through it again, oh there's that sentence. You know what? Here's another version, and just write it again, just make more iterations of that text until you get something. When you're doing your own self edit, look for the things that might mean something entirely different if you look at it at just a different angle.
This is relatively high level documentation stuff, but sure, those are things that could be valuable. I'm not sure how well I answered that.

Mike Gerholdt: No, a lot of it is you learn what you don't know. Some of it, I think to the point that you brought up, sometimes at least when I'm writing content, or working on something for a project, you'll find you're so close to it that you don't remember to tell people what you innately know. I feel that with documentation. You're so close to the app that you're writing maybe these high level milestones, and in your brain you're filling in the gaps because you know it already. And then, to the point that you brought up, you have someone else read it, well they don't have those. Those gaps aren't filled in, in their mind. That's a really good point to bring up. The ability for someone else to read it, comprehend it and be up to speed is something you should always shoot for.

Mark Ross: That's the other reason we say to avoid writing too technically, or writing with jargon, because that will automatically put you in the place where the user doesn't know what you know.

Mike Gerholdt: Yes. Let's tackle what is near and dear to just about every question I feel like I read on the community, which is error screen or error messages, and my flow doesn't work. Because in your mind, I feel like we're set up for success. Everything comes with a kit now, and a user guide, and you dump it out of the box, and you flip through it, and you snap everything together and boom, you got it. But with flow, you get to experiment, and you're working with data, and rules, and limits. Sometimes, stuff just doesn't work. How do you approach an error message? And what are you looking for in documentation that helps give you that moment of I know what to do next?

Mark Ross: Boy, error messages. They're actually one of the hardest things, in my experience, to work on because you really got to make sure from a Salesforce perspective that it's right.

Mike Gerholdt: Right.

Mark Ross: You've got to make sure you've got all the context, and that's absolutely critical. If you're going into an error message, you want to be sure you understand under what circumstances could this appear. Is it only in the UI? Is it going to also potentially show up in the API? Or, is it API only? If I'm doing some sort of push via API of a flow, is that the only way I'm going to see this error? That's really critical.
You have to keep audience in mind as well. If you're pushing something API only versus UI only, well API only, you're probably going to have developers, and architects and highly advanced admins doing that, as opposed to something that appears just in the flow build of UI. Well, that is going to be anybody. Entry level flow people, they're going to see this as well. We have to keep in mind audience, who we're talking to, what level they're at as well.
We also have to take into consideration when this appears, what could cause this to appear. And, is that going to necessitate how we're actually writing this? All these little details are why error messages are really one of the hardest things we do. It's actually one of my projects that I've been banging my head against lately, is a big set of error messages, because it is just so demanding. And, taking it in front of the developers and the engineers and saying, "Hey, does this look right?" And then taking it in front of the editor and saying, "Hey, what do you think of this?" It's this back-and-forth process where we have to make sure this error message is really going to communicate, as clearly as possible.
And even then, these error messages are often going to be very specific. The devs, the engineers, they can only do so much. They really do try to cover every base they possibly can, but there's nothing anybody can do to prevent any given admin from getting an unhandled fault for just some random thing that nobody could have predicted. That happens nine times out of 10. But, I have seen with my own eyes just how much effort they put into covering all the bases, because I know how many error messages I have to write.

Mike Gerholdt: Yeah, I can only imagine. The complexity, you have to think about how do we word this encompass quite a few things, too.

Mark Ross: Exactly, exactly. While not getting too out of hand, or being too narrow, so that it doesn't cover all those bases.
The other thing ... Sorry, this is actually really important. I should have said this. The other thing we try to do in our error messages, and I would recommend to anybody else whose doing anything like this, also include what the person whose reading the message can do.

Mike Gerholdt: Ah!

Mark Ross: That's a really important thing. Because if you're just saying, "Ah, this broke," that's not helpful. But if you're saying, "Hey, this didn't work. Try doing this. Or, remove this faulty thing. Or, add this first." If you're able to provide some amount of instruction, you're automatically putting your users in a much better place than they were before.

Mike Gerholdt: Yeah. Thinking through, because you're not there when the error message fires. You could be heading home from work, or walking the dog, or doing something and somebody in a call center hits an error message. It's not like they have you immediately on speed dial, and they need to know exactly what to do next, so I think working through that. I also think a lot of the questions that I see in the community, too, are they're getting error message while troubleshooting a flow, and trying to work through some of that documentation as well.
From a documentation standpoint, which I thought it was interesting to take this approach for a pod because we've talked about flow a lot and I've seen some really complex flows in my days. I've seen some really simple ones that have done amazing things. But, I think it's another one of those things that we document at Salesforce, that we put documentation out, that we want our admins to document, of course. As admins are going through and there's new features added, what is one of the things that you feel is foundational to understanding flow and automation, as opposed to chasing all the new shiny?

Mark Ross: Do you mean foundational in terms of it's one of the first things you need to grasp before you can grasp the whole enchilada? Or, do you mean a greater concept?

Mike Gerholdt: I'll give you an analogy related to cars. I feel, in my opinion, in order to learn how to really be able to drive a variety of vehicles and be a good driver, you need to know how to drive a manual stick shift. If you know how to drive a pre-1980 stick shift vehicle, you can drive anything.

Mark Ross: Oh boy. Wow. Okay. Because I can't do stick shift, at all.

Mike Gerholdt: Well, that to me is one of those foundational ... Because a lot of things have steering wheels, but outside of power steering and them sticking a million radio buttons on the steering wheel, that hasn't changed, but the way vehicles move forward has changed. Now granted, I'm all in on EVs, and the power cycle, and everything how cars are evolving, but manuals are going to be around for while and it opened you up to a whole world of vehicles that are very exciting to drive. I feel it's foundational because you also understand the mechanics of how the car moves. I've had to explain how you have to let off the clutch and give it gas, and it gives you an idea of what's going on in the vehicle. You don't have to do that with an automatic as much.
So what I was thinking of is, for example in Salesforce, I remember to the day that I was in the Admin 301 course with Wendy Braid, and she wrote on the board how objects relate to each other. She explained that, and man, I got it. It was the first time I got it. I felt like ever since then, it's just been knocking over cards to learn new Salesforce features. Because once you understand how objects and stuff related to each other, to me it was caveat emptor, I can learn this product now.

Mark Ross: Gotcha, all right. Man, okay. Well in that context, picking only one is difficult.

Mike Gerholdt: Well you're the guest, you can pick two. I just ask one.

Mark Ross: Well if we're talking a single thing, it's hard to pick just one. I would say variables is definitely one of the big ones. If you can understand variables, then you can handle almost anything in flow. Not just the concept of variable, even though I know that is one of the first hurdles that people have. This idea of okay, here's a place I can store something. Okay, that's great. Now that you understand what a variable is, now you have to understand how you can use it, and all the different types of variables there are.
There's the variable itself, which is just a normal place to store data. You also have things like formulas, text templates, record variables, these are things that are also critical. They're ways that you can store information, and calculate information if it's a formula, that can then be used in other places. And then, you have to understand where are all the different places I can use this. And in flow that's practically everywhere, that's one of the prime realizations. It's this idea that okay, well I've made a variable, now what do I do with it? It really is anything you want. You can use variables here, here, here, here, here, here, here. Same thing with formulas, same thing with text templates, same thing with record variables. If it's something that you can make that's like a variable in Salesforce in flow builder, it can be used almost anywhere for any purpose.
And then, there's a whole nother level up from that, which is okay, how do you use variables properly instead of using them in not necessarily good ways like loops. You don't ever, ever want to do a get records and update records, a create records, inside a loop. You don't want to do that. Instead, you want to do that before you loop and store it in a variable. So that later on, within the loop, you can actually go use that information. That's just a general practice of get all your data, manage all your data as much as you can before the loop.
Variables, I really feel are the one thing that, one, people look at as the first big hurdle, the first big thing that prevents them from using flow. But then, it also is ... It's like stick shift in that way, right?

Mike Gerholdt: Yeah.

Mark Ross: It also is the thing that, once you get it and once you know how to use it, you can do practically anything.

Mike Gerholdt: I think that's good advice. I still am learning variables.

Mark Ross: I can't really hear you. Should I hop off the VPN? We might have to use chat, because I've completely lost audio I think.

Mike Gerholdt: So true to COVID times, we had the internet drop out from underneath us so we got the last bit of Mark's answer and we missed the wrap up. So I will say thank you, Mark, for being on the pod, that was fantastic. And, here's the three things that we learned from our conversation with Mark.
First is there's a lot of documented sources from release notes, to help, to Trailhead, and they're all there to help you understand more about flow and Salesforce. You don't have to read them all. So go through things very diligently, and look for information that is relevant to you.
The second is be cognizant about writing your own documentation. Use simple terms, and think of it as making sure that your users are there when you're not. I would suggest, for sure, having someone else read your documentation. You can always revise it, you can always revise it.
And the third thing, I learned this asking Mark about what we should understand about flow, learn your variables. That seems to be, really, the one thing that you can do to understand flow. And once you understand that, as Mark said, you can do practically anything. So jump on over to Trailhead and learn about, well, practically anything with variables on flow. So that was super fun.
Speaking of podcasts, in today's all digital world, being able to learn in demand skills is really more relevant than ever. You can access all of the amazing Trailhead content that you love, including 1000 plus badges of marketable skills, trail mixes and Trailhead live, all from your phone. This is my plug for you to go, download Trailhead Go. I'm going to put the link in the description, there's a link that you can go to, you can download it. Or, you can search Trailhead Go in the Apple App Store or on Google Play.
Now, if you want to learn more about all things Salesforce admin, go to admin.salesforce.com to find those resources. You can stay up-to-date with us on social, we are @SalesforceAdmns, no I, on Twitter. Of course, you find my guest Mark on Twitter, he is @MarkRoss__C. Bet you know what that means. Gillian is also on Twitter, she is @GillianKBruce. And, I am @MikeGerholdt on Twitter. So send us a tweet, let us know if you loved this episode and suggestions for people we should have on. So with that, stay safe, stay awesome, and stay tuned for the next episode. We'll see you in the cloud.