We have discussed on several occasions and in different forums, about the importance of having or providing Alteryx with order of execution control, conditional executions, design patterns and even orchestration.
I presented this idea some time ago, but someone asked me if it was posted, and since it was not, I’m putting it here so you can give some feedback on it.
The basic concept behind this idea is to allow us (users) to have:
This approach involves some functionalities that are already within the product (like exploiting Filtering logic, loading & saving, caching, blocking among others), exposed within a Tool Container with enhanced attributes, like this example:
The approach is to extend Tool Container’s attributes.
This proposition uses actual functionalities we already have in Designer.
So, basically, the Tool Container gets ‘superpowers’, with the addition of some capabilities like: Accepting input data, saving the contents within the container (to create a design pattern, or very commonly used sequence of tools chained together), output data, run the contents of the tools included in the container, etc.), plus a configuration screen like:
This should end a brief introduction to the idea, but taking it a little further, it will allow even to have something like an Orchestration layout, where the users can drag and drop containers or patterns and orchestrate them in a solution, like we can do with the Visual Layout Tool or the Interactive Chart tool:
I'm looking forward to hear what you think.
This has probably been mentioned before, but in case it hasn't....
Right now, if the dynamic input tool skips a file (which it often does!) it just appears as a warning and continues processing. Whilst this is still useful to continue processing, could it be built as an option in the tool to select a 'error if files are skipped'?
Right now it is either easy to miss this is happening, or in production / on server you may want this process to be stopped.
I surprisingly couldn't find this anywhere else as I know it's been discussed in person on many occasions.
Basically the Formula tool needs to be smarter in many ways, but this particular post focuses on the Data Type component.
The formula tool, should not always default to V_String as the data type when entering data or a formula into the formula tool, it should look at the data type and estimate the most likely option.
I know there are times where the logical type might not be consistent in all fields, but the Data Preview and the Function of the formula should be used to determine the most likely option.
E.G. If I type a number or a date directly into the formula tool, then Alteryx should be smart enough to change the data type from the standard V_String to Int, Double or date.
This is an extension to the ideas posted here:
I often need to create a record ID that automatically increments but grouped by a specific field. I currently do it using the Multi-Row Formula tool doing [Field-1:ID]+1 because there is no group by option in the Record ID tool.
Also, sometimes I need to start at 0 but the Multi-Row Formula tool doesn't allow this so I have to use a Formula tool right after to subtract 1.
So adding a group by option to the Record ID tool would allow the user not to use the multi-row formula to do this and to start at any value wanted.
Love the new updates to the Browse tool in 2019.2! However, if you choose the option Open results in new window, which I do often so I can see my whole dataset, the search/filter/sort functionality goes away. Would be great if that new functionality also worked in the new window. Thanks!
Can't wait for the new base maps!
In-app screens, lot of space is wasted because components/tools can just be stacked one below the other.
It would great if we could also insert them horizontally.
Tags : screen, app, macro, layout, tools, UI
I like to suggest having a Batch Macro Container (besides the existing Container) which acts as a Batch Macro within a Workflow and is stored within the Workflow.
I understand that having a batch macro available as a separate tool can be very powerful and reduces redundant work. However, very often Batch Macros are set up for a specific workflow only and are of no use for other workflows. The Creation of a Batch Macro in a container will significantly reduce the time to deploy a batch macro and keeps the Macro folder clean of one-time Batch Macros.
Attached a picture of how this could look like
This has probably been mentioned before, but in case it hasn't....
The dynamic input tool is useful for bringing in multiple files / tabs, but quickly stops being fit for purpose if schemas / fields differ even slightly. The common solution is to then use a dynamic input tool inside a batch macro and set this macro to 'Auto Configure by Name', so that it waits for all files to be run and then can output knowing what it has received.
It's a pain to create these batch macros for relatively straightforward and regular processes - would it be possible to have this 'Auto Configure by Name' as an option directly in the dynamic input tool, relieving the need for a batch macro?
Is it possible to add an option to 'Add an Image' in the settings option of Interface Designer while building Apps or macros?
Currently, we can add Group box, Link, Tab, and Label. It would be really helpful if we can add static images as well!!
This would enable a developer to add an explanatory image just as a link or label is used to communicate to end user.
I am attaching a screenshot for the reference.
Thanks in advance!!
I rarely use the Group By tab on batch macros, but it's unfortunately always the first tab that pops up. When I have a questions tab on a batch macro, it would be great if it appeared first (ie I should see the questions tab when I click on my batch macro.) Thanks!
A common problem with the R tool is that it outputs "False Errors" like the following: "The R.exe exit code (4294967295) indicted an error"
I call this a false error because data passes out of the R script the same as if there were no error. As such, this error can generally be ignored. In my use case, however, my R tool is embedded within an iterative macro, and the error causes the iterator to stop running.
I was able to create a workaround by moving the R tool to a separate workflow and calling it from the CReW runner macro within my iterator, effectively suppressing the error message, but this solution is a bit clumsy, requires unnecessary read/writes, and uses nonstandard macros.
I propose the solution suggested by @mbarone (https://community.alteryx.com/t5/Alteryx-Designer-Discussions/Boosted-Model-Error/td-p/5509) to only generate an error when the R return code is 1, indicating a true error, and to either ignore these false errors or pass them as warnings. This will allow R scripts and R-based tools to be embedded within iterative macros without breaking.
Idea: Prompt the user to find a missing macro instead of the current UX of a question mark icon.
Issue: When a macro referenced in a workflow is missing, then there is no way to a) know what the name of the macro was (assuming you were lazy like me and didn't document with a comment) and b) find the macro so you can get back to business.
When this happens to me know, I have to go to the XML view and search for macros and then cycle through them until I find the one that's missing. Then I have to either copy the macro back into that location or manually edit the workflow XML. Not cool man.
Solution: When a macro is missing, the image below at the right should be shown. In the properties window, a file browse tool should allow the user to find the macro.
We all love seeing this. And, it's fairly easy to fix, just go find the macro and insert a new copy. But, then you have to remember the configuration and hope that it was simple.
With the tool that's there, the XML still contains the configuration, all that's missing is the tool path. It would be great to be able to right click and repair the path from the context of the missing macro.
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!
The join tool currently does not allow case-insensitive joins, but the find/replace tool does. Additionally- even if both sides are identical, the join tool will not join "Sean's house" to "Sean's house" because of the non-letter character in the middle. Finally - if one side is a string(2), and the other is a vString(200) - even if you have a single identical character on both sides you get uncertain outcomes unless you force the type
Please could you consider amending the join tool to include 3 new options or capabilities:
- Case insensitive join
- Allow full Unicode character set in join
- Full match across text types (irrespective of string size) - this would allow a string(2) value to match to a string(100) value as long as the string(100) value only has the same 2 characters in it as the string(2) value
That would remove a load of work from every text-join that's being done on every canvas we do.
Hello gurus -
I think it would be an important safety valve if at application start up time, duplicate macros found in the 'classpath' (i.e., https://help.alteryx.com/current/server/install-custom-tools, ) generate a warning to the user. I know that if you have the same macro in the same folder you can get a warning at load time, but it doesn't seem to propagate out to different tiers on the macro loading path. As such, the developer can find themselves with difficult to diagnose behavior wherein the tool seems to be confused as to which macro metadata to use. I also imagine someone could also arrive at a situation where a developer was not using the version of the macro they were expecting unless they goto the workflow tab for every custom macro on their canvas.
Thank you for attending my TED talk on the upsides of providing warnings at startup of duplicate macros in different folder locations.
I've recently been delving into using the interface tools and there are a couple of glaring issues for me as a developer/designer, all having to do with the UI, ironically (yes, I used that correctly!) with the interface tools. The irony here is that the interface tools utilise a poor user interface.
Firstly, I finished this video to ensure I was indeed doing things correctly, and I was.
The UI for designer's interface tools is incredibly sluggish. In order to rearrange tools, each time you create a new one, you have to push the up arrow for each tool and you have to traverse the groupings.
Instead of this, I suggest two changes to the interface designer.
I know not everyone is building macros/apps and dealing with this, so I have little faith that this will jump to the top of your queue. But this is a painful part of the UI. I don't know if your UX designers could easily fix this or if it is more pain on your end than the pain you're giving me, but I just want to say: This hurts. 35 clicks every time I add a new element with no option to 'move to top' like you (wonderfully) do in the select tool is a big drag on my time (hint: maybe add that sort of functionality too; the select tool manages this stuff so well!). Which is supposedly valuable. In theory. But it certainly doesn't feel that way when I've spent 10 minutes clicking an up arrow (and yes, my UI is slow. And I may be exaggerating, but not by much!).
Thank you for your continued improvement!
The current version of the Publish to Tableau macro retrieves an API key at the start of the workflow run. Often times the workflow may take several hours to run before it's ready to write to Tableau by which time the API may have expired. (I think the default tableau server setting times out in 2 hrs) It's one of those soul crushing "I should've forked the output!"
Sample Log Error -
The idea would be to change when the macro obtains the API from when the workflow is initiated to just before the workflow is ready to write to the Tableau avoiding these timeouts.
(If you're having this issue in the meantime you can have your Tableau server admin up the timeout)
See the discussion on this page:
It would be helpful to be able to embed a macro within my workflows so in the end I have one single file.
Similar to how Excel becomes a macro enabled file, it would be great if the actual macro could be contained in the workflow. As it stands now, the macro that I insert into a workflow is similar to a linked cell in MS Excel that points to another file. If the macro is moved the workflow becomes broken. I often work on a larger workflow that I save locally while developing. Once it's complete, I then save the workflow to a network drive and have to delete the macros and reinsert these. It also makes it challenging if I were to send a workflow to someone else... I will have to give them instructions on which macros to insert and where. Similar to a container, they could be minimized so to speak to their normal icon, and then expanded/opened if any edits were needed....then collapsed when done.
Thanks for the consideration.
when writing an iterative macro - it is a little bit difficult to debug because when you run this in designer mode, it only does one iteration and stops.
Could we add the capability to the designer itself to be able to run the second and third iteration using the test data built into the macro input tool? Even something as simple as an option to run X iterations; or when it's run the first iteration allow me to look at what happened and trigger iteration 2 (or to trigger a run-through to completion) would be immensely helpful.
While you can do this with a test-flow wrapped around a macro, macro development is a bit of a black box because Alteryx doesn't natively have the ability to step into a macro during run-time and pause it to see what's happening on iteration 1 or 2 or n and why it's not terminating etc. So putting the ability to run in a debug mode would be HUGELY helpful.
I decided to get real fancy when building a standard macro the other day. I checked the box on my macro input that made the connection optional:
It worked really well. My macro then became more complex, so I changed it to a batch macro. To my great surpise/astonishment/shock, the optional incoming connection is no longer optional:
The standard macro is working as expected on the left, but the batch macro is producing an error because my optional connection is requiring that something be connected to it.
I've been told that the code to make it optional is not there for batch macros and that this would be a product feature/improvement.
In the newer versions of Alteryx - if you open up a canvas that was created in a newer version, alteryx offers to auto-fix this by opening the canvas anyway.
However if that canvas includes custom macros - these macros are not imported if they are a newer version.
Please could you extend the Newer Version process to include macros used on a canvas, and attempt to import these too?
The performance profiling option on the "runtime" tab is very helpful to identify bottlenecks on a long-running workflow. However this is missing (along with the entire "Runtime" tab) if I change this to a macro.
Given that the only way to build relatively complex dependant chain jobs is to wrap them in dummy batch macros (using a macro like a sub-procedure with flow-of-control on the master-canvas) - most of our work is done in Macros - so it would be helpful to be able to performance profile them during testing.
When building an Alteryx Macro - one of the tough parts is that the input data you put into the Macro Input is used for testing, but you cannot set the type.
So for example - I want to test with the value 1, and Alteryx automatically assumes this is a Byte.
However 1 is just a useful test value, but I need this to be an int 64.
Can we provide the option to strongly type the macro inputs - this way, we can give advanced users the ability to control the type on Macro Inputs, and not run into this sort of issue with test data implicitly defining the type?
Note: this is similar to the idea here:
Despite being an Alteryx user for 2 and a 1/2 years this is something I have only recently came across but it does not appear that you are able to use debug mode appropriately with macros.
What I mean is, I have a macro input which drives a series of drop down boxes. In debug mode my drop down boxes will not populate. Now I understand why, Alteryx doesn't know what the input is so it doesn't generate the meta data for the debug mode drop downs.
What I suggest Alteryx do is automatically convert your macro inputs for file browses for the purpose of debug mode (I had to do this myself manually and it was a tedious task, not only to set up but then maintain two separate versions, one essentially an application and one a macro).
Or, by default debug mode uses the macro input data to run through debug mode as.