Does flow structure matter?

[Econdoc]

The picture shows two flows side by side. Each appears to execute three actions as a result of a condition. Does the structure matter? If so, please explain how they differ in function.
Thanks

Capture.JPG (30.37 KiB) Viewed 22141 times

[Bushmills]

What do you think what difference there'll be? Telling us first helps avoiding to explain to you the most obvious, and focus on what you don't seem to understand. For a start, think of 3 actions "action1", "pause 5 seconds", and "action2", and examine how execution may get affected.

[Econdoc]

Yes, I see your point.
Assume that there are no delays in the actions. Something like:
1. Set WiFi on
2. Notification to Screen
3. Notification to Statusbar

Will both flow behave identically or is there some advantage to one flow structure over another?

[Bushmills]

For sake of example, let's assume that you want to install that flow on different devices. Among those is one without WiFi, which throws an exception when the non-existing WiFi is attempted to be turned on.
In the sequential case, the actions following "WiFi on" won't get executed, because failing WiFi won't just proceed with next action in case of failure. Therefore, no notification - which is probably what you want.
The other case, with all actions on the same level, will show notification regardless of enabling WiFi being successful or not. Therefore, for your example, sequential actions may be preferable.

[Martin]

Executing actions purely sequentially can be easier to understand and debug when there's a problem. Executing the three actions in parallel could be harder to debug when the log output of the actions is mixed.
It could also make a difference when you execute three HTTP requests. The parallel case could lead to a slightly different request sequence on the server each time the flow executes since the order is not defined. The sequential case will be more deterministic since the order is clear and always the same.
It will also make a difference if one of the action fails with an error. The sequential case will not execute any more actions when for example the first action fails. The parallel case will finish to execute all three actions, even if one fails.

[Econdoc]

Thank you Bushmills and Martin.
My wishlist is still very big on examples, examples, examples.
Anyone thinking about a manual? That would be great!
So many little, tiny, issues that can be cleared up with EXAMPLES. (Have I said that before? )

[Bushmills]

Are you offering to carry together examples, test and publish them, or are you merely asking others to do that for you? That wasn't quite clear from how you put it, "wish list" can mean either. In the first case, consider that there exist different levels of skill and experience - you may want to focus on a user group of one experience level; trying to collect a set of examples for any user may result in too little of interest for any particular group, because most content would be considered too advanced or too elementary. Advanced users may not be ideal candidates for creating examples for newbies, because they tend to think of things as obvious which aren't for new users. OTOH are users with limited experience unsuited for creation of examples which appeal to advanced users. Therefore I'd suggest you create examples for users with an expertise level just below yours. You may want to have them looked over by somebody more experienced then. Good luck

[Wibbly]

In the parallel example, I think if I put a sleep in one of the arms the whole flow (including the other arms) go to sleep at the same time. Is this my imagination, or by design?

[Martin]

That's by design. A flow waits until all currently executing actions have finished until the following actions are started. This was done to make flows execute in a more deterministic way which helps to find problems and to analyze logs. If a flow has multiple branches that should be executed in a completely independent way, they can be extracted into separate flows that are executed with action 'Execute Flows'.

[Wibbly]

Excellent. Thanks Martin