Right from the get-go, the possibility for Salesforce Admins to build custom-guided wizards has been a significant game changer. While they could have built other types of automation in the past using Process Builder and Workflow Rules, none of them allowed the capabilities and flexibility that Screen Flows bring to the table.
As the user will most likely have to navigate through multiple screens, especially in a lengthy process, wouldn’t it be great for them to know how many pages they have yet to go through? In this post, we will explore how progress indicators can be easily added to your new or existing Screen Flows.
The New Out-of-the-Box Indicator
Perhaps one of the most exciting Salesforce Flow updates in recent releases is the option to set up a progress indicator with just a few clicks! As of Spring ‘25, the option is available for selection within the Flow’s version properties screen, where you can choose between three types of indicators and see a preview of each when doing so:
- Simple: Top of Screen: This is a simple line, with dots representing each of the stages. The name of the page appears when the users hover over the dot.
- Path: Top of Screen: If you’re familiar with the Salesforce Path, this is almost exactly the same – minus the navigation and confetti. A path-like experience with the name of each stage written on each section of the path for users to easily see which step they’re at.
- Simple: Footer of Screen: This option is exactly the same as the first one, with the positioning of the line being the only difference, as it will be at the bottom of the screen instead.
After choosing the type of indicator, it’s all about navigating to each screen in your process and starting to use it! You can choose to use it for existing flows just as easily, and the steps will be the same. For this example, I chose an already existing, very simple Screen Flow used to create a contact, with just a few fields on the screen, a screen for the success message, and a screen for the fault path.
You will see a stage field within the Screen Properties where you’ll have to create a new stage resource – each resource will have the following attributes:
- Label and API Name: The label will be the name of the stage displayed to the user.
- Description: Not mandatory, but definitely useful for more complex screen flows where you may have different variations of the process.
- Order: This number is unique between stage resources. While you could use consecutive numbers, it is a good idea to future-proof your process from the get-go by leaving gaps between the numbers. Instead of using 1, 2, 3 etc. as the order, you could use 1, 5, 10 etc., which will make it much easier to introduce new stages later on.
- Active by Default: This option will become your best friend when navigating lengthy processes with different variants of stages. If this box is checked, the stage is automatically added at the start of the Flow Interview to the $Flow.ActiveStages variable. This means that the stages will appear on the screen by default for the user to see, and the values will, by default, be sorted in ascending order based on the order value above.
While in this scenario it’s very straightforward, you will notice below that the path can account for the more complex processes just as easily. Also, it’s always a matter of seconds to go back while debugging and change the name of the stages or the type if you wish. For example, since I used the Success stage for both the Success and Error screens, I went back and renamed it to “Confirmation” instead.
Controlling Stage Visibility
In real-life scenarios, more often than not, processes are not going to be linear and will contain some sort of variations based on different criteria. Within a screen flow, guiding users to different screens considering criteria can easily be done with Decision elements followed by Screen elements. This doesn’t have to change one bit – it’s just one extra element to account for in case there is a need for one or more stages to appear within the progress indicator in this context.
The stage(s) that should not appear from the get-go should have their Active by Default attribute set to false. This means that they will not be added by default to $Flow.ActiveStages. Hence, we will use an Assignment element to add or remove stages to get the order and stages we need.
In my example, the Additional Information stage should only appear if the account selected for the contact is located in the United States. Within the Flow, this translated into removing the last stage (Confirmation), adding the Additional Information one, and then of course, adding the Confirmation stage back as the last one in the collection.
Since $Flow.ActiveStages is a collection variable, you might consider trying to add the new Stage resource and then use Collection Sort to sort the list based on the Order attribute. However, the collection variable is not available within the element. Also, by simply adding the resource to the collection without removing the last one and then adding both back, the new one will be added as the last one, which is not what we’re looking for in this scenario – we want this to be positioned in between, as the second one.
Once the changes are saved, we can debug the Flow. Make sure to choose an account in the United States, and watch the Additional Information stage for the extra screen with the two additional mandatory fields, appearing right between the two stages that were active by default!
Dynamic Flow Progress
Although this may not be needed as often now that there is a native, built-in option that doesn’t require developer work or the installation of anything, there still may be times when a slightly different look and feel is needed. Dynamic Flow Progress is an AppExchange listing by Salesforce Labs, meaning it will always remain free to use while also passing the security review to be listed.
While you can make use of this AppExchange listing as it is, since the code itself is open-source, you can make any additional changes you’d like or need to adapt the functionality. Alternatively, if you would like to start from scratch, you could build your very own custom component and leverage the Flow Stage resources.
Build or Edit Your Flow
Once the package is installed, the custom component will become available within Flow Builder. You can build a new Flow from scratch if you’d like, but similar to the out-of-the-box functionality, nothing is stopping you from updating an existing Screen Flow to make a progress indicator of your choice available. In this case, I had an existing version of a Screen Flow with three screens available and chose to edit it. Since I am looking forward to making it clear what stage the wizard was at when the error happened, I will also opt to add the progress bar to that element.
The Flow itself is embedded on the Account Record Page and allows users to choose an open opportunity from the account and add the Decision Maker Contact Role to it. It is a good idea to add notes and update the description accordingly. Also, remember to update the new component we’ll be adding and quickly let your colleagues know that it’s being used.
Add the Progress Indicator
Now that the Flow is chosen, it’s time to edit the three Screen elements in order to add the new component as well as the stages. The names of the steps will be added in a comma-separated format in the dedicated field, while the current step will be the highlighted one for the particular screen the component is on.
This component brings six types of progress indicators to choose from. Considering the Path and Horizontal line are available with the new out-of-the-box version too, you could opt to use this component for the other four styles available:
- Vertical
- Horizontal
- Path
- Bar
- VertNav
- Ring
After deciding which of them works best for your use case, it’s just a matter of setting up the components on each individual screen. The fields do need to be completed on each occurrence of the custom component; hence, you have full control over the values and style.
For example, if the Flow evolves in the future and has multiple possible paths based on the initial selection, there’s no problem with having different progress indicators for the different groups of screens.
Once the component is added to each Screen element, it’s time to test the Flow and make sure it works as intended. I used the Path and Horizontal line for a side-by-side comparison with the example above with the out-of-the-box options. Keep in mind that the progress indicator is not a navigation mechanism – it only serves as a visualizer. While you can experiment with the different types of indicators, it’s most likely a good idea to keep the choice consistent throughout the Flow in order to not create confusion.
Summary
Screen flows are here to stay, and with each release, it seems that there are more and more new ways to enhance the user experience while providing more insight into the process or information needed. Adding a progress indicator may not seem like a huge change, but simply knowing how many pages or steps there are to go through will provide your users with clear context and guide them through each section and what it entails.
Whether it’s the readily available Progress Indicator, the Salesforce Labs package, or a different custom component, are you using any sort of progress indicator in your screen flows yet? Share your experience with us in the comments below!
