Hi All,
I am trying to create a workflow where the Button should not be enabled unless it satisfies the condition in that user step.
I tried to write an if condition in the button but the target variable that I have declared in the user step, it is not visible while I try to write the if condition in the button.
Is there any way to achieve it.
Regard,
Santhosh
Hi,
yeah Flow (has this weird thing for variables 
and) needs the variable to be available in all the possible branches.
To get around this i usually add an Initialization step at the beginning (Just an assignment step where i “create” the same variable for the first time, blank)
Hope this helps!
B R
Ivan
Also please note that if you want to have a condition based on what you actually select in a user step to then (in the same user step) display a button this would only work by leaving the user step once and then loop back to it in older versions. In the newest version this should also be solvable by an event step i assume, but i haven’t tried it yet.
Thanks, I have a question about this though:
What if I have a variable y and I initialize it to 1.
Then I want my button to be available only if Len(y)>3
Is that possible?
Hi,
yes you can use most of Flow Script functions in the “Available if” section of a button.
However Johannes was right in the comment above: the conditions for a button are calculated when flow moves to the user step containing the buttons. So a change in a variable within that user step will not influence the button visibility (unless you enter that user step again).
So if you came into the user step with y=1 the button will still be enabled even if you enter something longer than 3 chars in the user step.
A workaround for this is a decision step after the button that shouldn’t be available that just loops back to the user step (with a checkpoint item telling them about the invalid value), or sometimes we use a refresh/evaluate extra button that loops back too.
Hope this helps!
B R
Ivan
Hi, any help appreciated.
The problem I have with this concept of looping back is I lose the changes the user made on the screen.
This can be resolved by creating every possible output variable in a user step prior to the step.
But for changes made in a datagrid, there is no way that I know to just take the user back without losing their changes or doing a lot of work to map the entire datagrid output back onto itself which would require creating the DG output variable prior to the actual User step which has it’s own complications because RowState is a hidden column and doesn’t map nicely as input.
What we really need is an ASSERTION step with the OPTION to let the user continue or go back. That way, we can check a condition, alert them, and then give them the option to continue anyway. But only when we want them to have those options.
Make sense?
Simple example:
Display a datagrid with an editable column.
Edit it and click a button you call cancel.
If I want to warn the user that they have “unsaved changes” and optionally take them back to the User Step, how do you do that while maintaining the changes they’ve made.
This should be simple and not require a complex remapping of their output back into the input table. Especially if they have a “search” already open.
Users complain a lot about how they search the datagrid then flow functions that refresh the screen remove their search.
@wpuymac I’m curious if you found an elegant solution to this problem to help protect the user from losing changes made in a datagrid without complicated multistep save-and-restore logic for the datagrid source?
Nope…nothing elegant at least.
