Possible enhancement idea

[rwinger1]

Thank you for this component; I definitely have a need for this. One enhancement I would love to see would be to have the option to make the navigation bar clickable so that when you clicked on one of the steps in the navigation bar, it would jump you to that flow screen. Thanks in advance for you consideration.

[egyptguy]

Hi @rwinger1 - thanks for your feedback! It's an interesting idea - I had not thought of using the component for navigation, but that's a definite possibility. I could see the component returning whatever step you had clicked on, which would allow you to use a Decision element to decide where to navigate. Does that sound like what you're envisioning? Very interesting, thanks for brainstorming.

[rwinger1]

Hi @egyptguy ...yes, that is exactly what I was envisioning. Thanks for your consideration!

[jonathankretzmer]

We need this same behaviour, please. Additionally, having the ability to mark 'future' states as disabled to prevent attempted progression to a future state should the user have not filled in any mandatory information for advancement would need to be included.

Would implementation be hampered by the default validation that exists on a screen? Would the action need to be 'FlowNavigationBackEvent' to get around this?
Would the user be at risk of losing any changed information on the current screen?

[ildiavolorosso]

I'll second Jonathan's comment. Control over (a) whether the progress bar is clickable and (b) what happens when something is clicked is critical.

[egyptguy]

So quite by coincidence a colleague at Salesforce mentioned there's a navigation component already like this on unofficialsf that I had not seen before. I haven't tried it myself, but I'm sharing here in case it's helpful to you: https://unofficialsf.com/building-a-direct-screen-access-flow/

[jonathankretzmer]

I've tried my hand at implementing this functionality and found the following:

1. I needed an output variable to capture the 'next screen' in order for the navigation decision to work
2. Added additional input variables: stepClickable (boolean), nextStep (string)
3. I had to use the Forward action as the first screen gave errors as no previous screen existed
4. The native Back button has a 'stacking' behaviour (as you add additional screens to the navigation stack then the back button will just keep popping screens off going backwards).

My work in progress:
https://github.com/jonathankretzmer/DynamicFlowProgress

Flow

[jonathankretzmer]

I've simplified the flow using the same nextStep to input the next screen but overridden for output when clicked.

[jonathankretzmer]

The problem I'm now faced with is that on-screen validation will prevent the user from navigating. But I don't think using the Back event would solve this due to the screen stacking behaviour for flow navigation.

[jonathankretzmer]

What are all your thoughts on 'forward' navigation?

I believe there may be complications:

1. We will need to maintain state to track what screens the user has already visited, these should be the only ones they should be allowed to navigate to.
2. What if changed values result in a new screen becoming available in a decision?
3. What about more complex validations that may occur in specific screens?

Overall navigating forward brings far too many concerns to be allowed, I feel.

[egyptguy]

I agree that enabling a component like this for navigation opens up a can of worms for handling the user experience and processing flow logic, but it could be done. That’s not the point of this component, but it could be done. I have many flows where I use custom navigation button menus to guide the user, but only at specific points (and only with planned/specific buttons). This component’s purpose os to visually depict where in a process the user is - there are no plans to make it available for navigation. Thanks again for the feedback though! Mitch

…

On Tue, Oct 25, 2022 at 3:26 AM Jon ***@***.***> wrote: What are all your thoughts on 'forward' navigation? I believe there may be complications: 1. We will need to maintain state to track what screens the user has already visited, these should be the only ones they should be allowed to navigate to. 2. What if changed values result in a new screen becoming available in a decision? 3. What about more complex validations that may occur in specific screens? Overall navigating forward brings far too many concerns to be allowed, I feel. — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3SVZF2S33VCFA3VDG5523WE6DQRANCNFSM5NGWM6LA> . You are receiving this because you were mentioned.Message ID: <SFDC-Assets/DynamicFlowProgress/repo-discussions/2/comments/3957725@ github.com>