Gallery Scheduled Workflow: Output File to SharePoint

Shelton_Thompson

Hello

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?

KevinP

@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.