Does anyone have any insight as to why, for my workflow, that when I use a set condition the workflow works flawless, but when I put in a state machine above it. it gets stuck on change state after the first change state. I can even put an email action on the yes side of condition and it will send the email but as soon as it hits the change state on either side, it just gets stuck. I tried searching the net and could not come up to a conclusion.
I can't tell from your screen shot, but do you have a "Change State" action on both paths of your Set Condition? If not, that could be one issue.
Other possibility is it could be a problem with the timer jobs. This post goes into some detail on that.
I do have change states on all branches, whether referencing a state or end state. I talked with our admins and they state it would not be a timer job as it works without the change state.
Any other ideas?
can you put the change state after your set condition like this:
Same issue when nested under the condition.
Why doesn't incoming submittal branch in your state machine not have a change state? It needs one.
DOH!!!!.... that was an over sight this time around....uno momento por favor
I've just read my poor English in that reply - bravo for understanding it!!
Cassie,
The English was just fine. I redid the WF and ended up with same result the workflow just gets stuck.
Ok so it goes down the left hand branch, sends the email and gets stuck? What is the pause for doing? Why do you need that?
Have you checked timer service is up and running? Does it change states after say 15 minutes?
I was setting the pause due to, that when it works fine under the Set Condition with no State Machine, I was getting the Request Data before a notification, but I tried it without the pause and it still does the same. That is the second screenshot with the history(no pause).
OK do me a favour please Pete; create a brand new workflow with just a state machine in it - give it three states each having a log to history of some arbitrary text and a change state like this:
Run it and see if it works. This way we can see whether anything else is impacting the performance.
The fact that the workflow works without the State Machine is exactly the reason it would be a timer job issue. Did you read the article I referenced?
Did as you wish and same result....
As much as my IT is stating not the timer job, I am inclined to agree with , and it's the timer job
Thirded (not sure that's a word but you get the idea)!
Well I am back at step one. I appreciate your folks insight to a newbie. So all the research I have done is not in vain and makes me feel better I am not crazy as well as knowing IT just will not listen to me.
THANK YOU!!!!!
Hi Pete,
This will probably not help at all, but we have two environments SharePoint 2010 and SharePoint 2013. We had the same issue with SharePoint 2013. built a workflow in the 2013 environment and it kept getting stuck. He also built this workflow in the 2010 environment and everything worked perfectly.
Back in 2013 we checked the safe looping setting on the central admin and that was fine and then we ended up restarting the timer job as well as IIS. We eventually ended up restart our whole SharePoint 2013 environment and the issue seemed to have gone away for now but without know what actually caused it.
I too believe its an environment issue. Without a state machine, what occurs with just a pause action. Does the workflow come out of a pause and continue without issue? What about using a loop? These can help to troubleshoot the environment.
Use the tips in the document linked earlier. Make sure there are SharePoint and Nintex patches applied where appropriate.
Ooh good shout you could also try "start workflow" and see what happens with that.
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.