We have extended our Early Bird Tickets for Inspire 2023! Discounted pricing goes until February 24th. Save your spot!

Alteryx Designer Discussions

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

Choosing which Input Fields to use in a Standard Macro

7 - Meteor

I'm building a macro to grab some data from a database, but we regularly use 2 types of IDs (corresponding to different databases) so I want the macro to be able to accept either of them, and for the ID that's not native to the database in question I'll do an extra step to map it back to the native ID first


Since the IDs generally don't come together in the same datasets, I want to be able to choose which input is used for the macro as part of its interface settings -- in particular, I don't want to have an input that requires both ID fields to be input for the macro to work since I don't want to have to rely on using dummy values for the missing ID each time I use this macro


So far, I've been able to get this kind of functionality to work by using 2 Macro Input tools and nesting their field map under separate Radio Buttons so that the macro interface can be toggled between the 2 depending on which ID the user wants to use. I like this interface because it's very obvious that only 1 ID will be used, and there's no need to map to the field that's not intending to be used




My only issue with this is that the macro tool itself then has 2 input nodes as a result of the 2 Macro Input tools, and that's absolutely not what I want -- but I can't figure out how to split out the field map, otherwise




Is there a way to get the macro to have a single input, but still have the choice between which items from the field map are chosen? I'll also note that the field map is necessary -- the exact column names given to these IDs changes across different people

7 - Meteor

The solution I've found so far is to use a Drop Down Interface tool combined with the Radio Buttons to indicate which ID is being used -- this is good enough: