Hi,
Ideally, it should work in this sequence, W1 --> start W2 --> start W3 --> finish W3 --> finish W2 --> finish W1.
What you can do is, add "Commit Pending Changes" action at the end of W2 and W3, this makes sure that after executing the "Comming Pending Changes" on W3, it returns to "W2" and executes the "Commint Pending Changes" in W2 and then it returns to "W1".
Thanks,
Krishna.
Sadly adding the Commit Pending Changes to the workflows has no effect, and W2 resolves before W3 is finished.
Meh.
Thank you for the suggestion though!
what environment does this happen on?
does it happen consistently or randomly? (I wonder whether time needed to load and compile workflow might play a role - if it takes too much time start workflow action need not be notified within a timeout)
I'm quite heavily starting workflows in a chain and have never experienced anything like this (NW2013 on-prem)
have you tried to capture workflow instance ID of the workflow being started? does it return anything?
maybe I'd try to remove start workflow action for W3 and add and configure it once again. I've seen cases some action behaved differently then configured, especially if they were copy&pasted.
have you tried to put pause action at the beginning of the (child) workflow(s)?
Yeah... Probably should have included the environment details being that I ask for them from other so often...
SharePoint On Premise 2016
Nintex Workflow / Form 2016, version 4.2.2.0
I went ahead and made a little test list with some test workflows to see if I could replicate what I am experiencing.
There are two Columns on the list that are important.
rToggle], Yes / No
rOption1], Choice (None, Partial, Full)
------------------------
I have (3) Workflows that should initiate. The first (1 - Workflow Router) has automatic start options, but will start the second (2 - Process Toggle), which will start the third (3 - Process Option).
All Start Workflow Actions are configured the same way.
Start Immediately - Yes
Wait For The Workflow To Complete Before Continuing - Yes
Do Not Start The Workflow If It Is Already Running - Yes
Below is the exact layout of each workflow.
1 - Workflow Router (Automatic Start Conditions: On Item Creation, On Change When nToggle](Previous Val) !== =Toggle]
Note: As shown above, there is technically a 4th workflow called 4 - Toggle Off, but it was just included for completeness and has no bearing on this experiment.
Start Conditions:
2 - Process Toggle
3 - Process Option
By Creating a New Item, like:
It will kick off the first workflow (1 - Workflow Router).
However, the history tells the rest of this story:
Workflow (2 - Process Toggle) is finishing before Workflow (3 - Process Option)!
Looking at 2 - Process Toggle more closely...
It just completely ignores the Wait on the Start Workflow Action!
That being said... Let's take a look at Workflow 3 - Process Option's history a bit more closely.
Not only does the Third Workflow start a full 5 minutes after Workflow 2 has ended (or tried to invoke it), I also notice that the delay Pause For 5 Minutes I threw in there to simulate 'work', actually doesn't resolve until nearly 10 minutes later...
I'm not sure if this is correct, or if it is indicative of some majorly bad Timer Service mojo, but it might be important information for somebody who knows a lot more than I do about the SharePoint side of things (which I am still grossly under-learned in).
Another strange thing that I noticed with this test were the Notification Emails that I have coming to me. There were extra notification that, as far as I am aware, should not exist!
Both of the notifications come from the same Workflow Instance ID, but there is nothing in the log to indicate that it was sent twice, nor are there any additional Notifications that exist on the Workflow... just a 'STARTED' and a 'FINISHED', but for some reason the first one is sending twice...
Everything for these workflows was made fresh with no copy / paste of actions.
I'm not sure what you can divine after seeing this, but I certainly don't think that this is an expected behavior.
My guess is that maybe something in SharePoint proper is disgustingly misconfigured, which makes me extra sad.
Thank you for your time and help!
Hi,
I tried simple way, in SharePoint 2013 on-premise environment, WF1 starts then calls WF2, but WF2 errored out then WF3 is started, WF1 completed and finally WF3 completed.
WF2 workflow error message is - already an instance of a workflow, WF3 is running on same item in the <sitename>.
I think it is better contact Nintex Support.
Yeah.
Thanks for trying it out and getting some results!
I suppose I'll start barking up that tree
Another strange thing that I noticed with this test were the Notification Emails that I have coming to me. There were extra notification that, as far as I am aware, should not exist!
add pause for... action as a very first action to each workflow. that should resolve it.
this is known problem/'feature'. nintex says it's caused by sharepoint.
workflow started on item creation event is being executed by worker process.
once you put a pause at the beginning, workflow is queued immediately and when pause elapses it is then executed by timer job. for unknown reasons workflows being executed by worker process experience problems like this, whereas once executed by timer service everything is ok.
more on the topic here - Defensive Workflow Design Part 4 - Slow Down and Speed Up
probably 'Wait For The Workflow To Complete Before Continuing' is influenced/confused by these several workflows being started in parallel as well, and it stops waiting on a false event from not 'proper' instance
chain of workflows wait for the workflow to complete before continuing pause for action slow down or speed up
Yeah. Ultimately it seems like using the Pause For... Action is the only way to approach this.
It would be nice if I didn't have to artificially hinder the progression of things (because let's be honest... Users want thing to be just as fast and instantaneous as Facebook or any other responsive service), but SharePoint has its particular infrastructure that Nintex can't really ignore, so, Pausing it is!
Thank you for your help and considerations!