Skip to main content

On the back of my previous post about running workflows, I've created a list with a single form and workflow as a basic example behind the premise. You can find them attached.

 

I'm not a fan of running workflows. Where I can, I will look to process a form in a single pass of the workflow. It will set the stage, status, Assigned, content type, permissions and send emails in a single pass. It will only have one list ( No Task List ) 

 

When I started using Nintex I quickly found that some of the actions that require the workflow to pause and request data are great until you want to make changes. Ooh I need another stage or another field on the approval form. Oh god I have 3000 of these in flight. I need to adjust the task form and restart all the workflows and somehow get them back to the current stage they were at. 

 

With this approach that pain goes away. If I've added another field or stage, next time the form is processed it'll take into account those changes.

 

Onto the example. It's a simple request with an approval and review stage. My actual solution would be more along the lines of my original post, with a 'stages' list to lookup the info and multiple content types for the different forms (stages) but for this example, everything is on the one form so you can download and have a look yourself.

 

There is a single workflow that runs on new or modified. Based on a WorkflowProcess field, the workflow makes a choice as to the stage you've chosen, looks up the relevant data for that stage and updates the item to that stage. Buttons on the form are linked to the WorkflowProcess and simply enter a different stage value into that field for the workflow to work out which stage you want.

 

Another advantage of this is the ease at which you can move items about. If I type into the WorkflowProcess the stage I want the form to goto, the workflow runs as if the button had entered the value.

 

 

On our New form the button is linked to 

 

So the workflow runs and looks for the relevant data for that stage.

 

and updates the item info with the new stage, status and who to assign it to.

217287_pastedImage_5.png

The form has now changed to the 'Approver' view. In this example I've used rules to hide the different sections. A better solution would be to have a content type (form) for each stage.

 

The advantage here is we are still using one list. It's the same item the applicant created. No task form to bring any required info back to. All the info is already on the form for the approver. I just disable the fields already input.

 

 

Here the Approver can send it on for review or reject it back. All the buttons are doing is entering stage 2.0 or 0.0 into the workflowprocess field.

 

Onto the review stage and as before I can see all relevant info and approve or reject. The form also shows an Audit and any comments that have been added along the way.

 

That's it. The reviewer can reject it back a step or approve and finish the item.

 

Ok! So apologies if I've stated the bleeding obvious. I've just been learning on the way by playing and reading this forum!

 

So advantages in a nutshell....

 

Single list. No need for a separate task list.

All the data captured during the process is captured in a single item.

Attachments. One item again. Attachments are there at any stage.

No running workflow. Items are processed to the next stage in a single pass.

Easily move items between stages as an admin.

Changes to forms or workflow are applied the next time the item is opened and or processed.

 

List and workflow is attached if you want to have a play.

 

T

This is quite an interesting way to configure a form and workflow. Many of my large workflows would benefit from this type of set up. They can run for ages, and as you mention, what happens if you need to update the workflow while they are in progress. 

Thank you for taking the time to set it up with images and templates. They come in handy when attempting to replicate. 


Thanks! I'd be intriged to see one of your workflow's to see if this model could fit or you're tied into having a running workflow by your requirements.

T


Hi Anthony,

I have been through this and do know your pain, In my previous projects I have been using FlexiTask (because of their over hyped approval/rejection/ multiple audience/Reports etc) but on my current and few projects that I did in the past year I have used this approach. I was in fact thinking of putting something together and posting it on this forum to see reactions of other folks here good that I can see same approach being employed by yourself as well. 

In addition to the list I tried to get the audit history stored in the same list where the data is, so its easier for export/reporting etc. and have also used multi-text (append only). With AppendOnly text SP manages all the comments through versioning but everything comes OOB.

Regards,

Shrini


Good to know I'm not alone  


Hello,

I am doing something similar, where I set a status field based on the result of a Flexi-task action and then end the workflow. If the flexi-task is reject, the workflow will set a Status field = "Initial Reject". 

The workflow starts when an item is created, or conditionally when item is modified.  The condition is Status = "Initial Reject"

My intention is that, after the rejection, the requester will make a change, and when they resubmit the item again, it will run based on the the condition of status = "Initial Reject".   

My problem is that when the workflow updates the status value in the item to "Initial Reject", the workflow immediately kicks itself off again. I only want the workflow to run after the item is updated and saved by the user.  Why is it running on its own? Does this make sense?  Any ideas?  Below is the conditional start.


Hi Susie,

I am not sure I entirely understood what you are trying to achieve and may be this could be a different question all together rather than a comment on a blog post as it would have wider audience reach out for answers?

Just from the brief you gave above I am assuming if you want the WF to trigger based on when the user submits then you should probably set the field value (via JS) "Initial Reject User Submit" etc and start the WF if the value is "Initial Reject User Submit". Because I believe in your case the WF start condition is achieved the moment it sees the status "Initial Reject" and it would not know who has set it, some other WF or another user?

Btw I have seen issues with conditional WF starting (not sure if this is the same thing though in your case) but when I faced this issue I did start the workflow when anything was modified and would have a switch clause in the WF to see for the conditional statement, if it matches it would proceed or it would just end.

I still doubt the entire design on why you would approach it this way? If you want to use flexi task then you could achieve all of your functionality using Flexi task and not want user interacting seperately or WF triggering based on any value? 

Sorry if i didn't understand your design and may be its right as I don't know the entire picture.

Regards,

Shrini


Hi, how about having a Workflow Process field and a status field. That way you can update the Status and Process Field to Initial Reject. The conditional workflow uses the process field to 'fire' and resets it to blank afterwards. That way if re submitted it won't run it again because the process field is now blank.


Thank you for your help.   I got this to work by adding a state to the state machine, and not relying on the conditional start.  Thanks again.


Reply