Mike Fitzmaurice presented at Nintex InspireX 2017.
When I’m talking about Nintex’s technology, I take great care to make sure I’m explaining – not selling – what we do.
But when I’m talking about the subject area of workflow itself, both at the technical and business level, I’m definitely selling. Selling ideas, that is; ideas that push you to think about your workflow and content automation goals beyond any product from any company. Mind you, Nintex tends to care about these ideas, to their credit.
Last month, in the final hour of Nintex InspireX, I brought a new idea to the table: in many cases, you’re better off building a solution out of multiple workflows, not just multiple forms and connections. Compared to one giant workflow, doing so makes sense more often than you might think.
6 Reasons Why You Should Have Multiple Workflows in One Solution
This is much less of an issue with Nintex Workflow Cloud, which uses our new Nintex-crafted engine technology, but our Office 365- and SharePoint Server-coupled offerings make use of SharePoint-supplied workflow engines, and they prefer smaller models; breaking a large workflow up into several smaller workflows often helps. Still, this is more a matter of avoiding a problem rather than embracing a benefit.
I’m guessing that many of you use Action Sets, and often do so to reduce a lot of detail when showing a workflow design to someone less concerned with details and more concerned with broad strokes. That’s good, but action sets don’t really buy you anything in terms of efficiency; they conceal steps, but a big workflow collapsed down to a few action sets is still a big workflow.
You can achieve the same effect by using a call to another workflow in place of an Action Set. Use Start Workflow or Execute a Nintex Workflow Cloud Workflow instead, and put the logic in question inside of that sub-workflow. Have the high-level workflow deal with the “what” and have the sub-workflows it calls responsible for the “how” details, each one handling different things at different steps.
Your constituents will have an easier time of things, and so will you.
The established way to secure data or services is to guard access to them with special permissions, and you only give those permissions to people who have a need to use them. Why?
It’s likely because you don’t want someone to use your data in ways you didn’t intend. Totally understandable. But it’s pretty rare to see a company implement granular per-user permissions on SQL tables, web services, etc. As such, a lot of opportunities are denied citizen developers.
But there’s a better way.
Instead of trying to put a fence around the data/APIs, create sub-workflows that use the them the way you intended – then give authorized users permission to call (but not view/edit) the sub-workflows. Connection and credential details are embedded, and hence hidden away, inside those sub-workflows.
Consider a situation where different departments have different review policies for vacation time. Rather than giving out keys and connection details for your HR software to someone in each department, create a sub-workflow for getting an employee’s leave balance and another one for registering approved leave time. Give those to someone in each department.
No surprises that way.
4. Office Politics:
For any process spanning cross-departmental boundaries, you absolutely should consider multiple workflows.
Take, for example, an employee onboarding workflow as viewed by your HR team. HR needs to prepare a contract, acquire manager approvals and new hire signatures – all steps in a workflow that IT doesn’t have or need involvement in. But onboarding to IT involves provisioning accounts, mailboxes, application privileges, group memberships – things that aren’t really HR.
You’d think you have three choices: give HR the right to provision IT assets, give IT the right to manage employment agreements, or find a third party to develop a solution that pleases both of them.
There’s a fourth, and better, way.
Have each department build a workflow that handles their part of the overall process. Then have one call the other. Once an employment agreement is digitally signed and an employee’s manager and start date have been registered, the HR workflow can call the IT workflow to handle IT-specific details.
Everyone retains responsibility for their own solutions.
If a business process takes a very long time (e.g., months), that doesn’t mean any one workflow should continue to run the entire time.
Even if an engine allows it, not everyone is comfortable with that idea (although this is also one of the things Nintex Workflow Cloud may make less of an issue as it evolves). Instead of a workflow assigning a task and waiting a long time for it to be completed, you can have it send a request, write some information to a data store (a database, a SharePoint list, even, I suppose, an XML file) and exit. Activity taking place later can trigger the start of a new workflow which reads that saved data and continues the overall process.
Mind you, this isn’t the kind of thing you want to do all the time; there’s a potential for dependencies to fail if you’re not careful. But if you have steps in place to monitor for tasks that are never completed, ideally by a monitoring workflow, you can mitigate those risks.
Finally, one of the more intuitive rationales for breaking up a workflow is expertise.
Each department and process comes with its own unique business rules that warrant separate data, steps, etc., all of which can be captured within multiple workflows. You can leverage other people’s knowledge by leveraging their reusable business processes.
Someone solving a problem with a reusable sub-workflow that everyone can use can be far preferable to having that same someone join in with every workflow project throughout the entire organization.
Check back soon for a full recording of my InspireX session, which includes demos of the situations above and touches on what you can expect from Nintex in the coming months – including new functionality to further your ability to leverage the power of multiple workflows.