Skip to main content

We are trying to upgrade SharePoint and Nintex to 2016.  I am testing a workflow that works as expected in the current version (2013) but does not work in 2016.  I am using the Copy to SharePoint action, where I actually have a specific URL set, but it uses two workflow variables to populate parts of the URL (since properties of the document and the workflow will determine the exact library to which it is to be copied).

I have attempted both clicking on Insert Reference to type in the entire URL with the workflow variables and typing the URL in the box on the configure action page and just clicking on Insert Reference in the place of the URL where the workflow variables need to be added.  Each time it appears correctly, but when I save, then click on Configure to check it, I find that something in the URL is different.  Examples include adding an extra "/", dropping one of workflow variable or adding slashes and the same workflow variables twice.  On occasion, when I click on configure, I can correct within the URL box, but when I try to save it, either nothing happens or I get a pop up box that says the site is not responding due to a long running script, then gives me the option to stop the script.  If I just close the box and try to save again, I get the same pop up.  If I click on Stop Script, nothing happens when I click on save and all I can do is close the window by clicking on the X and my changes are not saved.

As I indicated, this process works fine in SharePoint / Nintex 2013.

Sounds like a client based problem.

Is the workflow running as expected when you insert a static url for testing purposes?

Also, does it work when you try to set up your url in a separate "set workflow variable" action and add the combined url as a single variable into your copy item action?

Perhaps you didn't mean your first comment in such a derogatory manner as it was initially taken. 

To answer your two questions, yes it works when a static URL is used but when I tried your second suggestion, the same issue occurred as I experienced previously, where an extra "/" was added and one of the variables was dropped.  However, when I edited it in the box, it did save it correctly, which is different than what I experienced when I tried it in the Copy to SharePoint action.  So this may be workaround for now. 

If there is an issue with either our installation of SharePoint 2016 or Nintex 2016 that is causing this issue with the Copy to SharePoint action, I would like to know how to tell our technical staff how to correct that, rather than always needing to use this workaround.

Oh sorry, didn't mean you as client but the local computer which is often referred as client computer to distinct it from a server computer (SharePoint server). I'm sorry for the ambiguity.

In the past I saw a couple of scenarios where it was more robust to build strings outside of the actions where they are finally needed. So my advice would be to use this approach as the first workaround if something is not working as expected. I don't think there is an issue with your installation.

However you can always pass this behaviour to Nintex support. They can investigate how the strings are merged in the Copy to SharePoint action and maybe provide an update or further information on how to avoid the initial behaviour.

Regards and again my apologies,

Enrico

So after implementing this proposed workaround during our upgrade, I am now trying to do additional testing after the recent MicroSoft IE CU and am having the same issue with the variable not properly saving the URL and thus causing the workflow to fail. Just as before, it is adding / and removing variables from the URL, thus resulting in an invalid URL. Please advise when this Nintex issue will be resolved or if there are other options.

Could you post the output of the wrong built link? It might help identify what is going wrong when composing the URL.

Could you also post the version number of the SharePoint 2016 Workflow installation?

The URL is supposed to be .../real/VarRegion/VarProj/Budget .  However, it is getting switched to .../real//VarRegion/Budget.

Version 4.0.1.10

Hmm this is strange. It seems that VarProject is missing, however the additional slash is before VarRegion, not behind it as I would expect it.

Have you ever reached out to Nintex Support with this? It seems a more deep problem and as recently patches haven't helped it might be better to go through it with them directly.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings