Bingham Blalock​ posted a very useful blog about Some Common Misperceptions - Q & A

In this post he touched upon a principle around the design (or architecture, if you want to try and convince your boss that your should earn an extra 5k a year) or workflows when it comes to changing a workflow whilst it's running.

This prompted me to write about the idea of "micro-workflows" (I made that up, lets see if it sticks).

Micro-workflows (as defined by me ) are workflows that perform specific tasks within a process.

An example of this was an app I developed with an approval process which required a number of conditions to be queried before deciding which route the approval would take. There were a number of other tasks involved in the process as well, and the complexity led me to break the single workflow down into a number of smaller workflows. Not only does this mean I can make changes to a workflow whilst the "process" is running against the item, it makes making changes to the workflows easier and tidier. When you open a large complicated workflow map, especially one designed by someone else, it can be pretty daunting to try and understand where a change may need to be made. It also helps avoid any limitations around Nintex or SharePoint workflow, with regards to the number of nested conditions you may have in a workflow, or the size of the workflow.

So my workflow was broken into 8 smaller, more manageable workflows. We'll follow this example as if it were an expenses or hospitality claim.

1. Set Item Permissions - This workflow would run as soon as an item was created, it may not get submitted straight away, just saved, but the requirement was that only certain people would see and have access to items created in this list, so Item level permissions were required. Once permissions were set, it would pause and wait for a Status update from the form, which happened when the user hit "Submit" rather than "Save". A few other small actions were run before this workflow started the "Master Workflow".

2. Master Workflow - This workflow would run the first couple of major conditions to evaluate which direction the workflow would be sent next. Conditions could be something like the value of the request, or the expenses claim, or the type of client involved in the claim. Once the conditions were met it would start one of the 4 following workflows, but remember this could be any number of

3. Workflow Option 1 -  Obviously you would probably look to call your workflow something more obvious that describes the route taken to reach this workflow, such as "> than $50 with a sensitive client". These workflow might evaluate further to ascertain the nature of the submission, is it an expense for food or hosting a team building exercise at paintball? Whatever your business process dictates you need to evaluate before finally deciding who the approval may go to. So a small claim for $10 worth of lunch may go straight to your Line Manager, hosting a client for 3 course meal worth $50 may go to your department or business unit lead or taking the entire team to a conference for a week might go to your Directors. Once all the evaluaions are made, the workflow will start the final workflow to send the approval.

4. Workflow Option 2 - As with Option 1

5. Workflow Option 3 - As with Option 1

6. Workflow Option 4 - As with Option 1

7. Send Approval - So having decided who the workflow should be sent this final workflow will actually send the approval task. By passing variables from the previous workflows I can create a single task for all possible outcomes of the conditions that were evaluated in the previous workflow, no repetitive work, so if they decide they want to change the text in the email sent to the approver, I don't have to copy and paste it to all the different branches created in the previous workflow.

I found this modular approach to building workflows around complicated business processes, far more manageable than one large workflow. Using Action sets and snippets can also help deal with repetitive work across the numerous workflows.

I'd be interested to hear how different folks approach their workflow design before they start building.