Even linear workflows can handle conditional execution, you just lift the condition into a value, like into a Maybe/Option type, and later stages only execute if there's a value.

Or if you want to be more literal, declare a specific type:

    type Authenticated(User) = No | Yes(User)

And each stage of your workflow matches on Authenticated.Yes, and so only executes if the user is authenticated. That's basically what any system does internally, this just makes that implicit behaviour explicit.

I assume you would have conditions for each workflow which are then pattern matched to user behaviour to see if that workflow is relevant.

You still have a globally defined happy path of coordination but your overarching application logic isn't spread everywhere but contained in one place.

The preconditions for the logout would trigger a different workflow.

I am the author of additive-gui, which is based around the idea that you provide all the rules of the GUI and the computer works it out - what applies when. Additive GUIs loosely models dataflow between components and layout.

https://github.com/samsquire/additive-guis

It's not ready for anything, it's just a proof of concept. But it doesn't really implement workflows yet.

I would rather maintain a codebase that uses this pattern of user workflows, similar to state management than sprinkled logic everywhere.

Think of workflow engines as a runtime, not a hardcoded sequence of steps that can be activated or deactivated based on events, like a state machine.

Real workflow engines (the ones you find in large companies used to model business processes) handles conditions and branching.

But my personnal experience is that linear flows work really well in the context of apps with just those two additions :

The ability to cancel a running flow. The ability for a step to « do nothing » if the conditions for its execution aren’t met.