Try one thing first before you quit your job: take one small portion from your workflow and put it in a new test workflow. Save and publish it. If that works, I'm going to 'assume' the workflow could possibly be too large and has nothing to do with rebooting.

This is going to sound very beginnerish but how do I grab a portion of a workflow? Snippet grabs the entire workflow.

My workflow works like it should, I just can't add or modify it at this point.

I don't mean anything technical by the way I said it. I just mean create another test workflow. Recreate a small portion of your workflow there. No need to do a whole lot this is just a test. Save and publish it. If this is a problem deep in admin world, it won't work. But this may indicate if it does work it may be the size of your workflow or an error or something in it.

Hi Josh,

I think there are a lot of strategies that you could implement here to get this thing going.  How many actions are you talking and when you export this workflow what type of file size are you seeing?

1) Optimize - do you have unneeded actions?  (Log to history? Lots?? Remove- delete.)

2)  Optimize more, as a Nintex Consultant I see LOTs of workflows and I re-architect Nintex solutions on a daily basis.   Sometimes there are ways to cut 10 actions down to a single one.   This of course takes knowing, but just rethink some of the areas you think "might be suspiciously over developed" and if all else fails, post here and ask for advice.

3)  Before you quit your job, use Action Sets.   Actions Sets are cool, because you can turn them into Snippets by clicking the drop down arrow and clicking Save as Snippet.   Snippets are reusable groups of actions across your workflows.  This means you wouldn't manually have to recreate everything if you did have to split this workflow into a few others.   Snippets become as simple as drag and drop actions.

Let's start with the above and go from there.

Thanks,
Mike

You can use action set to grab small portion of WF

Are you using any custom forms for flexi task.

How many actions does your workflow contain anyways?

Hey Mike

Just reading this, I am excited to try some new things to maybe make this better. I will explain what I have done.

So I have a list to where the end user audits a specific set of loans. Their one audit could have up to 12 defected loans but could have multiple remediators assigned to each defect. I had this setup as one task/email completion but I was running into an issue where not all or majority of assigned remediators were completing the task so the flexi task completion email wasn't going back to the auditor. I then created individual workflows for each defect, which took me forever because there are multiple flexi task steps for each defect (ie: approved, rebutted, denied). Someone suggested that I use the parallel actions so this is where I am right now. I have attached a screenshot and each run if is a defect (12 of them). This is incomplete as I still need a final flexi task back to the auditor (you will see a single email notification action at the bottom) but haven't been able to do so. All of these flexi tasks have custom made forms and everyone is different because it is built specifically for each defect. This is sending tasks/emails to each assigned remediator(s) for each defect. I would graciously accept any feedback or suggestions to streamline this a little better. I didn't know size was going to be an issue when I started building this. This is not my fulltime function here at work so I am trying to avoid rebuilding...again!

Thanks in advance!

Hi Sojan

Yes I am. If you see above, I explained to Mike. Thanks!

Hi Enrico

I just explained more to Mike, above. Hopefully, this gives you more info you need to assess? Thanks!

Hi Josh,

On a positive note: no one will ever be able to call you a liar for saying that you had a really large workflow.  

Now it's hard to grasp the exact intention here without digging into the details of your actions, but the layering of parallel actions (at least the first 2 or 3 layers) seems peculiar to me.  What I am saying here is that I feel like you could achieve the same thing with less parallel actions involved.

The second thing I would ask is the "Set a Condition" sections that each grouping appears to have: what are the conditions they are checking, and is all the information inside of them unique as well (the emails and tasks?)

So I'll be honest and say that a lot of times I see users using Parallel actions where a "Start Workflow" condition should have been used instead, which may or may not be the case here.   This tends to go down the path of separating out workflows though.

On a side note, it seems that you went one direction originally but then ran into a scenario where someone wasn't completing a task. Were you aware of the "Escalation" feature built into tasks, as well as "Reminders" that could very well both annoy and force the completion of a task?    

I will also say that "Task Forms" and the data contained on them are a huge contributor to your workflow file size.  The forms themselves are likely causing the errors you are seeing.

I'll end this by saying that I completely understand that every business process is unique surrounding the needs of its users/managers and what works for some is out of place for others.   The more info you provide here the better for others and myself to help understand the reqs.

Thanks,
mike

Hey Mike

The second thing I would ask is the "Set a Condition" sections that each grouping appears to have: what are the conditions they are checking, and is all the information inside of them unique as well (the emails and tasks?) - These set conditions are checking to see if there is a remediator in a specific field for each defect.

On a side note, it seems that you went one direction originally but then ran into a scenario where someone wasn't completing a task. Were you aware of the "Escalation" feature built into tasks, as well as "Reminders" that could very well both annoy and force the completion of a task?  These flexi task go into different directions because they could agree or disagree with the defect and then it would trigger a flex task for a re-review so to speak. The task completed/not complete from the Flexi Task is only to trigger the set conditions. It doesn't matter what is selected there.

I will also say that "Task Forms" and the data contained on them are a huge contributor to your workflow file size.  The forms themselves are likely causing the errors you are seeing. The list itself is really big (lots of columns and rows) and the form I have has pretty much all of the columns, on the form, are informational to the end user.

This is definitely huge! But I will say mine is running right up there with ya! I go back to where I recommended calling other workflows. I'd call them where each of the Parallel actions are. Your workflow will not look as large and it will be in more modules - like code. Make sure in the Run if's you hide logging. That takes up a lot of performance too with all the writing to logs.

Running so many parallels isn't so awesome.. Are you able to break this it logical stages ? which you can then force through a state machine to make the necessary switches and decisions etc.. Or as ‌ was saying, breaking this down in to multiple workflows.. So you have a parent and child relationship..

Hey Dan

I have never used State Machine so I have not considered that an option. I have it working but if something breaks, or if an enhancement is needed, I am in trouble. I think I will just have to break them up into separate workflows. When I can find the time to do so. i have about 60 or so workflow projects going on right now (all are similar) so it's been a full time job.

I would start looking at the State Machine then.. for sure..  Check out this post by Jesse McHargue‌  

Hi Josh, 

Somehow I missed your response to my last response and never replied.  Anyways, I do agree that breaking this workflow up would be beneficial.  Remember my advice in the first post about using Action Sets so that you aren't manually recreating everything.   It should port over to new workflows fairly quickly.

Thanks,

Mike

If you are using forms and any error (incorrect syntax) validations or rules can lead to this issue. If you remember the last action you did before getting the error. Try undo that. Or if forms not many just try deleting it. Better export the forms before deleting it.

Mike

I surrounded each run if inside an action set and saved each one as it's own snippet. Now when I try to create a new one using one of the snippets, it does nothing when I drag and drop the snippet onto the canvas. Any other ideas?

Thanks.

I have the same problem, it used to work. but is not working now.

What version are you on?  Also do you have the site added to Compatibility mode in the browser?    I've noticed sometimes having it there and the lack of having it there can have different produce different effects with how the browser reacts to the drag 'n drop actions.  I actually had to remove a site from compatibility mode once to enable the ability to drag and drop actions again... (Strange right - compatible makes less compatible..  this I seen in one of the latest versions ) so it does seem to vary with each version of Nintex.

I am on SP13. I am going to plead ignorance with this but I a not sure how to change the compatibility. I am doing this for the company I work for so my administrative access is limited.

No problem, its set at the browser level.  Just click the little gear in the upper right hand corner and you'll see Compatibility View Settings options in the drop down menu.   Click on that and then see if the domain exists in the list of sites.   If its there you can try removing it and restarting your browser.   Otherwise you can attempt adding it and doing the same.  This applies to IE.

I am also faced the same issue, then I have tried with Chrome browser which working me. Try it with Chrome browser.

Hi Josh,

What is the size of the workflow when you export it?

Regards,

Shrini