Copy task attachments to Master Item on O365...

  • 16 February 2019
  • 10 replies

Hi all,


just to give you the context, my company is working on a 300 workflows tenant splitted into a lot of site collections.

We have built a component workflows called "Copy TaskAttachments to Master Item" that copies the task attachments to the underlying item. It also update the NFFormData field to put the attachment not only in the "default" attachment components, but exactly where the attachment should be in the form (this part is not detailled in the post).


It works 95% of the time ! I'm here for the 5 last %


First, a few tips, if you want to do it too...

  1. Inside a component workflow, First do a POST webrequest call on {Variable:Current Site URL}‌/_api/contextinfo to retrieve the FormDigest.
  2. Retrieve names and URL of your task attachments using another GET webservice call on "{Variable:Current Site URL}‌/_api/Web/lists/getbytitle('‎‏{Variable:Workflow Tasks List Name}‌')/items(‎‏{Variable:Task Item ID}‌)/AttachmentFiles


    Retrieve URLS and files and store them in some collections...
  3. Create and delete a Dummy file (just to ensure that the "Attachment" folder is created using another webservice call  on
    ‎‏{Variable:Current Site URL}‌/_api/web/lists/GetByTitle('‎‏{Variable:List Name}‌')/items(‎‏{Variable:List Item ID}‌)/AttachmentFiles/add(FileName='dummy.txt')
  4. Then loop on those collections and call the POST HTTPService
    ‎‏{Variable:Current Site URL}‌/_api/web/getfilebyserverrelativeurl('‎‏{Variable:Attachment URL}‌')/copyto(strnewurl='‎‏{Variable:List Relative URL}‌/Attachments/‎‏{Variable:List Item ID}‌/‎‏{Variable:Attachment File Name}‌',bOverWrite=true)
    and for that use the following header

    You retrieved the {FormDigest} from the initial call.
  5. Package it...test it... it fails if you run it on another site/sitecoll with the status code "Forbidden" on the CopyTo service call ! Basically, your remote workflow app doesn't have the correct access on the local site. To solve this problem, follow the link :
  6. You have now given the correct rights to your app... and now it should run properly.
  7. Here is my problem now...

    It runs most of the time, and for a few cases , the copyto Webservice call gives us an "Unauthorized" status code without explanation.

... we have been investigating for weeks now, and I have no clue on the solution!

We tried the following :

  • The formdigest is maybe wrong,but why then it would work on all the hundreds of other workflows?
  • The permissions have been updated on the site : Can't be...I have tried with my own admin account, same behavior.
  • We checked and the "workflow can use app permissions" feature is activated everywhere.

any idea would be appreciated!



Best answer by allan 14 March 2019, 14:28

View original

10 replies

Hi Alex,

You mention a that this fails in a few cases, is it the same workflow/users/site where this fails, or is it randomly failing (e.g. same user runs the same workflow 20 times and one time it fails).


Hi Callum,
sadly not! Any user running some of those workflows are having the issue. Even me with my site coll admin account.
So, I wouldn't try to investigate on the user.

This was a tricky one, but I think I solved your issue!

The issue is because the REST call is limited to 400 characters, so when setting the URL, the variables are replaced and you can have a really long URL.
Just imagine doing this on a subsite ("/sites/MyProjectSite1/MyProjectSite11/MyProjectSite111"), add the length of the list name and the name of the file ("maybe_you_have_a_really_long_file_name.pdf"), it can become huge quite quickly.

The trick is to use REST query with parameters.
Instead of :

{Variable:Current Site URL}‌/_api/web/getfilebyserverrelativeurl('‎‏{Variable:Attachment URL}‌')/copyto(strnewurl='‎‏{Variable:List Relative URL}‌/Attachments/‎‏{Variable:List Item ID}‌/‎‏{Variable:Attachment File Name}‌',bOverWrite=true)


{Variable:Current Site URL}‌/_api/web/getfilebyserverrelativeurl(@v0)/copyto(strnewurl=@v1,boverwrite=true)?@v0='‎‏{Variable:AttachmentURL}‌'&@v1='‎‏{Variable:List Relative URL}‌/Attachments/‎‏{Variable:List Item ID}‌/{Variable:Attachment File Name}‌'

The parameters (@v0 and @v1) are not counted in the the length of the request, only what's before the "?". That's because it is not replaced at runtime by Nintex, but is interpreted by the SharePoint API, it accepts long URLs, but not long function calls.
This did the trick for me.

mate, how could I do without you ?

Thank you for your answer blog. I have done the feature. Really Great.


I'm new to the nintex thing so forgive teh stupid question anyway for teh current site url are you using a variable or workflow context?


I am using the workflow context ;)
Whenever possible, use workflow context.

Hi allan,

I need to build the same solution for my customer, I set all the things as I can already, but I still have the below error in Workflow History when action is in "Add file" :

403: {"error":{"code":"-2130575251, Microsoft.SharePoint.SPException","message":{"lang":"en-US","value":"The security validation for this page is invalid and might be corrupted. Please use your web browser's Back button to try your operation again."}


After I check in Google...etc I think that may caused by the Form Digest, but I already generate one before it, may I have your help please? I have no ideas after I did it for 3 days...(sad


Thank you so much!


Hi @yannisfan 
if you already generated your Form Digest using a similar approach as the screenshots below, then it probably caused because the Form Digest expired. I'm not sure how long the token is valid, but it's only a few minutes. So if you get your Form Digest at the beginning of your workflow and try to use it days later when the workflow continued its execution, then the token will no longer be valid and it won't work.

To use ‍{Variable:Current Site URL}‍/_api/web/lists/GetByTitle('‍{Variable:List Name}‍')/items(‍{Variable:List Item ID}‍)/AttachmentFiles/add(FileName='dummy.txt'), you do not need the Form Digest though. Are you using the correct headers ? 

  • Content-Type : text/plain (since it's a .txt file)

  • Accept : application/json;odata=verbose




Thanks allan,


I tried it but it didn't work for me. I think it may related to the version of SharePoint ...etc

I used the action "Call HTTP web service" instead of "Call Web Request" with the action details from you, I think that is interesting discovery when using nintex ( lots of solutions

Finally, I would like to express my thousand thanks to you for your quick response : )

hope to share and discuss with you again in future