I fully agree with the depicted concept, and use it all the time!

I just can't find good reasons why this is not native feature...

you well described all the reasons and advantages.

but I would like to extend on downsides, since there are many more downsides and headaches (to be polite) then that single one you mentioned.

and to be honest, the one you mentioned is bothering me the least.

just few of them that bothers the most:

- all of the state machine branches are very similar (well, apart from status check/entry/init and sort of finalization/closing ones), they usually follow the same pattern.

there are just the same action, just the same flow, etc.

only slight differences are in action's data inputs (sometimes nintex actions require hardcoded/static values) and targets where/how outputs/outcomes should be applied.

this forces us to copy&paste the same things over and over. I think I do not need to mention this is definitelly source of problems (not to forget to change the same thing on number of different places).

so we copy&paste, copy&paste and soon we hit problem that workflow is too big to be published. we just implemented  small portion of business logic and we are already running out of resources.

IMHO, this could easily be unified into single or very few branches, if all the actions supported parametrized inputs/outputs.

- state machine branches can not mutually share flow (sub)parts that are just the same.

typically initialization part and finalization parts are just the same with no even single difference in every branch. why do we have to replicate them in every branch?

- state machine action can not decide  resp. change state action can not switch based on a variable/item property.

why do I need to place change state action into every task outcome branch when it could be enough to have it once at the end state machine branch and supply it with taksk's outcome variable?

if that were possible I could get rid of 90% of change state actions from my workflows (very often along with switch actions as well)

- maintaining customized task forms is painful as well.

more on the topic I've written here May Mission - Universal task form

- as I have already mentioned, soon or later we come into the point business logic has to be split to several workflows.

but there is no way how to share 'current running context' among workflows in an easy way. I mainly mean plenty of variables that are needed in both calling and called workflows.

if I'm forced to spin off part of the business logic to a separate workflow, I should be able to share that business logic context among workflows.

something like it is possible with UDAs.

I wouldn't like to say it's a bad concept/approach.

as I've written, I use the very same concept with my every approval workflow, and do not know any better.

just wanted to bring it into attention, hopefully to NINTEX too.

Thanks for your thoughts, I agree the State Machine can lead to a lot of repetitive work. You could combine the Switch (to identify your item status) with another post I wrote around "Micro workflows" to make this more manageable.

So you may have 8 workflows that make up an approval process, each one doing it's own thing with as much complexity as you wish to manage in each of those workflows. Then, when something goes wrong, the first workflow to fire is your "Status Checker" and the Switch evaluates the status of your item and then instead of setting a state, it starts the relevant workflow.

Anytime you have something that is repeated, put it in a separate workflow and each time it could call that. Just like in programming, you do not want to copy and paste but create a function.

Nice post, certainly a method I now use for every workflow where possible.

Though I use a specific status column for the StateMachine, which is defaulted, saved and picked up from the List. That way I have full control over what the statemachine does If I want without changing any other status.

With Nintex moving to pay/per Workflow I create large statemachines that do every process I need and just start it with a specific status and it will run that State, and also have a "DoNothing" state which just completes the workflow as I have it to run on modify.

yes, that's possible to a certain extent, and in fact I do that so.

however, before calling a workflow within state machine branch you still have to do some preparation/initialization steps and after you get returned from workflow call to do results processing. and this usually follows very similar patterns across branches. and if you need to use actions that do not support parametrical input (like change state machine) you need to repeat/copy the same actions over and over, or even create one additional branch.

I don't think there's a need for a state machine to control the workflows in this case. If you are using a number of smaller workflows, then just a switch will suffice for this.

this would be usable for workflows that that passed one way down and end.

but if you have multi-stage workflow (multiple level of approvals, possibility to return back few steps by approver's decission...) you definitely need state machine.

after all, you describe it that way in your post as well.

The post was describing a single workflow with a state machine in it and a switch being used as the first branch to direct the workflow to the correct state based on a status column.

If you simply broke that state machine into a number of smaller workflows, you can do away with the State Machine and use a "master" workflow to start each stage of the process as required. So if the process arrives at the "master" workflow at Stage 2, the switch will start "Stage 2 Workflow". If it's a linear process then "Stage 2 Workflow" can then in turn start "Stage  3 Workflow". If the workflow requires the ability to bounce between stages, end each workflow with a "Status update" and then Start the "Master" workflow again to allow the Switch to do it's magic.

This is my favourite. I mean, you can have some complex workflows, but this should always be at the forefront.

Something I'd like to get around to looking at, is trying to fish out the audit trail from the previous workflow that failed, and then write it to the History list, thus giving a slightly more convenient illustration of the item's workflow history, in one screen.

Hi,

I really love this approach - as I use this regular for more complex workflows, that might fail at some point in time and need to resume at some state, without going through already completed approvals. I could even modify this value and have to workflow start at any give point within my workflow.

In stead of the switch statement, I write the name of the state to a status-column, this way I can just change to whatever state is persisted in this column.