Showing results for 
Search instead for 
Did you mean: 

Alteryx designer Discussions

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

Macro unable to translate alias




I have a workflow that contains a macro and this macro uses alias to connect to db (SQL Server). Works fine on desktop and when I try publishing it to gallery, it gives an error saying "Unable to translate alias". The alias are set up correctly in gallery and shared as well, there are no issue in publishing a regular workflow that use alias. 


Are there any additional steps to be taken to make a Macro work with alias?

Can a macro recognize alias at all?  


Thank you,



Hi @mtakka1,

What is likely happening here is the server that hosts your gallery doesn't have an alias setup the same way as your local desktop instance.  The server needs an alias with the same alias name and credentials need to be able to access the tables or files you access through your DSN.  More information about this is available at


Hi @WayneW,


Thank you for the response. The alias is set up correctly and are synced between Desktop and Gallery, I have workflows published in gallery using those alias and they work fine. 

When I try to use a macro referencing the alias within a workflow then I get "Unable to translate Alias" error. 

@mtakka1 I just wanted to chime in and say I had the same issue and got this response from Matthew Braun at Alteryx:


Thanks for following up! I had one of our developers take a look and this appears to be a bug whether you package the macro or not. Per the dev…


When I try it, if the macro containing the data connection is not in the same directory as the parent module, it fails to package the data connection properly (because it tries to adjust the path as if the data connection was a file).  If I have the macro in the same directory as the parent, it works, but in that case I can’t put it in the common macro directory, which is the only way I know to get it to work on the gallery if you don’t package the macro.


He also added that since the data connection is essentially an ID, there is no size on disk savings by not packaging it. So, for a new version, there is no real disk penalty and you would just package up a new version.


I have created a bug in our system. Given our current priorities and that this is the first time we have heard about this issue, it is unlikely to get into a near release. However, if you don’t mind, please post this in the Community for awareness. Ideally, if other customers find your post and comment, we can try and bump up the priority.


Thank you @patrick_digan for sharing this useful information :)


Can someone please elaborate on this because I'm confused as to what the solution is?  I think I have a similar issue when using the Crew Runner macro.  The macros are installed on the server and run without issue, however the workflow(s) that are executed by the Crew Runner macro fail with "Unable to translate alias [DATASOURCE]."  


The workflows that fail to run work perfectly fine from the server if they are executed from the server instead of inside the CrewRunner macro.  Any ideas?

@rhervey It's currently a bug where the new gallery aliases cannot be used inside macros (including running it from the crew macros). The current solution is to use the old method of having a system alias defined on the server and making sure that the workflow isn't built using the gallery alias but instead a user or system alias. It should get fixed eventually.


@patrick_dignan, So workflows saved directly to the gallery will leverage the alias defined on the Web portal whereas workflows exectuted from within a macro need to leverage the connection defined within Desktop on the server.  Is that correct?

@rhervey Yes that is unfortunately the case. We had all of our aliases on the server as system aliases and I was excited to convert them over when the new aliases came out; instead, I currently maintain 2 sets of aliases, system and the new gallery. I use the new gallery aliases as much as possible. Whenever I need an alias in a macro or runner, I then "convert" it back to the old method so that it will work on the server with the system alias at that point. 

Alteryx Alumni (Retired)

@patrick_digan - I recently did some troubleshooting on a similar issue I believe to be related to yours.  Referencing the macro using UNC pathing seems to allow the packager to get around the defect even if the macro is in another folder.  I'd recommend giving that a try.