This is something that comes up in every single conversation about Nintex Workflow I have with partners or clients. What are best practices when it comes to Nintex Workflow? Well, to be honest there is nothing documented and that is what I want to change with this series of blog posts. We will also make them available in various whitepapers to be published on Connect, so you might find some of my blog content in various whitepapers.
I want to take a top down approach on this series of posts and start with the design of the process first, working our way to best practices in workflow design, then best practices when working with the designer, down to the infrastructure level. And please, at any time of the series, feel free to comment, provide feedback, ask questions or suggest more detailed recommendations on covered topics.
Ok, first things first, let’s dive into the actual process of designing workflows. Most of the time you will end up getting a process which looks something like this:
A nightmare, right?
Well, the first task you will encounter here is to split the workflow into smaller pieces, so called modules. Modules are nothing but small workflows that interact with each other. So rather than having one big chunky workflow you will end up with 2, 3 or however many workflows there will be. “What’s the point of that?”, you may ask?
- Flexibility – A business constantly changes and so do its processes. Having a workflow solution broken into logical modules allows you to swap one for another as the process adjusts to the need of the business. No need to redesign the whole workflow.
- Re-use – Ever created a workflow and thought “Oh, that is the same logic I used in a previous workflow”? Thought so. Keep that in mind when you design your workflows and make them re-usable. A module that might work in Workflow A might also work for Workflow B. Or it might at least be similar and might take you 80% of the way to your second workflow.
- Error Handling – Having a workflow broken into modules gives you a way easier approach to debugging and fixing your process. Instead of spending hours going through your workflow solution, you might only spend an hour going through one module, trying to figure out what went wrong.
- Workflow Cancellation – Similar to error handling, you have to carefully consider when a workflow will have to be restarted and have to consider this in your workflow design.
- Testing – It is by far easier to test individual modules rather than one big workflow. Of course, part of your testing will involve testing how those modules work together and going through the whole process. But going through the whole business process during the development phase is a bit of a pain. Especially when you try to fix an error that appears towards the end of the process.
- Timeouts – Since we are talking about SharePoint Workflows and in particular about Nintex Workflows, the compilation and deployment of the workflow is an important factor too. When a workflow is run for the first time it will be compiled on the SharePoint server. One big workflow with lots of activities will obviously take longer to compile and put more load onto the server, thus affecting the performance of your environment.
Input and Output
The next step is to think about the input and output. This needs to be carefully considered right at the start when designing your workflow. It is easier to think about those during the design of your workflow than it is to adjust your workflow at a later stage. Also think about the structure of the output and input and where it will go in the end.
One thing many people forget is, that there might also be input that is not necessarily part of the formal business process as such. For example, imagine a support agent talking to a customer on the phone and working collaboratively on a case. The output of the process to trigger the phone call might be an email to the agent. Then there is an interruption of the process. Some offline collaboration between the agent and customer happens and voila, there we have our input back to the process. The case might be closed or referred to a higher level after the agent gets off the phone, which is the input that triggers our workflow to continue.
LOB system Integration
Carefully consider LOB integration. This goes hand in hand with the previous point. Make sure the data is available at the right time and more importantly in the right format. There might be some data transformation you will have to consider, either as part of the workflow, or ideally as part of a middle layer. After all the workflow should support the process flow and not modify and translate data for different systems.
Also always make sure you only involve LOB systems that are relevant to your workflow. This does not only add extra complexity in data transformation but you will also need to consider authentication and security.
Sequential vs. State Machine Workflow
Thing carefully which model you will use. Sequential workflows are perfect for rather short processes and are for robust processes that aren’t that error prone or where it doesn’t matter if the whole process will be re-run upon an error. I personally prefer State Machine workflows as they are better for process tracking as each stage usually represents a logical step in the business process. Also, they are better when it comes to restarting workflows after an error occurrence. But more on this in a later post of this series.
I hope this post gives you some food for thought and please feel free to comment, criticise, agree, disagree or whatever you feel like. I greatly appreciate any input.