Skip to main content

I have a workflow that keeps cancelling for no reason at the Flexi Task level. IT does this immediately when the workflow is fired or terminated then refired. Before the flexi task the workflow doesn't do much except set some variables and a couple of fields in the SharePoint list (I have built an Infopath form over the list FYI) it also sets individual Item Permissions on the list item. I have checked and the initiators and approvers in the Flexi task all have contribute rights to the list item. Any ideas. Thanks very much in advance.

do you get any error?

do you get any outcome?

have you tried to configure OTHER branch whether flexi task wouldn't go down that way?

what do you exactly mean with this:

when the workflow is fired or terminated then refired

when you start the workflow and then you start it once again, you get a error?

when you terminate the workflow and then you start it once again, you get the same error as well?


What are the starting conditions for your workflow?  Does it start automatically on creation or modification or is it purely started manually?

Are you saying that when it starts, the flexi task gets cancelled?

I can see why the flexi task gets cancelled if you terminate the workflow, that is expected behaviour.


Hello Marian thank you for your reply. I will answer your questions in order

Yes I get Error Occured the exact message is "An error has occurred in Job Open Form Workflow."

No outcome it just errors.

This workflow is fairly linear. It hits a State Machine and Immediately hits the Flexi Task where it just cancels. I will attach a screenshot

I created a very simple workflow that will terminate any running workflows and just restart the main workflow that I'm talking about

Yes to both the last questions

I hope this helps.

NintexWFError.JPG


Thanks so much for your reply as well Cassy.

It is started upon creation of a list item.

It actually officially says "Not Required" you can see in the screenshot I posted for Marian

I only terminate and refire after the error.

Does any of this sound like something you've seen before?


I haven't seen this error yet.

some hints, thought

- I would definitely put a commit pending changes or pause action right before flexi task.

you  perform some item updates and permission changes down the way and they need not be effectively be applied before flexi task is reached (if you eg. grant permissions for task approver). see following link for further insights Designing your Workflow - Commit Pending Changes Action NW2010 & NW2013

- the error message reference some 'Job Open Form Workflow'. 'job open form' sounds a bit uncommon wording.

anyway, I would check whether task form is valid and there are no errors on single controls or in javascript.

if you couldn't spot a problem there, try to export the form definition (to have a backup) and then remove. that way default task form is restored.

try to run workflow whether flexi task will correctly in this setup.

- due to uncommon and unclear error message, if you have customized workflow start form, try to check its validity as well.

but that doesn't seems likely to be a reason since several workflow step has been executed.

if above will not help, post configuration of flexi task as well.


Agree about commit pending changes after the Permission changes. Though I wonder what permissions are changing to on what item. Also, is the task able to identify the user it is assigned to? I've seen that post a Not Required. Can you assign it to yourself and create the task?

Also, what user is publishing the workflow?


OK so I tried the Commit Pending Changes and it didn't work even tried a Pause and it didn't work. BUT I disabled the Item Permissions and lo and behold it went through. Now this is a fairly heavily used list and has been so for almost a year. That workflow was working up until about two weeks ago just the way it was. Any ideas on what could have happened? And more importantly what can I do here. I need those permissions.


Hi Andrew as I replied to Marian something's going on with the permissions for sure. To answer your question yes it is able to and no I can't assign it to myself. The odd part is I conducted a test with some of my end users and it worked.

I'm a little unclear do you mean what users are firing the workflow or actually making changes to it and publishing?


since you say it's heavily used list, any chance you hit limit of  max possible permission settings per list?

https://technet.microsoft.com/en-us/library/gg128955.aspx


Great feedback. The workflow will run under the context of the initiator and their permissions. What is the Set Permissions action supposed to do(add/remove permission) and for what item?


Hello Marian and Andrew to answer your questions we're at 4k items at the moment with a 15k threshold so we're good on that front.


The Set Permissions action is modifying the list item to only be viewable by the approver SP group and the Operating Company (we have 8 OpCo's and they can't see each other's items) as well as give another SP group Read permissions.


Thanks for the followup. What are you using the Action Step for in this scenario?

Also, I still recommend a commit pending changes before and after the set permissions. For the full explanation as to why, please see Designing your Workflow - Commit Pending Changes Action NW2010 & NW2013​ that Marion pointed out earlier. Not having this can make toubleshooting difficult as the permission change could be happening out of order.


Hi everyone I've figured it out! I use an SP list that my workflow looks at to determine what people and groups get added to the individual item permissions. Turns out one of the users in that list no longer works for the company and that account was deleted. So the workflow would error when trying to add that account to a variable. Good to know for future reference. Thanks everyone for your help!


Good to know and thanks for posting the details. So the workflow wasn't able to identify all assignees in the end. Go ahead and mark your last post as the answer, I believe this will be vital information for others with similar issues in the future.


Reply