Local and Remote Data Connections

[EEdLoh]

The current setup of Data Connections, as of v11.3, relies on users to have the same aliases or connection strings available to easily share Workflows and publish them to a Gallery. In order to solve this, I propose that a system be created that allows users to establish "Local" and "Remote" connections. The Local connections will be used anytime the developer is creating a Workflow on his own computer, but will be automatically substituted with the Remote connection information once the Workflow is published. Remote connections may be filled with an Alias to a connection from the Gallery.

The primary benefit of this is that an organization will not need all of their developers to standardize their aliases and/or connections strings per connection. Instead, they will create one connection within the Gallery that will be distributed to developers and applied to the Remote column. This will generally reduce difficulties regarding the expansion of an Alteryx user base within an organization. Below I will outline two possible implementations of this:

1) Add a Remote Connection String field when adding a connection in the Data Connection Manager. This optional field will allow the user to set only one connection to an IO transaction, but maintain the Local-Remote functionality described above. Here is a mockup of how that might look within Alteryx Designer. 

2) Add a Remote Connection String field on each IO action within Alteryx. This will give the developers more flexibility in which connections are used where, but will also require more setup and maintenance time. Below is a mockup of how that might look.

[MattB]

Thanks @EEdLoh for the great idea. We will be revisiting the Data Connection Manager and be sure to keep this in mind. In general, we want to expand the use of Data Connection Manager, including credentials, while adding flexibility for user and admins.

[SeanAdams]

Hey @EEdLoh  - another piece to your proposal is that the data connection used when publishing to your dev server could be a different end-server connection than the one you would use once in prod.

The way some other platforms solve this is that a connection has multiple different versions (one for Dev; UAT; Prod) and as you migrate it across the environments the server changes which connection string to point to.

That seems to be very strongly aligned to what you're thinking of here and the problem you're attempting to solve?

[KylieF]

Updating this idea's status back to Under Review, to be in line with past product updates.