When training people on the use of action tools, something that I always have to hit on is that when you are telling the tool which piece of the XML that you are adjusting, it's sort of difficult to tell what you have selected, and super easy to accidentally select something else.
When you initially select the action to take it's this nice Blue Color. However, it still doesn't feel exactly like you have actually selected anything or told the Action Tool what to do, since it's so easy to just select any other one of these actions.
A slightly different problem is that if you are selecting an action that has been previously configured, it is just this light grey color. So it can be easy to accidentally change your settings because you may not realize it's actually set up.
Here is a recent community post that sort of outlines a few of these problems.
I would love to be able to have an interface tool that allows a user to search through drop down values (when there are more than 100 or so) similar to autocomplete. It would be helpful as a multiselect or single select drop down. I have inserted a very poorly mocked up picture below. It would essentially be a modified version of the drop down as all the values would be in the tool, but the user could type to find what they are looking for.
My idea comes when I've built an application, where user select filter from drop-down list. However it contains thousands of records, so it takes lot's of time to find desired record.
In Excel and MS Access when you use filter you can put many letter and filter shows rows that match the input. In Alteryx user can only put first letter, which is huge drawback to my users.
This is how it works in Excel:
Hope you like it!
Can you add the search functionality in the dropdown (Apps) where the user enters specific text and the dropdown list gets filtered accordingly?
It would enhance the user's experience while using large lists in dropdown.
The method of saving the results of one app to be read in by a follow on app seems very clunky to me. Can we develop a method to use the results within a workflow to feed drop down lists in later stages in the same workflow? That way an app can stand on it's own without having to save files out and chain further apps to read them again.
It seems this only works for selecting fields to include in the output but not for list of values to feed to a drop down list.
One thing I have noticed is that for some of the end-users of the apps I have in the gallery is that running the app from server is enough of a barrier that they don't use it at all. I have had to send links repeatedly to gallery, to apps on server for them to run them.
What I would love is a way to create a custom desktop icon (bear with me - I don't have the lexicon.) that an end-user would open and it would launch the app in the server directly (I'm assuming this would be opening a browser of choice, opening the app/workflow to the screen where it gives you the option to 'Run/Download/Schedule' rather than accessing it through a shared collection in the Gallery through a browser.
Possible extensions of this are the ability to create an app for a mobile device where they can access an app/workflow on server directly to run it from a phone/ipad.
I know this has been posted before, but the posts are fairly old, and I have just confirmed with Support that it is still an issue. Seems to be a pretty basic request, so I'm putting it out there again under this new heading.
The issue is that if you have data in a field, and you have that data separated by a new line (\n), it will show up fine in a browse tool, or pretty much any other output (database file, Office Document file, etc.). But if you try to use the Table Tool under Reporting, it ignores the line break and strings the data together.
The field data looks like this in a browse or most other outputs:
Hello, my name is
and I love
But when I try to pull this field into a Table Tool, it shows up like this:
Hello, my name is Michael Barone and I love Alteyrx
Putting this out here again in hopes that it gets lots and lots of stars so it gets put on the road map!!
Pardon the length of this post, but I have been working with Alteryx since version 2.0 (11 years) and have been accumulating a wish list ever since. Some of these suggestions have been made in the past but have yet to be embraced. This is the first post for the first 'idea' but, as I said, this is a wish list that has grown since I was first introduced to Alteryx. More posts will follow.
I will break this into sections to hopefully make the suggestions easier to categorize and digest.
Application interface - Since I was introduce to Alteryx, the application interface (what is presented to users) has remained rather stagnant and, with the rumored push to adopt HTML as a replacement for pcxml, could benefit from the following additional settings. I suggest these based on the fact that dot Net classes for interface controls are readily available in Windows which allow for manipulation of each of the controls attributes.
1. The ability to set 'style' attributes for each of the interface tools in the application interface (font-family, font-style, font-size, font-weight, color, etc. This could be presented to the developer as an additional (perhaps optional button) in the Configuration panel for each interface tool as below:
These settings would be specific to the type of interface tool and to how the individual tool would layout and/or be styled relative to the application interface window. One layout option, applicable to most interface tools, would be where the label would be relative to the object itself (top, bottom, left, right). The CSS could be stored in and interpreted from the XML of the yxwz file referencing the ToolID of the Node in a section of the XML hierarchy called <CSS> or something standard. An option to alter the default CSS could be displayed with a radio button control so that if not selected, the tool would fallback to the default system CSS of the tool. This default could also be set in System settings so that a consistent interface could be defined across the enterprise.
2. Moving to the actual window that displays when the application is opened, a lot of the same concepts could be applied to the Interface Designer pane.
Attributes that could be set could include position on screen when opened, width and height of the window, and all the attributes of a dot Net form. The same radio button strategy used for individual interface tools could be employed to use or not use system defaults.
3. In the UI, it would be nice if there was additional flexibility in how the interface tools could be laid out. Along with the relative position of labels for each control, being able to layout controls horizontally as well as vertically would allow for a more organized interface.
The Radio buttons would work as normal with the Text Box controls inside each Radio button and only displaying when the button is selected.
I realize a lot of the current development in Alteryx is focused on the new Alteryx Connect and being able to attach to more data files and services. But, if there is still also a concerted effort to move from what could be considered a legacy proprietary mark up language, pcxml, to a more robust and universally accepted mark up, html and css, then, in my humble opinion, expanding the options for developers to design more user friendly and customizable applications to a standard 'style' across the enterprise, both on the desktop and in the gallery, is a worthy endeavor.
Thanks for your attention. More to follow.
Hi Alteryx Devs -
It would be *really tight* to have a drop down interface tool that would support auto completion based on a odbc connection to a table/column or ajax call. I recently had a situation wherein we need to give the users the ability to select an address, then run a workflow. But the truth is, our address data is terrible, and what I really needed was to be able to let the users start typing the address, then give them a list of choices to pick from, they pick the correct (but usually wrongly formatted) address, and then I send that value into the workflow.
I could not find a decent way to give a gallery user a reliable way to pick an address from our list, so eventually wound up having to write an ajax piece to handle the auto completion, capture the user input, then post to a service that would in turn, interact with gallery through the API, get the response, and send it back calling page, and back to the user. A significant amount of work to put into something that is an exceedingly common web operation of auto completion.
This would make a lot of gallery operations flow so much more naturally.
Thanks for listening!
Now that Alteryx releases updates to Designer every quarter I'll likely be updating my copy of Designer frequently. Meanwhile, my IT team doesn't want to have to update Server every quarter to stay compatible. Problem there is, when I create workflows in the latest version of Designer they can't run on the older version of Server, nor on the Gallery.
Some features that would allow me to work around this:
I'm guessing this is a niche problem that few others will encounter:
When we industrialize our workflows, we often use a parameter file with a command like :
AlteryxEngineCmd.exe MyAnalyticApp.yxwz AppValues.xml
I would like to have the parameter file path with its extension as an engine constant, like we have the workflow name.
Disabled Containers throw errors if it contains any interface tools. It should not throw any error as the user is intentionally disabling the container.
I frequently make analytic apps for my clients that requires them to enter information or parameters to the workflow via a prompt before running. The user could be entering codes that will affect a certain filter or it could be a prompt to browse to the new source file required to run the workflow. In order to make adjustments to the workflow itself, I need to work in Debug mode so that I can see the data as it passes through each node in the workflow. Once I am done making all of the changes in debug mode and I am satisfied with how it works, I then have to remember each change I made, and copy and paste each tool and its contents over to the workflow that I am debugging. This is a pain because it is like I am fixing the workflow twice. A good solution to this would be allowing the user to apply changes made in debug to the workflow you are debugging, so that there is no duplication of efforts!
This should be a simple addition:
In the same way that many default tools automatically generate annotations when they are dropped into the workflow, or their configurations are modified, there should be a way to add custom annotations for custom made macros.
Never noticed this, because I always use the custom filter option, not the basic. But I had a user come to me asking why his app wasn't updating his filter properly.
He configured the filter tool thusly (dummy data):
And here is the what the action tool looks like when you connect it to the filter tool:
So he simply highlighted the "Bob" line and picked to update "Bob".
However, since he used a basic filter, and not a custom one, this is how he should've configured the action tool:
I realize that "well, it's spelled out for you - there's an expression section & a simple section in the action tool". But for beginners or even non-beginners, it might not be obvious.
It would be nice if when you connect the action too, it only displayed the appropriate option (either custom or simple, but not both).
I'm adding a 'Dynamic Input' tool to a macro that will dynmaically build the connection string based on User inputs. We intend to distribute this macro as a 'Connector' to our main database system.
However, this tool attempts to connect to the database after 'fake' credentials are supplied in the tool, returning error messages that can't be turned off.
In situations like this, I think you'd want the tool to refrain from attempting connections. Can we add a option to turn off the checking of credentials? I assume that others who are building the connection strings at runtime would also appreciate this as well.
As a corollary, for runtime connection strings, having to define a 'fake' connection in the Dynamic Input tool seems redundant, given we have already set the 'Change Entire File Path' option. There are some settings in the data connection window that are nice to be able to set at design time (e.g. caching, uncommitted read, etc.), but the main point of that window to provide the connection string is redundant given that we intend to replace it with the correct string at runtime. Could we make the data connection string optional?
To combine the above points, perhaps if the connection string is left blank, the tool does not attempt to connect to the connection string at runtime.
My users love having the ability to pick objects from a reference file in the Map tool in the Interface palette. However, usually they need to pick objects that are interspersed amongst others. The Control + Left Click works great, until they pick an incorrect object. The only option is to clear the selection and start over.
Please add something as simple as Control + Left Click on a selected object will deselect it.
It would be great if Alteryx created a program along the lines of Tableau Reader. If an organization is not at the point where they want to deploy Alteryx Server, but some people need to run Alteryx Apps, making a low cost desktop application that would allow users to open and run .yxwz files would be great. There are many non technical users who don't need and would not use the full version of Alteryx, but creating a desktop application allowing them to run .yzwz files would be helpful to them and would drive Alteryx adoption.