Start conditions are incredibly useful when developing Workflows in Nintex. They allow the developer to simply and eloquently decide which conditions are necessary for a Workflow to automatically be triggered. For example we might only want our Vacation Request workflow to trigger when an item is saved to our list with a status of Submitted. No point in notifying the boss that you’re just thinking about taking a vacation, eh?

What you didn’t want to know:
Start conditions change the way Nintex Forms trigger the workflow. Workflows with start conditions are started synchronously once the form is submitted. Under normal circumstances, this will not cause any tangible issues, however if you have large workflows being triggered, your user will watch a spinning circle until the workflow finishes its first batch of operations, which can come across to users as a slow system.

tldr; there’s no perfect solution. There’s not even a great solution. They’re actually all pretty ugly workarounds. I recommend not doing anything unless you notice a real performance impact. Even then, get other people to take a look. You might be just too close to it, make sure your fixing an actual problem before doing anything.

So what’s a [determined] dev to do? Here are some options to consider

The first is to do nothing.
No, really, this is probably what you should be doing. Just use the conditional starts and ignore the issue. If anybody asks, it worked fine on your machine.
Generally, Nintex is pretty snappy and the first batch of actions happen quickly. If too many workflows are running, the operation is queued and the user won’t even notice. This is generally going to be your best option as it’s the easiest to develop, and most of the time, users are not going to even know. Yes, this is intentionally making the user’s life less great, but, it’s out of the box functionality, and it’s the right way to develop the solution. We can argue about what ‘the right way to develop the solution’ means some other time.

Okay, you have this problem, and you want need to do something about it. Fine, but don’t say I didn’t warn you.

Next option: start every Workflow with a wait.
Waiting ends the Nintex Workflow Batch, so the WF will end quickly and the user won’t notice a delay. The downside of this is that we are waiting for a minimum of five minutes because of the way Nintex takes advantage of SharePoint’s timers/jobs. In some cases, this may be fine, in others, this is a deal-breaker. I generally prefer not to wait for five minutes because it will seem arbitrary to users and developers when they interact with the workflow (and it’s really annoying when you’re developing the workflow).

Get rid of the start condition and add a Terminate Workflow action
Getting rid of the start conditions lets Nintex run things asynchronously. “But what about my start conditions?” Simply put the negation of the start conditions into a run-if and terminate the Workflow. “Why don’t I always do this?” Well, you’re starting the workflow every time you create an item (or edit?). This is using up resources. Keep in mind that Nintex has some very real limitations to the number of simultaneously running workflows. Additionally, this makes logging a nightmare, and it’s going to make the history needlessly noisy. Keep in mind that if you’ve got multiple workflows that have conditional starts on the same item, you might be creating a lot of noise. For example if you have eight workflows run on a single list item, you’re starting half the available # of running workflows every time you create an item.

Start the Workflow(s) Manually from another workflow that always starts
Another thing you can do is to have a single workflow that always runs and all others never automatically start. This workflow decides which WFs to start based on the various start conditions.

The benefit of this is we get our wonderful asynchronicity, and we’re not starting WFs just to stop them immediately. We also have a single point of failure for starting conditions.

The downside is that we have an extra workflow, this can add to the cost of the solution, fails to take advantage of built-in Nintex Workflow features, and creates an extra point of failure. Logging is also more complicated as we have additional WF History Logs to look at to see what’s going on with a single item. Additional complexity will exist for the developer to consider. For example, we now have to put more thought into who Nintex considers the Workflow Initiator.

See? I told you that you should have just done nothing. Now you have to live with the knowledge that your start conditions are ruining your User Experience. At the end of the day, you have weigh the options and decide what the right approach is for your specific circumstances, but in most cases, using Start Conditions should be the right approach.

Have I missed something? Do you have a better solution? I’d love to hear about it! Comment below. No, really, I would really like to hear of a better solution to this problem. Please.