Welcome back to this series for the month of March, this is Flow Documentation Month. This is the third of five posts, so far we’ve already covered tips for creating helpful documentation and what you can do internally within Salesforce to document your Flows. In this post we’ll be covering the topic of what Flow Documentation you need most in your life as a Salesforce professional. Like with the other posts in this series, this is all based on my experience and personal opinions as an avid lover of Salesforce Flow.
This post will go over 3 documents you might want to consider using as you build up a suite of documentation relating to the Flows that you build. This list is not an exhaustive one, so if you have any documents of your own that you think are needed, I’d love to hear about them in the comments section below or online in the posts that share this link via social media. This post will include examples of how this will look if you implement these additional documents into your overall Flow Documentation efforts.
So, let’s dive in shall we? We’ll begin by talking about the first Flow Document I feel you need, that being a change log.
#1: Change Logs
The first document I want to cover in this post is Change Logs. As a Salesforce Administrator you may be already familiar with Change Logs in the work that you do. But in regards to Flow, I think that Change Logs can be a real benefit and a massive asset in your arsenal of Flow Building. My view here is that this kind of document doesn’t have to be complicated at all, rather it can be something simple, something that is used to convey important changes to the Flows that you build in your Salesforce org.
In terms of what I feel is needed in a change log for a Flow, I feel you need the following information:
- The Flow Version.
- Date of the change.
- A description of the changes made.
- Who made the changes.
- Who approved the changes (optional).
I include the point of who approved the changes as an optional item. The reason for this is because depending on how you govern the creation and maintenance of your Flows, you may want to have someone in your organisation approve the changes made to your Flows to assist with your automation governance efforts. The other items on my list in my view are completely mandatory.
When it comes to putting this document, my view is that this should be included as an appendix to the main document that you build relating to your Flows. In terms of design, a table should suffice for this in my view. Again, this doesn’t have to be anything too complex. In fact, the simpler the better as it will allow you to quickly update and maintain this aspect of your documentation.
Below is an example of what a change log could look in your Flow Documentation:
N.B. Please note that the word organisation has been flagged as being incorrectly spelled, it is however spelt correctly for us in the UK.
#2: Resource Glossaries
Next up is Resource Glossaries. Like with Change Logs, my view is that Resource Glossaries don’t have to be complicated either. But what do I mean by a Resource Glossary? Simply put, this is where we include a list of the resources included in the Flows that we build. A good Resource Glossary is less about noting down every minute detail about the resources we build in our Flows, and more about documenting what those resources are, what they do, and their overall purpose for being part of the Flow in question.
In terms of what we need to log in our Resource Glossaries, I feel the items listed below are the most important things to log:
- Resource Type (Variable, Formula, etc.)
- Resource Label (In many cases this will only be for the documentation)
- API Name (Make sure you document this, I’d also recommend using this to sort your Glossary)
- Description of Resource (include Formulas and Text Bodies where applicable)
The description is by and far the most important thing to include. Depending on the resource type, it might be beneficial to include the body of the resource. For example if you’re documenting a Formula resource, then adding the Formula body to that particular line of documentation may well be a very helpful to include. Likewise, if it is a Text Template, you might want to include the body.
In terms of categorising your Resource Types, my advice would be to go a little beyond the standard Flow resource type labelling. How I would do this personally is by combining the Resource Type and Data Type of the resource (if it is a Variable in particular). For example, if you’re building out a Text Collection Variable, I’d write that out as Variable: Text Collection in your documentation. Doing this will allow you to organise the resources that you include within your Flow to a much more beneficial standard.
Like with the Change Log, I feel this can simply be a table in an appendix of your Flow Documentation. The overall theme I hope that you’re picking up in this post is that this doesn’t have to be hugely complicated. A Resource Glossary is no different.
Below is an example of what I think a good Resource Glossary will look like:
N.B. I don’t think we need to document resources that are created through the addition of elements or Screen Flow input components. Components and Elements in my view should be documented as part of the main Flow Documentation you compile for your Flows.
#3: Scheduled Flow Calendar
The last additional piece of Flow Documentation I think you may want to include as part of your Flow Documentation efforts is what I’m referring to as a Scheduled Flow Calendar. Once again, this doesn’t need to be anything overly too complex. A Scheduled Flow Calendar is simply a Calendar that you will create where you add your recurring Scheduled-Triggered Flows in order to give you a very quick method of knowing when each Flow would be expected to run. Personally I wouldn’t add Scheduled-Triggered Flows that are only scheduled to run once. I would only add the Flows that are Scheduled to run on a recurring schedule.
The added benefit of this kind of documentation effort is that you can actually enhance it a little bit. By that I mean, you can log your Flows that will run on a recurring basis that isn’t what is offered in Flow Builder. By that I mean, if you have built a Flow to run on a monthly basis, you will have to use a workaround on a Scheduled-Triggered Flow to flag that the record in question fits within that monthly timeline (you can currently only create Scheduled-Triggered Flows that run run once, daily or weekly). When it comes to how to populate this calendar, obviously you need to be mindful of things like timezones, trigger objects and so on. Once again, it doesn’t have to be hugely complex, all I think you need to log here is the name of the Flow, the trigger object and the cadence.
One piece I will give at this stage before I show my example is to colour code your calendar entries based on cadence of the Flow. For example, if it is a daily trigger use a colour like red, if it is weekly why not use yellow, and for monthly maybe blue. The colour scheme is obviously completely up to you, my advice here is simply to use different colours for each of your trigger cadences.
Below is an example of how this could look in Google Calendar:
You will see from the above that I have colour coded my calendar entries, red for daily, yellow for weekly, and blue for monthly. This is based on the advice I gave above. You will also notice that I included the name of the object. This is something I would do even if you don’t use the object name in your Flow Labels. You will also notice that I opted not to use the API name for the entry, but instead the Flow label (or in this case a slightly amended one). I did this because it simply makes the entry a little cleaner.
In terms of the description one thing I would consider doing is including a link to your Flow and the API name for the Flow as well. I haven’t done this myself here as these Flows don’t exist in an org that I can showcase an example for right now as I made up examples of Flows that I would commonly build for the purpose of this post. But including some good information in your calendar entries description is something that will prove extremely helpful in my view. Again, it doesn’t have to be overly complicated, what you’re really looking for in a description is the provision of information that will easily allow you to check if the Flow has triggered.
One final note on the calendar before I move on to my closing comments. I have used Google Calendar in this example, but you can use anything you want really. You could use Outlook, you could even simply just use a table in a Word or Google Document. Personally, I prefer a calendar system for this, but as a Salesforce Admin you should pick whatever method works best for you.
Closing Comments
So that’s the Flow Documents that I think you need most in your life. In this post I haven’t gone over your main piece of Flow Documentation, rather I opted to focus on the additional documents you should consider using to up your documentation game. Now, I want to turn it over to you. What do you think of the list I included in this post? Do you agree with it? Are there any other additional documents you think you need for your overall Flow Documentation efforts that I haven’t included here? If so, I’d love to hear about them in the comments section here in this post, or online via Social Media where I share this post online. It would be great to hear your thoughts on this subject overall. Finally, this post was late due to how I was feeling post-TDX, so this week there will be two posts in this series. There will be this post and my fourth post in the series which focuses on naming conventions. So please do come back in a couple of days as my naming conventions post will go live on Friday evening this week. Next week, will be the last post in the series, there we’ll be talking about creating a Flow Documentation strategy. I hope to see you here next week.
