Nintex 365 on-change workflows do not start after the item is changed by another task workflow

Answering my own question.

The problem we have here is that we don't have conditional start workflows, and we can't have workflows that start when the list item has been updated by another workflow. So we only have 2 scenarios where a workflow will trigger: 1, a new list item is created; 2, where the list item is manually modified (by form or direct list edit).

My process flow has the following steps:

1. Form creation (when closed workflows analyse the form content and set following approval steps as Not Needed or Not Decided)
2. Form check (a manual step where input by applicant is checked, and maybe sent back if incorrect). When this closes, on-change start workflows can be triggered.
3. Depending on what steps were set as Not Decided, approval task workflows are started, in a pre-determined order to deciding managers. There may be up to 6 different managers involved in extreme cases.

My problem occurs at step 3 - I need to have the tasks sent out to the managers in the specified order, depending on whether the previous decision was approved.

To get around this I had to setup the approval step workflows as follows:

• On-change start (so that they start running after the second manual step, above). So after the Check step all approval task workflows start.
• 1st, a Y/N condition to see if the step was set to Not Decided, if not the workflow Ends; If set to Not Decided, the flow moves to a loop on-condition step
• The loop on-condition step can have multiple conditions, so it is ideal when waiting for several status columns to line up, before continuing to the task step. But the main problem with the loop is you have a 5,000 loop limit in SharePoint - so you need to add a Wait for Duration step. Depending on how long you expect your workflow to take, you should adjust this accordingly - 5 minutes for 17days; 10 minutes for 34days, etc
• The multiple condition setting for the loop is required because a request may be rejected before it gets to all approvers - so the loop tests for a "ready for approval C" status as well as a rejected status. After the loop, you would have a switch step setting the rejected request workflows to be Terminated - otherwise already-rejected requests would have workflows hanging around for ages before erroring on the 5,000 loop limit.
• Each of the task workflows closes with a status setting which would move the item status on to cause another task flow's loop to finish looping and move onwards.

If any of this is unclear, please let me know.