Scheduling a workflow that is reading XLSX files from a local mapped Google Drive location

[AkisM]

Hi, we're trying to schedule an alteryx routine on the server that is reading .xlsx files from google drive. We can't use the google input tool for other reasons so I went with a workaround that uses the default alteryx input tool, which I'll describe below:

Using the google drive desktop app, by signing into your google account you can stream your google drive to a local folder or virtual drive. When the routine is run locally it works fine. It is using the regular alteryx input tool, pointing to that specific virtual drive that Google drive was mapped to for that PC, and it reads files from it normally like it would read files from any other location. But when we upload the routine to the server, obviously it fails to find the google drive path, as no such mapping exists on the server machine. Any advice?

Another potential workaround we considered is designating for example my PC as a controller, and scheduling the routine to run locally, as the mapping is set up already for my pc. Would that work or am I missing something? What are the pros and cons of this approach instead and is there a guide on how to set it up?

[Felipe_Ribeir0]

Hi @AkisM 

It is possible to do the same that you did for your local machine (stream your google drive to a local folder or virtual drive) to the server machine?

[AkisM]

@Felipe_Ribeir0 I'm looking into that with the server admin, but as it may be slightly more complicated I'm also looking into what other alternatives we have.

[salbol1]

You are likely running into an IT defined restriction in your environment that doesn't allow that connection to that drive to remain persistent so that it can be run from your server's scheduler. That's often seen, and is either supported with a policy exemption or not. Normally other creative means around it has to be found - like pushing things to SharePoint and obtaining access to those elements with a firewall/port request to be able to access your SP tenant's backend.

I've found IT teams are far more pliant to the latter request, at least in larger, more spider-webbed hierarchies.