On Office 365, in a customized document library a workflow initiate an approval task when a new item is created.
Once the task is completed the workflow update a status field of the document.
A second workflow has been set up to start when an item is modified to track the status change and initiate a second approval process.
It seems this On Modified Event is never triggered properly, the second workflow never start.
If a manual update of the file properties is done, it works fine.
Is it a bug ? Or unfortunately that's the way it is ?
Sounds like you're trying to run a recursive workflow scenario here and those are not permitted within Microsoft's Workflow Engine. This function was removed from SharePoint some time ago as a precaution to keep workflows from executing infinitely.
You can find more information regarding recursive workflows here: Service Pack 2 prevents an on-change workflow from starting itself - Microsoft SharePoint Designer T...
My recommendation is to run a "start workflow" action to start the second workflow after the update field action.
As recommended in the link you have provided I'm already using 2 workflows.
I could understand the second one is not generating a recursive call but I don't get why this 2 workflow is not executed after the first has updated a field.
My current scenario is:
On create - > Workflow 1 -> Task -> Field update -> End Workflow 1
On update -> Workflow 2 -> Task -> Field update -> End Workflow 2
So Why Workflow 2 never start?
Are you still experiencing this issue? If so, can you please create a support request regarding this issue and request it to be assigned to me so we can work together on this issue?
Andrew - looking at the link, I cannot help noticing that Nintex has cut off very useful functionality to stop all types of recursive - where the problem blocked by SP2 is only the single-recursive workflow (i.e. one that triggers itself):
But SP2 apparently does allow multple-workflow recursive flow (where one workflow is triggered by another, not itself):
[· Before SP2, a single on-change workflow could enter an infinite loop by updating the current item, thus triggering itself.
· After SP2, an on-change workflow can trigger any other on-change workflows by updating the current item, but an on-change workflow cannot trigger itself. So co-recursion scenarios — including any scenario that implements a state-based workflow by using many smaller on-change workflows — are not blocked]
To allow these state-based workflows to work, Nintex could add some error checking to the workflow - such that if an a column field is included in an Update action in the workflow, it cannot be used in an On-Column-Change-Start scenario.
This functionality is present and works On-Premise; it is a big gap in 365 Nintex Workflow