The Sharepoint file tools are certainly a step in the right direction, but it would be great to enhance the files types that it is possible to write to sharepoint from Alteryx.
The format missing that I think is probably most in demand is pdf. If we're using the Alteryx reporting suite to create PDF reports, it would be awesome to have an easy way to output these to Sharepoint.
After used the new "Image Recognition Tool" a few days, I think you could improve it :
> by adding the dimensional constraints in front of each of the pre-trained models,
> by adding a true tool to divide the training data correctly (in order to have an equivalent number of images for each of the labels)
> at least, allow the tool to use black & white images (I wanted to test it on the MNIST, but the tool tells me that it necessarily needs RGB images) ?
Question : do you in the future allow the user to choose between CPU or GPU usage ?
In any case, thank you again for this new tool, it is certainly perfectible, but very simple to use, and I sincerely think that it will allow a greater number of people to understand the many use cases made possible thanks to image recognition.
Thank you again
Kévin VANCAPPEL (France ;-))
Thank you again.
Alteryx Designer is slow when using In-DB tools.
We use Alteryx 2019.1 on Hive/HortonWords with the Simba ODBC Driver configured with SSL enabled.
Here is a compare In-DB / in Memory :
We found that Alteryx open a new connection for each action :
- First link to joiner = 1 connection.
- Second ling to joiner = 1 connection.
- Click on the canevas = 1 connection.
Each connection take about 2,5 sec... It really slow down the Designer :
Please, keep alive the first connection instead of closing it and creating a new one for each action on the Designer.
In a similar vein to the forthcoming enhancement of being able to disable a specific output tool, my idea is to have the inverse where you can globally disable all outputs and then enable specific ones only. This should help reduce the number of clicks required/avoid workarounds using containers to obtain this functionality and allow users to be very specific in which outputs run and don't run as required.
The JOIN tool could use some love. Let's consider merging the JOIN and UNION functions into a single tool. Instead of strictly L, J, and R outputs, we could have an option to allow for all standard SQL joins:
Being able to JOIN on case-insensitive values is a big bonus (resisted urge to BOLD and change font size).
Being able to JOIN on date-range is often requested.
Being able to JOIN on numeric-range is often requested.
If we are combining tools, getting UNIQUE on L or R (or both) inputs would also save time. Most JOIN errors are because the incoming (R) data contains duplicates by KEY.
Hi UX interested parties,
Here are some ideas for you to consider:
1. These lines are BORING and UNINFORMATIVE. I'd like to understand (pic = 1,000 words) more when looking at a workflow.
If you look at lines A, B, C in the picture above. Nothing is communicated. Weight of line, color of line, type of line, beginning line marker/ending line marker, these are all potential ways that we could see a picture of the data without having to get into browse everywhere to see the information. If we hover over the data connection, even more information could appear (e.g. # of records, size of file) without having to toggle the configuration parameters.
2. Wouldn't it be nice to not have to RUN a workflow to know last SAVED metadata (run) of a workflow? I'd like to open a "saved" workflow and know what to expect when I run the workflow. Heck, how long does it take the beast to run is something that we've never seen unless we run it.
3. I'd like to set the metadata to display SORT keys, order. Sort1 Asc, Sort 2 Desc .... This sort information is very helpful for the engine and I'll likely post about that thought. As a preview, when a JOIN tool has sorted data and one of the anchors is at EOF, then why do we need to keep reading from the other anchor? There won't be another matched record (J) anchor. In my example above, we don't ask for the L/R outputs, so why worry about the rest of the join?
4. Have you ever seen a map (online) that didn't display watermark information? I think that the canvas experience should allow for a default logo (like mine above, but transparent) in the lower right corner of the canvas that is visible at all times. Having the workflow name at the top in a tab is nice, but having it display as a watermark is handy.
5. Once the workflow has RUN, all anchors are the same color. How about providing GREY/White or something else on EMPTY anchors instead of the same color? This might help newbies find issues in JOIN configuration too.
6. If the tool has ERRORs you put a RED exclamation mark. I despise warnings, but how about a puke colored question mark? With conversion errors, the lines could be marked to let you know the relative quantity of conversion errors (system messages have a limit)
Just a few top of mind things to consider ....
Can we have a User Setting that allows the users to select if Alteryx should prevent the computer to go into Sleep or Hibernate mode when running a workflow?
It is my understanding that hidden in each yxdb is metadata. The following use case is common:
As an Alteryx Developer/Designer I want to know the source of a yxdb.
Ideally, I would know as much about the workflow (name, path, workflow version, AYX version, userid) as possible.
It would be awesome to be construct a workflow that would allow me to search the metadata of yxdb's on my client computers quickly.
A very useful and common function
Return the first non-null value in a list:
I'm really missing a search in the medata phane?
If I am on data phane:
If im browsing though metadata:
We've got your metadata. Suppose the "SELECT COLUMNT TO SPLIT" question is considered by Alteryx and this happens:
If a user updates the Field/Delimiter, the metadata could suggest the right Number of columns based upon the delimiter.
This all belongs in the automagically idea bank. It saves me the time of counting delimiters or trial and error counts.
We see canvasses every day where dozens fields are brought into a canvas or a macro, but never used - and this just creates slowness for no good benefit.
Given that one of the selling features of Alteryx is the speed of processing - could we look at three improvements to the Alteryx engine & designer:
Under the Runtime setting, there is an existing option to "Disable All Tools that Write Output". This is incredibly useful when developing workflows when you don't want to overwrite existing files.
But this option doesn't disable all outputs, like Publishing to Tableau!
I suggest adding the option to disable ALL kinds of outputs, uploads, and publishing (except possibly logging and caching).
When configuring a FILTER tool, the results of your formula are uncertain until you RUN/PLAY the workflow. Compare that experience with the configuration of a FORMULA tool where you see a "Data Preview" of the first record results.
TRUE or FALSE could readily be added to the Filter Tool and save the execution time for the workflow.
When you get to HTML tool versions, you could check many rows of data and potentially give back counts of TRUE and FALSE results as well.
I'll put this on my x-mas list and see if Santa has me on the naughty or nice list.
CI / CD is critical to any production level process, especially when multiple authors are contributing new features to the same workflow. Currently, multi-author editing of workflows is extremely difficult, and something that would be aided greatly by using git to control different branches of ongoing work. Luckily, that's something we can already do today! However, the ability to test before merging a pull request is critical to modern CI / CD pipelines. For this, it we need to be able to run a headless workflow from a CI / CD environment. Also, having the ability to pass in parameters to the workflow would allow for robust integration testing - something that isn't straightforward today without running on production environments.
When opening an Alteryx workflow that has been saved in a newer version, a warning message is shown, but you are still able to open the workflow, provided that it doesn't contain tools that don't exist in your current Alteryx version.
This does not work for packaged workflows that contain macros, for instance. You have to manually edit the xml of the extracted package file.
It would be great if we could have the same ability with packaged workflows that exists for normal workflows, i.e. the ability to extract and execute them with a warning.
In order to run a canvas using either AMP or E1 - the user has to perform at least 5 operations which are not obvious to the user.
a) click on whitespace for the canvas to get to the workflow configuration. If this configuration pane is not docked - then you have to first enable this
b) set focus in this window
c) change to the runtime tab
d) scroll down past all the confusing and technical things that most end users are nervous to touch like "Memory limits" and temporary file location and code page settings - to click on the last option for the AMP engine.
e) and then hit the run button
A better way!
Could we instead simplify this and just put a drop-down on the run button so that you can run with the old engine, or run with the new engine? Or even better, have 2 run buttons - run with old engine, and run with super-fast cool new engine?
In cases where there are dynamic tools - you often get a situation where there are zero rows returned - which means that the output of something like a transpose or a JSON parse or a regex may not have the field names expected.
However - any downstream filter tools (or other similar tools) fail even though there are no rows (see screenshot below).
The only way to get around this is to insert fake rows using a union or use the CReW macro for Ensure Fields. However, this is all waste since there are no rows so there's no point in even evaluating the predicate in the filter tool. Rather than making users work around this - can we please change the engine so that a tool can avoid evaluation if there are zero rows - this will significantly reduce the amount of these kind of workaround that need to be used with any dynamic tools (including any API calls).
As of today, Alteryx can use the proxy settings set in Windows Network and Internet Settings "Server pulls the proxy settings displayed in Engine > Proxy from the Windows internet settings for the user logged into the machine. If there are no proxy settings for the user logged into the machine, Engine > Proxy isn't available within the System Settings menu.". Then, you can override the credentials (but not the adress) in system settings but also in user settings.
The issue : in many organizations, there are several proxies that you can use for different use case. And by default, it can happen access to API are blocked by these proxies. The user, which is not admin cannot change his Windows Settings... and even if it's done by IT, it will impact all the system, including other software and leading to safety failures.
What I suggest :
-ability to change credentials AND adress
-a multi-level settings for both credentials and adress:
default : Windows Settings
Download tool/ Settings
In workflow Constants, it would be really useful to be able to populate a new field associated with each user created constant.
E.g. Type, Name, Value, "Description"
The description could be left blank but also populated by workflow designers to attach commentary / business logic to the constant.
E.g. Type = User, Name = MyUserConstant, Value = 0.25, Description = "This describes the weighting factor used in Product Calculations"
If you try to use Alteryx to solve simple recursive problems like the Towers of Hanoi; or solving Sudoku - you get this error
Please could we enable Alteryx to allow recursive macros - this would not only be helpful for problems such as Towers of Hanoi - it's also particularly useful for solving problems like walking an HR tree to get to the leaf nodes
With an increasing number of different projects, involving different machine learning models, it's becoming difficult to manage different package versions across workflows. Currently, the Python tool has a single virtual environment, so we need to develop models in different projects always using the same Python and package versions as the Python tool venv. While this doesn't bother the code itself too much, it becomes a problem as soon as we store and load pickled models, which are sensitive to even minor changes in packages.
This is even more so a problem when we are working on the Alteryx server, where different teams might use different packages. Currently, there is only the server admin who can install packages on the server and there can only be one version per package.
So, a more robust venv management in the Python tool would be much appreciated!
Can we have an option to save a workflow in a prior version for backward compatibility? I think Tableau offers this functionality.
If I have 2019.4.8 and a colleague has 2019.1.x, I cannot share my workflows because my colleague will receive a notice that the workflow was built in a newer version. I want to be able to save my workflow in 2019.1.x and send to my colleague.
This is predicated on the workflow not containing any tools/features not present in the older version. In that case, give me a warning about the specific tools/features that are not backward compatible. Thank you.