As the Nintex Workflow Cloud platform continues to gain traction in the market, we have made multiple improvements based on the feedback and learnings since we launched in late November 2016. To recap, the notable features delivered were conditional start, a number of new Connectors, and interoperability features with Hawkeye. In this blog post, I want to specifically highlight improvements we have made to the workflow execution behaviour.

We have observed specifically for workflows that start on an update event, if the workflow design has an action to update the same item that started the workflow instance, this inadvertently initiates a new workflow instance. For example, a workflow instance starts when a Salesforce opportunity is updated to ‘Review’. Part of this workflow design has an Express Approval and upon approval, updates the same opportunity to ‘Approved’. This may inadvertently start a new workflow instance of the same workflow design if the start conditions were not scoped appropriately to handle this situation. So we set out to make it easy to manage this behaviour.

In Release 22 (18 May 2017) we updated the workflow execution behaviour to only a run a single instance of a specific workflow design for a given item which then avoids the unwanted behaviour described in the above example. We believe that defaulting this as the behaviour of the workflow execution, most users will welcome this and find it helpful.

However, we understand that there may be scenarios where you would want to override this behaviour. Hence, with Release 23 (1 June 2017) we have provided an option to Allow concurrent workflows on a single item when configuring start events that are of an update nature. When enabled, this allows multiple instances of the workflow design to run on the start event item. For example, an instance is allowed to run on an updated Opportunity object (Salesforce) or Campaign entity (Microsoft Dynamics CRM) even if another instance is already running on the same item.

With the option to toggle between both behaviours when designing your workflows, the workflow designer can now address the nuances that are required for enterprise workflows and easily manage workflow content and automation requirements.

However, there are scenarios where the single instance feature is unable to catch largely due to how the inter-webs behave. Below are some of the scenarios:

1. If a workflow instance completes and just before completion, one of the action is to update the same item. We would flag the workflow instance has completed on an item but due to the polling which happens later, this would result in triggering a new workflow instance
2. A spike of events (due to 3rd party delay in sending events or recovery), Nintex Workflow Cloud could get multiple events for the same item and these events could be legit updates to an item that do require instances of a workflow design to run. Depending on how quick the events are processed, we may not be able to treat each event as its own workflow instance

In the not too distant future, I’m excited to inform that we have plans in delivering an event log to your Nintex Workflow Cloud tenant. The primary purpose of this event log is to inform on the events that have been received and the outcome taken upon receiving the event. For example, an event was received and a workflow instance was started; or we received an event but did not start a workflow because an instance of the workflow design was already running on the same item.

Although we have started planning and working on this feature, I would still be keen to hear from you on what else you would expect from this event log. Feel free to add your thoughts, comments, wants, desires or even any point of clarification to what I’ve shared above. I look forward to hearing from you!