Skip to main content

We've all been there haven't we? You've got a multi-stage workflow, your director has approved it, your manager has approved it, and then **ERROR**

 

Something goes wrong. Maybe your next approver has left the company since the workflow was started, or there's an erroneous value in your variable that your SharePoint column won't accept.

 

Either way, you've got into a position where you've already had approval from a director (or anyone) once, you don't really want to have to ask them again.

 

On long running workflows this can be a real pain. So we introduced a setup that allowed us to "Pick up where we left off" (or were kicked off as the case might have been).

 

The State Machine is a brilliant action for for these staged workflows that transition through a number of different states and the Switch Action allows us leverage these states. Take the following example:

An item is created, to achieve approval it must go through 3 stages on a State Machine.

  1. Manager Approval
  2. Director Approval
  3. Task to be actioned by individual

Each of these stages is a branch in a State Machine, and after each task has been approved a Status column is updated to represent it's stage.

  1. Manager Approval - Status = "Approved by Manager"
  2. Director Approval - Status = "Approved by Director"
  3. Task to be actioned by individual - Status = "Ready for Action"

 

The status is updated immediately after the task completes and then the State Machine changes state to the next branch.

Item with ID = 101 is submitted and the approval workflow starts, the manager approves it immediately and then a month later the Director approves is, however, in that month, the user listed in the Item as the person to complete Stage 3 has left the company. So when Stage 3 goes to assign it's task, the workflow fails because the user does not exist in AD.

 

Enter the Switch!

 

When we designed our workflow, we created an additional branch on our State Machine called "Status Check" The state machine is set to go to this branch first. In this branch we have a Switch which will check the status column of our item and look for one of "Approved by Manager", "Approved by Director", "Ready for Action" or "Other". Each branch of the Switch has a Change State action that will send the workflow off to the required branch in the State Machine.

 

So when our item is updated with a new user to "action" and the workflow is restarted, in the case of Item 101, the status is "Approved by Director". The Switch identifies this status and the Change State action is set to send the workflow straight to the "Task to be Actioned by Individual" state. Thus the workflow "Picks up where it left off".

StateMachineSwitch.PNG

The main downside we have from this is that we are left with 2 workflow instances for an item in order to prove the audit trail of the item, however, the full story is there to see.

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.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings