Showing results for 
Search instead for 
Did you mean: 

alteryx server Discussions

Find answers, ask questions, and share expertise about Alteryx Server.

Gallery Scheduled Workflow: Output File to SharePoint




I have a workflow which the final step is to output a file to a SharePoint.

I planned to save this to our gallery and schedule it to run every hour so I had my user credentials setup as the Run As User as I have read & write access to the SharePoint.


When testing, the workflow works fine when running on my desktop, and when publishing to the gallery and setting my Run As User credentials I get the error "Cannot Access the folder \\Sharepoint file path\ -Tool 1-Unable to reach SOAP API (Check URL), so I tried saving it to the gallery without defining any credentials and the error is resolved. and it saves correctly but when running in the gallery to test before scheduling I get the error "Error creating the file " FILE PATH ": Access is denied. (Tool Id: 11)"


I did grant the default credentials for the server read//write access to the SharePoint folder so I am assuming its more of that since it is share point 2013 it requires a domain + user name and the way the Alteryx Server is presenting the credentials to the SharePoint site isn't matching, but again just my assumption.


Has anyone found a way to output a file to a share point document library on a workflow published to the server?


@Shelton_Thompson We only support reading and writing to SharePoint lists using the SharePoint connectors available in Designer. Reading and writing files to SharePoint document stores via UNC paths is not supported. This is primarily due to complications/limitations with authenticating to the SharePoint resources when workflows are run from Scheduler or Gallery.


Specifically, when we run a workflow via Scheduler or Gallery it runs as a sub process of the service in session 0 which is a non-interactive session. Because of this SharePoint will typically prompt for credentials even though we are providing the Run As credentials when attempting to connect. Since the process is running in a non-interactive session the credentials prompt can't be rendered to the screen for the user to re-provide the credentials, and as a result authentication immediately fails. This causes the access to that location to fail and we report the access denied errors you are encountering.


Some customers have been able to work around the issue by making changes to their SharePoint servers authentication configuration, but other customers have had no success making the same types of changes. Because we have no control over if SharePoint prompts for these credentials or not there isn't anything we can do to prevent the issue, and this is the reason we can't support this type of connectivity to SharePoint.




Did you ever find a solution?  We're running into the same issue.






Do you know what specific changes were made by the customers who were successful? I work in the same org as OP and we still have this issue.

Unfortunately no. I can read files from SharePoint but have been unable to write files to a SharePoint Document Library. My current workaround is using network shared drives which is not ideal. 

I would love to see Alteryx build a connector to connect to SharePoint document libraries to both read and write files. 


The other solution I have been exploring with our IT group is using Microsoft Flow and telling that to copy the file from the network drive to the SharePoint list anytime it is updated, which again is not ideal but may be a workaround to accomplish the same thing more automatically. 




@Shelton_Thompson As noted above this functionality currently isn't supported. However, if you would like to see supported functionality for accessing SharePoint document libraries you can contribute to the following product ideas post:


Not sure how to @ someone but Kevin, you mentioned earlier some customers were successful by changing their Sharepoint authentication settings, do you happen to have anecdotal solutions that you can share? Our problem was identified as a likely MFA issue with Sharepoint, but we haven't truly rooted out the problem.


@aquinta4 Unfortunately, none of the customers that have managed to get this working have shared exact details of the changes with me. I am also not a SharePoint admin so I am not sure I would be able to make recommendations here either way. I did have one customer that got it working state they changed the authentication type to NTLM, but I have no idea what settings they changed to do this. Also another customer stated changing to NTLM didn't work for them so your mileage may vary.