Unpretzeling Your Org

One of them actually loves cats on my keyboards.

Is it just cats, or do you have some dogs too or any any other furry critters?

No. I have I've maxed out on the cats. So I used to work with the rescue before I moved down here and I ended up fostering for them and I failed at the fostering and became an owner instead.

It happens a lot. So we've got some people starting to join so we'll just let everybody know that Michelle and I are just gonna sit here and chat for a minute and we're going to let the people show up and then we'll go from there.

Absolutely.

I think it's actually really fun to do these just because you get to see a glimpse into what somebody is like as a person. So we're also used to putting on a professional front and we see them at the office or you see them at the conference.

So this whole kind of coronavirus thing has really given you the ability to welcome people into your home to a certain degree. And so I absolutely love welcoming people into the chaos. I've decorated my whole office and Salesforce stuff and cats.

Well how many Dream Forces have you been to?

Two! We started sending employees to Dreamforce in twenty eighteen and I am actually thrilled that I have gotten to present at both Dream Forces I attended so.

Oh cool.

That's been really exciting.

Cool.

Well let's see here we'll give it another minute. Let's start at three zero five if that works for you.

That works great for me.

Okay. Good. So, yeah, I just I was a participant. I was there in twenty seventeen, I think. Twenty seventeen.

Well, have you gone to any virtual con virtual conferences this year or any participating virtual events?

Yeah. It's actually been really interesting. They did a twenty four hour straight virtual Dreamin' since all of the Dreamin' events throughout the world really have also been canceled. I was slated to go to four, five of those, but they had come up with this even before COVID actually.

And it was really well put together. I think I managed to make it through close to twelve hours of it before I'm like, okay, I've got a little bit of fatigue here with the whole virtual sitting in front of a computer. But yeah, I mean, they had a virtual expo and they had breakout sessions and keynotes and they did it all through a really cool interactive virtual platform.

So between that and Trailhead DX, which they did virtual and I attended that this year. So it's been interesting.

That's neat.

We hosted a virtual conference a couple months ago. That was a lot of fun. It was one of the first ones just we had already planned on doing it virtual and then you know the lockdown happened. And so the good things I think were the talks are good I think where things where there's really room for to do something with some software, clever software is is the interaction. We had a Slack channel but I think you could do more with the, you know, you wanna kinda record, you wanna record some of the sessions but you don't wanna record them all, you know.

So was pretty, it was really fun to talk to all these people and then the thing that I think would really be neat, I think there's a piece of software out there waiting to be written to just get people connected before and like keep a community going around the conference while it's going on. So next time we do that, I think we're gonna look for something like that. But it was fun.

Anyway, I think it's three zero five.

So I think I'll just officially introduce Michelle. Michelle Hansen, she's a senior sales force administrator at a technology co op called NISC which is an interesting thought. There's such a thing. And Michelle is gonna talk about un pretzeling your org, your org. I think she's un pretzeled hers already. And it's a topic that she knows a lot about, she's presented on before.

And so without further ado, here's Michelle.

You can stop sharing. Want you to share, Michelle.

Alright. Well, let's see if I can actually manage to work with our technology today and get this screen shared out properly.

It's always it's always a challenge. There we go. I'm seeing it. Great.

Fantastic. Alright. So welcome, everyone. Glad you're here. Just wanted to let you know a little bit about me first. I am a senior Salesforce administrator at NAIC, as Leonard said. I've been working there for about eleven years and I've spent probably about eight of those working with Salesforce.

Really, I've been focusing on being an admin full time for about the last probably four years now.

So in that time I've managed to achieve Ranger status and I've gotten nine certifications. I also work with the Trailblazer Community both as a mentor and as a community group leader and Lightning Champion. So absolutely love presenting, do it all the time, thrilled to be here.

So thank you all for coming.

Okay, so we've got half an hour and a lot of ground to cover. Essentially we're gonna start by talking about why documentation is important. Then we'll move into the types of documentation that you really should have for an org.

We'll talk a little bit about how you can document processes because that's something that's a little bit less intuitive for a lot of people.

Then I always like to wrap it up by kind of giving you your marching orders. So where do I start now that I've convinced you this is something important that you need to do?

And there's always help out there. I don't wanna leave you stranded or feeling overwhelmed. So we'll finish up by giving you some more resources so that you can continue your journey with documentation.

Okay, so first up, why is documentation important? And usually I would do this through audience participation, but since we're on a webinar today we'll dispense with the audience participation some of the things that I hear most often.

I need to understand what the org looks like today, because if I don't, then I'm pretty much stuck for two reasons. Number one, if I don't know what it's supposed to do, I can't figure out if it's actually doing what it should or not when I'm troubleshooting. And how do I know what to develop if I don't know what's already there?

Documentation also can double as your training material. So a lot of people feel like it's just a waste of time and it takes too long, but being able to get kind of double duty out of it really makes it better for you to make that case to whomever else, be it your boss or your team, that this is important.

And finally, it helps give you job insecurity. And most people are like, what's job insecurity? Don't I want job security? Don't fire me.

And yeah, that's true. We'll talk about that a little bit more in a minute. But have you ever been passed over for a promotion or had your boss tell you that I just, I can't afford to lose you?

That's kind of the thing that we're going with here is sometimes you can put yourself in a position to your career or prevent your future growth because you've done such a great job of making yourself indispensable. So there's a kind of a fine line in there between being secure but not too secure.

So, okay, if it's so important and I've given you some pretty darn good reasons why, then why isn't everyone documenting their org?

A lot of people will say, just, I don't have time. I've got other projects that I need to get to and so I need to focus my time on creating.

Documentation's just gonna have to wait or I'm not gonna do it, too bad. Or perhaps it's, well, it's somebody else's job, especially if you have a team that you're working with. So maybe there's a business analyst or someone who's developing those requirements and user stories. And then you have a developer and admins.

And so some people are under the impression that, well, the developer wrote the code, so they should be documenting it out. And then the developer's like, well, no, I just wrote this little bit of code, but it's being deployed by the admin team. So the admin team should be responsible for writing the documentation. And then everybody turns around and says, Well, the analyst is the one who wrote all the user stories.

And so clearly, if they're the ones who know what it's supposed to do, they should write the documentation.

It's always a fun game of finger pointing.

For some people, especially when they're new to Salesforce or they walk into a very large org that hasn't been well maintained, they're not really sure where to start. And sometimes it's that overwhelming feeling of, I don't know where to start, so I'm just going to not look at it and pretend it doesn't exist and maybe it'll go away.

A lot of people think it's too expensive. Well, we need documentation software and we need to get all of these fancy tools and we can't afford it. It's not in the budget, so I'm not going to deal with it. And then finally, as I mentioned, kind of the opposite of that job insecurity is the job security. Well, if I know how this works and nobody else does, well, they can't fire me. So it's in my best interest not to let anybody else know how this works so they can't ever get rid of me, which works great until you're the one who's ready to leave or move on.

So, okay, if you're in a position where the value of documentation isn't very well understood by your supervisor or your team, it's a good thing for you to be able to make that case. And so there's three key aspects that we'll talk through that you can use to kind of convince them of the importance of doing this.

So first, accelerated development schedules. If you know the current state of the org, it's much easier for you to start designing towards that future state. If you have to actually go back and understand what that current state looks like, it's going to add up in terms of time. So I've thrown just some examples of different things that you may need to do as an admin. So if you need to go look up a field and figure out what it does, and this assumes it's maintained well in documentation so that there's a description that actually tells you what it does, that's probably gonna take you about three minutes. Same thing for accessing a page layout or examining an email template that's being sent out with some sort of an email alert based on activity that goes on in your org.

Depending on how complex it is, Reviewing formulas, formula fields, or workflow rules and validations, those could take you about five minutes to work through each. And so if you have to do more than one of these for the particular project you have, start adding that up. Processes or flows might take you ten minutes, may take you thirty minutes, may take you more depending on the complexity. And this is just what I'm looking at from an admin perspective. We haven't even factored in looking at Apex code.

So if we say on average, it's gonna take you a day, eight hours of your time, to go back and look through what is in your org.

On an average salary of seventy five thousand dollars a year, that adds three hundred dollars in costs to that project and a day of time to do it, which is in addition to what you're not working on because you're going back and doing this rework.

And that doesn't seem like a whole lot, but it starts to add up when you add that to every project that you're doing.

Also troubleshooting.

You need to understand what the expected behavior is. So how is it designed to work? What is supposed to happen when the user does A, B or C?

And then how can that compare to what the actual behavior is that you're seeing? And especially because we want to know how it's designed to work, it's good for us to be able to compare that to what is the user actually doing. A lot of times you can find out that really the error you're getting is because of your user as opposed to a problem with your Salesforce architecture.

Because maybe they are a very creative user and I've had a few of these that has decided to co opt a process for something you never designed it for.

So clearly the actual behavior is not what they expect. But that's because the expected behavior isn't what they were looking for. So it is working as designed, it's just not doing what they thought it should or they're using it for a different case.

Now where this really adds up is training time. As I mentioned, your documentation can double as your training material.

So if you take a look at how much time it's gonna take you to train a new user, someone walks into your company, you're using Salesforce, they've never heard of it before, we've gotta start from scratch. This is how you use an account. This is what an opportunity is, those kinds of things. It's probably gonna be a solid hour or two for you just to go through how you navigate Salesforce and use it with all of the objects that you've put in your org.

Then when you add in training them on the processes that your company has built into Salesforce, maybe it's your sales process or it's case processes for customer support, conservatively, we're gonna say another four to eight hours of training on that. And that assumes that you train them once and it sticks and you're done.

Then every time you add new functionality, we need to train them some more. So if you create things that are new, probably thirty to sixty minutes worth of training. If you update a process that they're used to and change it, that's probably another thirty minutes that you're gonna spend teaching them how to redo the process this new way.

And then of course, everyone pays perfect attention in meetings, right? You've never had anyone else answering emails, taking phone calls, stepping out, having dogs and cats barking in the background as we all work from home. So now more than ever refresher training becomes important because someone wasn't paying attention or doesn't remember because it's been a while since they've had to do it. And so they ask you to walk them through it again.

Depending on what the process is, that could be anywhere from ten to thirty minutes. So when you start to multiply that by how many users you have and how many topics you could be training on, that could be days, weeks, or even months of your time that's spent going back over things that you have already trained on. And so again, if we conservatively estimate that at two weeks a year, that's almost three thousand dollars in your admin time alone that they are spent retraining users and not getting other work done because we're going over already covered territory. And again, we're not even taking into account a sales manager salary or some other employee salary that has to be spent getting retrained and what work they're not doing.

Okay.

So with that, let's keep that in mind in terms of why it's important. So what sort of documentation should we actually have to be effective?

First of all, there are three different types, and I wanna talk about customizations of your org, then focus on documentation specifically for your users as opposed to your admins or developers. And then I wanna get into process diagrams, are very useful for both because I wanna talk about both your business processes as well as any automations that you've built into your org, which is often overlooked.

And all of these things together, plus some other choice morsels become what I call an admin handbook. And the admin handbook you can kind of think of as if you were to go on vacation for a month and you needed to leave your org in someone else's hands, what do they need to know to keep it running until you come back? And more importantly, what do they need to be aware of that they shouldn't touch until you are back because there are some things that you should have the admin handle?

Okay, and as we're going through this, there's some considerations I want you to keep in mind. While you're writing documentation, you need to keep in mind who your audiences are. There's not going to be just one person that you're writing this for. And if you are, that means you're probably writing multiple versions of documentation which you don't really wanna do.

So think about the different people involved in your process. So your inputs, your main actors, your outputs. For example, if we're talking about expense reports, your inputs are your sales rep that needs to actually put in their expenses into the system.

The main actor then is going to be that employee supervisor who then reviews the inputted expenses in the expense report and then creates the output, which is the approved expense report document that then goes to accounting. So accounting is also an output because they're the ones that are going to get that and then have to do something with it.

So some of these are users, Are all of them? Are some of them management? Do they want a little bit less hands on? Are some of them admins that will have a much deeper knowledge of the platform and be able to kind of speak the lingo or understand some of the acronyms that you may be used to whereas other users or management may not.

What are their knowledge levels? Are you writing this for the new employee that comes off the street that's never even used Salesforce before? Or is this targeted towards someone who should have an understanding of some of the processes in your organization?

Or again, if it's an admin, they advanced or are they a power user maybe? So that you can basically skip some of the easier steps and go right to the heart of the new process.

How it's going to be consumed more than ever these days is important. A lot of us have started to move away from working every day at a desk or a laptop with a computer.

So it's great if you're writing in a Word doc and you put it in a PDF and you throw it in Salesforce and someone access it from their PC, they can pull it up and it's no problem. But what happens if they're on mobile and they need this to be mobile friendly? If you've ever tried to actually read a PDF document on a screen that's about four inches by five inches, it's really difficult and it's very small. So was there a way that you can put it together differently that makes it mobile friendly?

And also, if you have any of those old school people that every time you send them documentation, the first thing they do is they print it and they put it in a binder on their desk, That's going to be a challenge you have to work with because they need to get an update every time you make changes. And again, this format doesn't just have to be paper or PDF, like the electronic version of paper. Again, if you're going mobile, can you do something different? Maybe it's a YouTube video or a TikTok video, a walkthrough or something that they can actually see and access easier from a mobile device.

All right. So documentation types that we're gonna go through. First of all, we wanna talk about your customizations in Salesforce. And so validation rules and formulas, custom objects, custom fields, All of this information really should be documented in Salesforce. They have a description field there for a reason. They have actually expanded recently out to more fields about the level that this goes to, is it internal or external?

Who's the owner of this data? So if we need to get it updated, we know which group to go talk to. But it's more than just putting a description in the name field that says this is the name of the record.

I can probably figure that out from the title. But why are we putting it in here?

How is this being populated? Is it part of an integration to a third party system? Is it filled out through automation? Is a user responsible for doing this? Those kinds of things help you understand how this gets populated, where else in the system it may be used, if it's in a report or something like that, so that you understand the impact of other changes that you make in the org and you make sure that you don't delete a field that all of a sudden it disappears from fifty or seventy reports.

Comments.

It's actually really cool. You can do this in code and everybody's pretty familiar with that, but you can also put it in your validation rules and formulas. And so what you can do is you can write out what you're trying to do in English. I wanna look and see if the opportunity stage field has been set to close one.

And if it has, is this timeline field blank? If so, throw an error. So now that I've written that out in English, I can then translate it into a formula, which then makes it easier for admins after me to come and actually understand what it's supposed to be doing. Plus it's a great way to make sure if you have multiple criteria that you're using your ands and your ors appropriately.

So you can do this in a spreadsheet, and I'll show you a couple of versions. And you can do this by object or by release, which is how I tend to do it.

So by object, I'll have a link to this later in the presentation, you can actually pull in all of your different fields. All of the information about those fields is shown here, and you can even show which record types they're assigned to. So it gives you a really good one stop shop to look at where is this field, what's it used for, what are the impacts of it.

By release, I use this as my checklist when I'm ready to move things between orgs. So when I'm working in a sandbox, everything that I build, if it's a custom field or a custom object, page layout, validation rule, flow, I write everything down in here and then I use this as my checklist when I'm ready to move it. And I can go back and see when things were added because it's by release.

Okay, second type of documentation we need to have is for our users. Number one, release notes. And quite honestly, Salesforce is a huge company. If release notes are good for them, it's good for us. It keeps your users up to date on the new things that are impacting their job. And so you can be a little creative to make sure that they actually do get read because I can tell you from experience throwing in an email and letting my users know there's new stuff out there generally makes it to the bottom of the reading list, not the top.

So here's an example of what I do for release notes. I make sure I put the date of the release and the platform version that it was on. Then I have a highlight section that gives us kind of a one page overview of all of the things that I've released. And then a footer at the bottom that makes sure everyone knows this is internal only so my legal team doesn't get upset with me.

Then each expanded section, I actually put the icon that relates to the object in Salesforce that we're talking about to start solidifying some of those relationships.

And then after I've explained it in detail, if it's pretty complicated, I will actually put together how to documentation and add a link to that right in my release notes.

So speaking of how to documentation, this is basically where I go for users that are new to the system or new complicated processes.

It's step by step instructions. If you remember the idiots guides to everything from the 90s and 2000s, you could learn how to do pretty much everything and it would take you from the beginning. And this is my goal. If someone walked off the street and into my org, would they be able to take this document and complete this process without any assistance beyond the document I gave them?

You can also do this with in app guidance, which is new with summer nineteen. So definitely I encourage you to use the option that works best for your users.

So again, some of the things that we do here, I use a lot of screenshots, I use a lot of numbers if there's things that need to go in specific orders.

I always put in kind of a what's in it for me section because again, if someone doesn't understand how this impacts them, they're not going to bother to read it.

And then I use formatting in Word to hyperlink it so they can jump to appropriate sections if it's a multistage process.

All right, process diagrams.

These are supposed to be a visual representation of a process that is much easier to understand. They always say that a picture is worth a thousand words, and that is definitely true for processes. I can write a fifty page document that explains every step, or if I can put together a one page flowchart that you can follow, that's gonna be a lot easier. Plus it helps you document the current state of what's happening today. And then you can add to it and say, okay, this is what we do today but here's the future state I wanna get to you. And what are the steps that it's gonna take to help me move from where we are to where we want to go?

You can also add multiple layers in most of the tools out there so that you can have different levels of complexity or information based on your audience. So what you're gonna show to your managers is gonna vary widely from what you show to your users that need to use the process every day and then what your admins are gonna need to see to build and support it.

Okay, so how do we document processes?

There's a few different ways. Business processes have a lot of different options. So this is called the SIPOC diagram. It gets your suppliers, your inputs, your processes, your outputs, and your customers. And so basically, this is identifying kind of who's responsible for what.

This is great if you're really trying to ascribe responsibility. But what it doesn't do very well is show you kind of the steps.

A top down process map is a little bit better because it shows you the start of a process and it actually gives you the ability to have a couple of different layers so that you can drill down into it if it makes more sense.

So the top line, the boxes could be for your management, the detail steps below may be for your users.

So doesn't necessarily show who's responsible for what, but it gives a good progression of how you get from the start to the end of a process.

Flowcharts are always great if you have decisions and logic. If the answer is one thing, you go this route. If it's another thing, you go a different route.

So this is definitely kind of a step up from the other two, but we can actually improve on this a little more by adding swim lanes, which not only gives you the flow chart concept, but also starts to show you who's responsible for what.

The one thing that always kind of throws me with these though is they have all these different shapes to represent different things. And quite honestly, I can't remember what they are. So something I found recently is called universal process notation. And it basically combines all of these together and it just uses boxes and words, which everyone can understand and follow, to walk you through a process. And so every box is what's happening and who's responsible for it. Then you have the lines that will show you what happens next.

And this is basically the why of where we're going for the next step. So you can still step through the process. It still gives you the ability to have branching logic.

And depending on the tools you use, again, you can make attachments or drill down so that if some of these are processes of their own with additional steps, you can link them all together.

Automations also need to be documented. And a big reason I say this is because a lot of times in your Salesforce work, you're going to have automations that cross different objects or impact different things. And if you don't keep all of that in mind, making changes to one object can definitely lead to problems elsewhere. And I've run into this myself.

So this is gonna help you understand different things about your org. So what exactly was selected? What are the objects that were involved in this process? Is it running in user mode or system mode? What kind of permissions do they have?

And then what actually happened? So again, when you're troubleshooting, by documenting out all of these different things, when someone comes to you and says, I don't know if this worked right, you can follow this diagram and figure out if it did or not, and if not, why.

So we'll take a quick example, closed won opportunity. Everybody's really excited when we win new business, right? So the sales manager goes in, they update the opportunity, closed won, an email alert gets sent out that we won new business. Everyone's excited. Pretty simple, right? Two steps?

Well, when I started to dig a little deeper, no, there's a lot more than that that happens. So the opportunity's updated not only by the user, but also through automation.

It's triggering a process. The process calls a flow and actually also calls a second process as well as does some updates.

The opportunity products flow fires, and it actually updates the opportunity because it's looping over my opportunity products. And then that invocable process is used to send out an email alert based on a specific email template.

So now all of a sudden we've gotten a little more complicated.

So to document this, I started by identifying everything that's part of the process, whether it's a person, an action, or something that's acted upon, or dependent on something that's acted upon. So for example, I've got my salesperson, the process, the flow, my opportunity and my products, and my email alert and templates. So when we go through here, this is what's happening by or to each of these different items. The salesperson's updating a stage on the opportunity.

The process gets called because that was updated. It's accessing a flow. It's updating an opportunity field and calling an invocable process. My flow is looping through my opportunity products and updating an opportunity field. My opportunity, again, is being acted on, so I need to keep it in here.

My opportunity products, the fields and the records of those opportunity products are being looped on by the flow. And opportunity products are being created from actual products, so I need to keep that in scope because if I make changes to products, that may potentially impact something upstream.

And then of course my email alert gets called by a process and that email alert is tied to an email template. So I need to make sure that that's top of mind in case I'm trying to make changes to my email template.

So here's what this ends up looking like when I dig into it. Customer signs our contract, the sales team updates the opportunity, because of that, the process fires, the process fires and updates a field, calls a flow. I actually have a sub process down here for what the flow actually does, but I've also itemized out each of the pieces within here that are impacted by this step of the process. And so this is an easy way for me to have a one page document that I can go and look at and see every single object that is being acted upon by my foil.

Okay, so I know we're running short on time. I wanna make sure that I get through some of the rest of this. But where do you start?

Start where you are. If you need some suggestions on where to get going, number one, what's business essential? If you won the lottery and quit your job tomorrow, what would they need to know to keep things going until they could hire another admin? And then also, start from now. The next thing that you do, start documenting it. Use these things to make sure that you're not getting more technical debt or more pretzels in your org because you're not documenting. And then it's less for you to go back and have to fix if you start from now.

Finally, there's a lot of different tools that you can use.

Now, some of these I have used, many of these I have not, so I really can't speak to how well they are gonna work for what you want. But for documentation, there's a lot of things out there from elements. Cloud down to field footprint or a field trip that are AppExchange apps you can download. Some of them are free, some of them do have a cost or they're paid in free versions of both.

For process mapping, things like Lucidchart, Draw. Io, I mean, even Visio or PowerPoint can be used for that.

Wiki documents are not terrible. Sometimes it's good just to have things that you can go back in and document all of the kind of the weird foibles in your org. So Confluence, a Google site, building it in Salesforce even is a great way to make sure that your documentation is around.

Then, I mean, you can start with something as easy as Excel. So if all you have is the Excel suite or even Google Sheets, you've got enough to start documentation and there's no excuse for that. If you wanna go with training videos or walkthrough snippets or anything like that, Camtasia down through Zoom all have really great tools to grab screenshots, to do walkthroughs, video editing, all of that great stuff.

So Dreamforce nineteen had quite a few sessions on this and you can go and access the recordings from the Dreamforce site. So I like to include these in case you're looking for some more information.

And these include how to document Salesforce within Salesforce, how to use Quip, all sorts of great things to help you build your documentation.

And then of course, there's different styles out there. Everyone learns and does things little bit differently. By no means am I the only expert out there or even an expert at all.

I'm learning right along with the rest of you. So here's some more readings and videos. Here's one of those wiki pages that you can go and you can actually look and see what some other people have done. Find the style that resonates best with you and start instituting that at your org.

So several of the things that I showed here, I have links to all of the templates. And so you are more than welcome to download these and start using these.

Some of these are my own, some of these I found elsewhere on the website or on the internet. So by no means do I take credit for the content that's here.

So with that, wanna wrap it up and leave a little bit of time for questions.

So again, thank you for inviting me to present here. And I guess we'll see if we've got any questions.

Thanks Michelle. Yeah, we do have a question. Attendee asks, how do you ensure your documentation is simple for your team to understand? Simple enough maybe is what they mean.

Sure.

That's kind of something that has to be done more by feel.

The biggest thing I've noticed is the more I get into Salesforce, the harder it is to look at it with fresh eyes. So find somebody with fresh eyes and ask them to review the documentation and see if it makes sense.

I know Salesforce in and out, I've built most of our org, it's my baby. So if I take my newest user and hand them a document, I'll go, okay, I'm working on documentation, I need you to see if this makes sense to you. And if there's anything that you have questions about or that isn't clear, then come back and let's talk about it and I'll modify my documentation as I go. And then in the future I can remember why that wasn't clear. So do I need to break it down into smaller steps? Did I use terms they're not familiar with? And I try to make those adjustments as I go so I don't do the same thing in future documentation.

So short answer, ask them.

Yeah, that's a great piece of advice. You know, I really liked the slide on cost savings.

Have you actually used that technique with your management to try to, know Worked truly in I haven't had to.

So, but yeah.

I think you work in a good place.

I do. I'm actually very fortunate to have a great team that backs me up and we're expanding our use of Salesforce quite a bit. So they've really embraced the platform and the opportunities that it offers. And so I'm very fortunate to be where I am and to be able to work with Salesforce the way I do.

I don't wanna turn this into commercial but are there some is it are there any of those documentation tools that you found more compelling that you use? I mean, looks like from what your examples you used, you just use base good old Excel and good old a word your release note which looked really nice by the way, looked like a word document.

Yep. So release notes right now we do in word, how to documents as well. I'd really like to get some more of that and then I post them into Salesforce's files so they're accessible. I'd like to get more of that into Salesforce.

Quip would be amazing if we ever got that to be able to do a lot of that with as well.

When it comes to being able to do some cool stuff with documentation, I can't say enough good things about elements. Cloud and spec it.

Both of them have a cost. Elements does have a free version for process mapping, which between Elements and Lucidchart, those are probably my top two favorites.

There are going to be limitations with the free version, so just be aware of that.

But I mean, if you can use one of those, those are probably my favorites that I have used. There's many of them on here that I have not gotten a chance to use.

ScreenFlow, Vidyard, I know about them, but I've never had a chance to use them. Metazoa, I've seen some demos and it looks pretty cool.

But a lot of these, especially when they're AppExchange apps, they actually get in and start digging into your metadata and can tell you a lot. Elements. Cloud, for example, will tell you what your field usage is and what the impact is of changing that field based on how many other places it's used in your org. Is it in your automations? Is it in your reports?

If I delete this field am I going to blow up the org?

So for our EXPLORERCE conference, no plug intended but it is a plug. We did interview both Ian Gotts and Melanie Follet from Ian's from Helmets Cloud and he talked about the process flow diagrams and Melanie also talked about just basically how SpeckIt works. And honestly, I mean, so the way I'd characterize those two is elements is more of a administrator documentation behind the scenes type documentation I would say. I'm sure you could show this process diagram to users. And SpeckIt is more right in Salesforce document giving help, you know, on demand help for the at the user level.

Absolutely.

It's kinda like in app guidance on steroids with cherries on That's a good way to put it.

You know the other thing when I was listening to you go through all the I mean, user satisfaction I think is gonna be higher in a well documented org.

In fact, a lot higher. Because when you just throw somebody at Salesforce and it's all know, ask the guy next to you, the woman in the cube across from you or whatever.

Especially Ashlander, who is that these days?

I'm working from Yeah, right.

Exactly. Ask the per you know, it makes that makes the barrier even higher. Ask your cat maybe. But it seems that the it seems to me that in your organization, I bet your users are happy. Even though they nobody loves reading documentation, I bet you in the end it's happier than a place where there isn't any and there's no way to find out.

I don't know if I think we've definitely gotten better adoption as our documentation game has gotten stronger.

When I first got here, we didn't have a lot of documentation in there. There definitely was every time we get a new employee, sit down, hold their hand through it, and then one of their coworkers has to teach them the system basically on on ride alongs on handholds.

That's great, but what if I'm off that day and you have a question, there's no one to ask? If you've got documentation that you can refer to, you can at least try and help yourself. And we live in a world where really people are much more likely to use kind of self-service and they don't wanna have to call someone for help. So if they can do it on their timeframe with tools that are available to them, people are going to be happy.

And by helping them understand how to learn it, the adoption's gonna be there.

And when they adopt the things that you use, definitely they're happier because as an admin, your goal is to build things that make your users lives easier.

Got another question from the audience. Do you find that certain audiences, users, administrators, management, consume documentation differently or better? Desktop versus mobile versus print?

Oh boy. So it's not always users versus admins versus management.

The company I work for has a pretty big gap in tenure. We've got the people that we've hired straight out of college and we've got the guy that's literally been there for forty five years. He just celebrated a work anniversary.

Guess which one of those likes print better?

You are. Yeah, just because they're all users, sometimes it's the older generation that prefers paper and having something that they can physically refer to as opposed to documentation. But yeah, before COVID when people were traveling, absolutely most of the time my sales team would be out with a phone and a tablet. So something that they can get to you on a phone and a tablet is gonna be much more important for them than something that they have to be able to open an email and download an attachment.

And honestly, don't actually know if most of my management team reads my release notes. I can tell you that my manager does at least, because usually I get, hey, good job, this is fun functionality and I'm excited it's released.

But out of my one hundred or so users, I get about two or three of those emails. So I mean, what does that tell you about my readership levels?

The good thing is, is at least when questions do come up, I have somewhere to refer them back to and say, yep, we did document this. There is a change in Salesforce, you're right, you did catch that. Let's review what it is and if you need some more help, then we can schedule a meeting to walk through it.

Yeah, that's I think at some point people do learn when you redirect them like that. So we have couple minutes left.

Did you have anything more that you wanted to add about documentation or famous last words that you wanna give us?

Like your elevator pitch for doing this or something?

Honestly, anything is better than nothing. It does not have to be perfect from the beginning.

I'm presenting on this and I am by no means perfect because truthfully, it's twofold. Number one, to learn something. The best way is to teach it to someone else.

And number two, if I'm going to start presenting on this, you better believe I'm not willing to be a hypocrite so this forces me to do my documentation to a better degree than I might otherwise.

So sometimes that's what it's about. But anything is better than nothing so even if you start small, just make sure you start.

I think that's good to know because I think you definitely could feel overwhelmed if you just try to document your whole org at once but know doing the next feature it's always gonna work. So thanks, Michelle. I really appreciate your time and your presentation. I think it's a really important topic.

And I wanted to encourage everybody who's attending to to attend our next webinar which is going to be by Steve Marcel who's gonna talk about Einstein analytics and he's gonna use a superhero example. He's gonna talk about how you can, how different superhero information can be gathered through a Google Form and then using Einstein predictive analytics to say what kind of superhero you are. So we're anybody who attended the webinar is gonna get an email telling you about Steve's presentation. And before we go, I'll let Michelle show her her contact information, which we're also gonna send in a follow-up email to the webinar.

Go ahead, Michelle.

Perfect, yeah. I'm always happy to help the Ohana. So if there's anything you have questions about or wanna talk about further, I'm always happy for you connect with me.

Definitely Twitter is probably the best way where I spend most of my time socially with this, but yeah, feel free to reach out.

Well, thanks again. It was a great topic. Thanks for everybody who participated, asked questions, listened and we hope that we'll see everybody at another X Force webinar in the near future.

Bye bye.

Thanks again. Have a great day everyone.

‍