I have some problem with a workflow for a customer. The issue seems rather strange to me and I have been looking for an explanation for some days but with no success. Maybe you have another idea what could be the source of the problem.
This is the problem area of my workflow:
As you can see I have parallel tasks. My requirement is to check if everybody who gets a task assigned does approve it ("Ja" = "Yes" = means approved). Therefore I created a variable which is called "var_bedingungsloseZustimmungOEs". This variable is set to true right before the tasks are assigned (default value is also "true" but I need to set it again because I'm working inside a state machine and this state could be processed many times). If any of the task assignes does not approve the task ("Nein" = "no" = means rejected) i set this variable to false. After all assignes have responded to their respective task, I check if the variable is still true. And this is where the funny part starts.
Point 4 is the problem. My evaluation variable is set to true again, but why? I dont have an action in the "Ja"-path that set this variable to true again. It seems like the system is doing it automatically.
But it gets even more weird. To solve the problem I tried to give every task assignee an own variable and afterwards I checked if all the variables are true. But even using different variables the fault remains the same. As soon as one of the assignee say "yes" all other variables are set to "true" again even if another assignee has rejected before and his variable was set to false already. I tested it on two completely different machines and have the same problem on both.
I also built up another test workflow where I simply put in two parallel tasks with one variable and there it works fine! So I think it has to be a problem related to this specific workflow. If I take the second task out of the "run parallel actions" it works just fine and my evaluation variable is not overwritten.
To me this sounds like a bug in Nintex but I wanted to ask the community if someone maybe witnessed something similar or can even show me what I seem to be blind for...
Any help or advice is highly appreciated! If you have questions about the implementation of my workflow, please don't hesitate to ask!
Thanks in advance
p.s.: I'm using the most recent Nintex 2013 Version 18.104.22.168 but the problematic workflow was built on an older version of Nintex, don't know if this could be the issue.
Solved! Go to Solution.
You said that the default value is set before you assign the tasks but you are inside a state machine. Could it be that simple that it runs over setting the default value again and again?
Why are you not using the built in decision makers like "all must agree to a specific outcome" or "all must agree"? Does that not fit? Afterwards you still can evaluate the stored outcomes, use the hidden "other" path or even use the approver comments for getting the real results using a regular expression which gives you the "Approved" and "Rejected" results which then can be counted against the number of assignees and then point your workflow in the right direction.
at least the worklfow shouldn't reset the variable to the default value, but that maybe the problem (I just don't see why it behaves like this).
We chose to create different task for every assignee because it gives us more flexibility over the process. However, your suggestion would probably be the easiest workaround. But I really want to find out why it doesn't work like this. Our customer already created a support ticket, if there is no satisfying answer to this problem, we will try to do exactly what you mentioned.
when you tested with several variable, were their names as long as one on screenshot?
I would try it with shorter names.
do you possibly set variables within task form?
I have to admit that I don't remember how i named the variables. Can't look it up right now because it was on the customers testing environment. But I may give it a try. Did you ever had problems whit that? I wouldn't say my variable-names are too long and I don't know any threshold regarding this. But I'm desperate enough to try anything
No, I don't set the variables in the task form.
Nintex Support already had a look at it but refused to get active because the workflow is too big (couldn't be published when they added their logging actions). I wonder how to meet the best practice (500 kb per workflow) though, if one of the task forms is already above 500 kb...
However, I reduced the workflow-size (from 3,5 mb to ~1 mb) and still had the same issue.
I'll keep you informed if I get any new information from support.
Allright, with the help of the nintex support team, we finally found at least a hint to the cause of the problem.
The problem is caused by the task form we have created with Nintex Forms. To be more precise, it is caused by 3 Workflow-Variables we are using as text input for some labels and a mutli-line text field where i store my attachment-html links I created in the workflow.
As soon as these variables are deleted from the form or the whole form gets reset to SP-standard task form, the workflow works correctly and does not reset my variables to the default value anymore.
I do not understand the relationship between using some variables as text input in my task forms and WF-variables being reset to their default value after completing a parallel action as it obviously doesn't make any sense. However, the case has been transfered to the development teamn of Nintex and I hope to receive an explanation soon.
If I have an update on this one, I will let you know!
Thanks again for everyone who tried to help me!
I'm terribly sorry but I forgot to update this post with the information I received from nintex development team.
After further investigation, in order to get the correct value from the result of Task Form there are a setting that need to set up to Yes. Please open Form Setting > Advance > Load realtime workflow data (set this into Yes).
Since this answer took some months I already implemented a workaround in the meantime. And because my workaround was then working and the project was already finished, I haven't tried this solution yet. However, maybe someone else having a similar problem can make use of this information.
p.s.: Thanks Marian Hatala for mentioning me in his post and reminding me of my own post