Showing results for 
Search instead for 
Did you mean: 

Alteryx Designer Ideas

Share your Designer product ideas - we're listening!

Option to rename all linked Field Names when an original Field name is renamed

 Hello everyone,


Currently in Alteryx if a user uses a SELECT tool to rename a field name, and then have various different tools connected in a flow to this SELECT tool, the same field name is carried throughout. 

However, what if your project kept adapting to different needs and hence the field name in the SELECT tool had to be renamed again for some reason, this would cause all the linked tools in the workflow to break, especially if the previous field name is used in these tools. 

It would be great to allow the user to tell Alteryx to change all linked field names in the various linked tools to the new name or keep the old one.


I understand that Alteryx at the moment does not have this feature by default, in the case where the user renames a Field name, Alteryx does not want to automatically update all linked Field Names, especially if the renamed Field Name has already been used somewhere else in the workflow. However Alteryx should provide a warning that the renamed Field Name is a duplicate !


Matlab has a similar case wherein if a user changes the name of one variable, with a simple keyboard shortcut he can rename all other variables just simply.






This is a capability (identify unique fields, and change them throughout the canvas if renamed) that has been discussed quite a lot in many different forums - and I think that there's a few ideas posted on this topic too.


In many ways - this would then mirror much of the functionality of many development tools - and by keeping explicit record of a unique field ID, it would also open the way to deeper optimizations of the workflow (which is an idea that @JoshKushner floated)


Adding @AdamR


Out of interest - this is also a necessary capability to do field-level lineage tracing from outside Alteryx in a meta-data tool or a catalog.   For example - the standard regulatory need to answer the question "where did this value come from - trace it back to source fields"




This could potentially be resolved with pointers to fields stored in XML "memory" so that each time the field is referenced it would point to the "memory" and include an alias if necessary (although this is it's own host of complications).


This would require the XML behind an Alteryx canvas to fundamentally change.


@NeilR, @Claje, @


I think that this feature could be developed without necessarily requiring significant changes to the XML that makes up an Alteryx workflow.

Conceptually, a feature like this needs to be able to look forward from a change in a Select tool, and check for the historical field name to perform updates to tools downstream as appropriate.

While what I am about to propose is not at all how I would like to see this implemented, i think you could build a proof of concept Alteryx App which performed field name edits downstream by utilizing the connection information stored in the XML today.  I'm thinking something like three chained applications:

Step 1 loads the selected Alteryx workflow, and gets a list of all Select tools in the workflow.

Step 2 lets the user pick which Select tool to apply updates from, and then loads the fields in that tool.
Step 3 lets the user pick which field to apply an update from, and what to change the name to.  Then it runs through the entire workflow selected in Step 1 and updates all field references in the XML and formulas.

Obviously, since the Alteryx engine is capable of identifying downstream impacts from a field name change, I think it should have the ability to do a lot of this more effectively than a brute-force solution like the above proposal.  It should be as simple as storing the old name in memory for the workflow validation, and upon finding a missing reference (or references) which matches to the name in memory, prompts to ask if you would like to update this reference.

If I understand the proposal correctly, think this is a great idea and
could update the back end XML in real time while working in a workbook. --

Josh Kushner

Hey all,


Check my thinking - but as far as I'm aware, the one gap that would need to be closed for the computational approach that @Claje and @JoshKushner are suggesting is that many tools don't store the full field list.

For example - the select tool only stores changes or subtractions from the field list.


So - agree with your thinking - and the first step is to parse the XML and persist all the fields in each tool.


I like the discussion in this thread, but agree with @SeanAdams that given the related variants to this idea that have already been discussed, AYX should consider solving it in a broader application level way outside of just enhancements to the Select tool.

I would hesitate to suggest redesigning the metadata of the yxmd workflow itself to persist field information tool by tool as I think it would significantly increase workflow sizes.  I can't attach workflows here, but I've included a few screenshots of a workflow size proof of concept.


Claje_Size_Flow.PNGGenerate 1000 rows, cross tab to create fields


I saved this flow twice, once with no changes in the Select tool, and once changing the data type from Double to Int32 for all 1000 fields.


As you can see in the below screenshot, the second flow (with 1000 field changes) is almost double the size of the first.  Persisting this much extra information on all calls seems like it would dramatically impact performance based on what I have seen in large or complex Alteryx flows today.




Since the Alteryx engine can already identify which tools break when upstream fields change, my theory is that the engine could be updated to support pushing these changes downstream dynamically without dramatically increasing stored metadata.  The reason I proposed a "workflow proof of concept" is because I'm assuming that the engine itself is performing similar checks of all metadata and connection info within the workflow, and so the same concept could be applied for all existing tools more easily.


Agree about the size @Claje - the trade-off is that by using this shortcut, it becomes impossible to do a full trace on all fields to look for lineage at a field level.


For example - the question "where did this output field come from" becomes very difficult if we're not fully capturing all the fields.

I'd take the trade of a doubling of an alteryx file size (given that they are so small - in the order of kilobytes), if it gave us this kind of trace and lineage on large data sets (often in the order of MB or GB)