This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
Some users have reported a problem when importing and exporting macros within the Alteryx Designer when the Regional Settings for the machine are not set to English (United Kingdom) or English (United States) (see screenshots below). You may also be unable to see personalized Macro folders within the Designer. They encounter the following error: "Input string was not in a correct format.”
The workaround for this is to switch the Regional Settings to the regions named above and you will then be able to import, export macros and see personalized macro folders within the designer categories.
The screenshots below demonstrate what the users will see when they try to import and export workflows with other Regional Settings than English (United Kingdom) or English (United States).
To find Region and Language settings in Windows 7, please navigate to the Control Panel>>>Clock, Language and Region>>Region and Language. For more information on Localization please see this link: http://community.alteryx.com/t5/Analytics-Blog/Alteryx-Commences-Localization-Endeavors/ba-p/11765.
The key component of any batch macro , the Control Parameter Tool is the gear that keeps things moving. Using the input , the control parameter accepts a field of values that will be used within the batch macro to reconfigure and rerun the macro for each of the standard input records - unless using the GroupBy feature that matches certain control parameters to buckets of records to be batched through the macro together. Adding this interface tool to any macro will upgrade it to a batch macro and will give you the ability to loop through macro configurations for added customizability. While one of the more sophisticated solutions you can build into your workflows, there are few problems you can’t solve with a batch macro:
A must-have for any app or macro, the Error Message Tool displays a prompt to the user based on input from Interface Tools . Using any expression that evaluates to true, along with any number of user inputs from question anchor connected Interface Tools, the Error Message Tool can layer even the most involved applications with failsafes that ease a user’s experience through more robust interactions.
Alteryx Analytic Applications (Apps) let us take a process, parameterize parts of it, and add an interface so that end users don't need to know all of the inner workings of the process in order to make it work for their specific scenario.
For any macro or analytic app – one of the inevitable questions that you may encounter is “how do I configure this to do what I need?” For example, if you build a macro that checks if two fields are equal, but sometimes you want to ignore the case such that “A” equals “a,” and sometimes you want an exact match. This is where the Interface Tool Category comes to the rescue, with a super-tool called Check Box!
In a workflow, not too far, far away...
Structured data has vanished. In its absence, the sinister Dirty Data Order has risen from the ashes of the Server and will not rest until Data Analytics have been destroyed.
With the support of the Alteryx Engineers, Solutions Engineer Tony Moses leads a brave RESISTANCE. He is desperate to find structured data and gain its help in restoring blending, joining and analytics to the galaxy.
Tony has sent his most daring Community Leader, Matt DeSimone, on a secret mission to Jakku, where an old ally has discovered a clue to the structured data whereabouts....
Welcome to the Star Wars universe!
Ever wanted to know the most important details of your favorite characters from Star Wars? Me too!
Our generous friends, Paul Hallett and team, have given us the Star Wars API - the world's first quantified and programmatically-accessible store of Star Wars data.
After hours of watching films and trawling through content online, Paul presents us all the People, Films, Species, Starships, Vehicles and Planets from Star Wars.
The data is formatted in JSON and has exposed it to us in a REST implementation that allows us to programmatically collect and measure the data.
Now, how was I able to retrieve this treasure of information via Alteryx? Easy! I've built a REST API connection using the Download Tool to pull information based on a user inputted query in an Alteryx Application (attached as v2018.1 Star Wars.yxwz).
Normally, once having retrieved JSON formatted data, structuring and parsing the data would be a nightmare! With Alteryx, this is just one tool away. The JSON Parse Tool allows you to identify the JSON field, in this case our download data field, and easily extract Name and Value columns. From there it's some simple formatting and using the reporting tools to present us a nice clean composers file (pcxml).
Man, if only the Rebels could process information as fast as Alteryx then they wouldn't have had to send poor R2 to find Obi Wan.
I'll be bringing you, the Alteryx Community, updates of the app with each new movie release!
I hope you enjoy the API and may the Force be with you!
The Drop Down Tool is part of the Interface Tool Category and can be used when creating Apps. This tool has many great configurations from loading data from within the workflow to using outside sources to update tools. Hopefully, after reading this article and looking at the samples you will feel more comfortable using this tool in your app user interface.
Question Have you ever wanted your own help page for your custom macros or applications?
Answer If you create your own macros or applications and send them to other who aren’t as familiar with your project, or if you just need a refresher from time to time, you may try and access the help menu only to be greeted by the general Alteryx macros/apps pages:
Macro Workflows Page
Analytics App Workflows Page
You can actually create your own help pages/files that can be accessed how you would normally access the Alteryx Help Menu for any "out of the box" tool that comes with the Designer.
Using your favorite text editor (Microsoft Word, for example), you can create your help file with any instructions or graphics that you feel would be helpful to the end users who may need to access a help file. Once you are done, you can save this in any file format that your (or your users') machine is able to open, as well as any location those users would be able to access (a network drive for example).
In your application or macro’s Interface Designer Properties, there is an option to add the path of a file or hyperlink to your newly created help file.
For an example I created the following help file as a .docx, .pdf, and .htm file type. Each other these files open in their respective default programs.
So we’ve generated our list of Key Values (in Part 1) to be read by the Tree Interface tool and when we look at the Tree Interface it looks correct.
So how can we use these selected values in a workflow?
As a review, our original data consists of very pretend pet data.
Now we need to associate the Key Values to our data so that our data can be queried. This can easily be done by adding a couple steps to the workflow we create in Part 1 (updated workflow is attached).
By adding a Transpose tool, the table can be manipulated to get each possible Key Value for each record. Then a Select Tool to rename the Value field to Key. Those results are saved to a new file (Pet data with key values.yxdb) that will be used in the app.
When values are selected in a Tree, a list of the Key Values are returned with a line break between each value. In the above Tree Interface example (Figure 1) the Key Values 111 and 26 are returned as a string data type and would look like this:
Setting up the App
We now have all the parts we need to create the app: Pet Key values.yxdb (from Part 1) and Pet Data with Key Values.yxdb
The start of the app is a Tree Interface tool that points to the Pet Key Values.yxdb file, and an Input tool pointing to the Pet Data with Key Values.yxdb file.
We know the Tree Interface returns a list of Key Values, so we can then filter our pet data on the Key Values. A Filter tool is added with a template filter that will ultimately be updated by an Action tool, once we connect the Tree Interface to the Filter tool.
Now let’s connect the Tree tool to the Filter tool and configure the Action tool.
We are going to select the Action Type ‘Update Value with Formula,’ and update the full Expression. Now for the Formula: click on the ellipsis (…) to add this formula:
'[Key] in ("' + REGEX_Replace([#1], '\n', '","') + '")'
This expression will build an IN statement (Figure 5) based on the selected values from the Tree Interface. If the returned values from the Tree tool are, as in Figure 4:
The expression will build a string starting with: [Key] in (“
The REGEX expression looks for all line breaks (or newlines) in the connection 1 ([#1]) value, denoted by the \n, and replaces those occurrences with: “,”
And then finishes the expression with: “)
The final expression looks like this: [Key] in (“111”,”26”)
This will replace our template expression when the app is run.
To test your Action tool expression, use the Interface Designer’s Debug tool. Open the Interface Designer from the View menu in Alteryx. This Community article goes into more detail on how to use the Debug tool.
With that, the tree tool is complete. The Key Values from the selected Tree Interface items are used to select the desired records from the dataset for further processing.
Add a Browse tool to the True output of your Filter to view the results when the app is run. Be sure to configure your app to show the results of the Browse when the app completes. This setting can be found in the Interface Designer, under Properties.
As with many things in Alteryx, there is usually more than one way to accomplish a task. In the attached App example workflow, there is an additional method to take the results from the Tree tool and query the pet dataset.
All related workflows are attached to the post and saved in Alteryx 10.0 format.
In a previous article we’ve shown how the list of selections in the List Box tool can be dynamically generated from:
the column names from an input file
the values in one of the columns of the input file
the values in one of the columns of a user-selected input file (target field must be in both original and new file)
In this second article, we’ll see how to let the user select both a file and a field within this file to create the values in the List Box. The file that the user selects doesn’t need to have the same columns as the one you used when building the App.
Show the selection options from one of the columns of a user-selected input file and field
In this example we will use the techniques we’ve explained in the first article including, reading field names from input, creating value list and using chained Analytic Apps to show the second screen with the list of values for selection. Again, make sure you save these workflows as Analytical Apps.
The first workflow uses what was done in the previous article but relies on the fact that Alteryx yxwz files are XML files containing the configurations of the tools of the workflow. To load the user-selected values into the second List Box, we will manually update the XML of the second workflow to change the List Box configuration. The List Box tool, when set to Manually set values, expects a Name:Value pair and therefore we are using the Multi-Field Formula tool to create these pairs and change the field size to make sure it fits the extended text. We then use the Summarize tool to concatenate all of the separate values into a single field with new-line (\n) as separator.
Now that we have our List Box Values ready it’s time to load them into the second workflow. For this to work, we should have already built the second workflow, ProcessWorkflow.yxwz and setup the List Box tool List Values to Manually set values with the value set to _xxxx_:xxxx.
Back to our first workflow, we start by reading in the second workflow we just created. To be able to read it into Alteryx, we set the Input Data tool to read the file as CSV with \0 as the delimiter (no delimiter) and with first row contains field names.
We then use the Summarize tool to concatenate the rows into a single row and make sure you name the field <?xml version="1.0"?> (this will be the first line in our output file).
We bring in the list of values we created in the first part of the workflow and append it to this data stream using the Append Fields tool and then use the formula tool to find the _xxxx_:xxxx text and replace with the correct values. We deselect all fields except the <?xml version="1.0"?> using the Select tool and write the output to a new file ProcessWorkflow2.yxwz using csv as format and \0 as delimiter.
The last step in this workflow is to set the new workflow we just wrote-out to start when the first one finishes execution. This is done by naming the second workflow in the Interface Designer (Alt-Ctrl-d) under Properties: "On Success – Run Another Analytic App". Also the "On Success - Show Results to User" should be deselected.
You can find the workflow used in the article attached to this post. It was built in Alteryx Designer 10.6 (10.6.6.17413).
Special thanks to @patrick_digan for testing and suggesting improvement to the example workflow.
This article is part of the CS Macro Development Series. The goal of this series is to communicate tips, tricks, and the thought process that goes into developing good, dynamic macros.
If you’ve ever built an analytical app and used the Interface Designer (View >> Interface Designer), you’ve probably spent some time in the Test View:
This menu provides a great runtime view of the interface as you’re adding and configuring tools and also allows you to interact with them, much like you would when selecting “Run As An Analytical App” in your Designer. You can clear (Reset), save (Save – as an .yxwv analytical app value file), reopen (Open – search for your .yxwv files) and investigate the xml capture of your test values (View – these will initialize to your specified defaults) in here, but the real value is in using the “Open Debug” button to open your app debug workflow:
This will create a new module with the workflow that would result from executing all the actions of your interface tools (individual values, tools, even xml, can be updated). You can also see these values, along with an actions log, in a comment box preceding the tools themselves. The workflow will even show you errors if your interface tools created any after updates! This comes in handy as you’re updating detours, opening/closing tool containers, and performing complex updates to your workflows via interface tools because it gives you a snapshot into what, exactly, is happening with each set of Test View values and, in effect, at runtime.
For example, in the screen capture of the Test View above, we have the default app (attached as v10.5 App Debugger.yxwz) values. When opening the debug workflow (attached as v10.5 Debug Workflow Default Values.yxmd), we can see the result of them in that our row value is still “Test” and our detour defaults to the right:
However, if you update the values in the Test View and reopen the debug workflow with the values below:
You’ll see in the new workflow (attached as v10.5 Debug Workflow New Values.yxmd), that our row value is now updated to “DebugTest” and our detour no longer goes to the right:
The above is a simple example of the power of the tool, but using it more often in your troubleshooting will help pinpoint where your errors or conflicts are arising, freeing more time for you to build out more apps!
This article is part of the CS Macro Development Series. The goal of this series is to communicate tips, tricks, and the thought process that goes into developing good, dynamic macros.
The Detour Tool and its counterpart, the Detour End Tool, are tools that come in handy in building out custom Analytical Apps and Macro workflows when you want to “turn on” or “turn off” entire sections of the workflows based on a user input. While handy, there is an alternative to the approach in using Tool Containers to encapsulate the sections that you’d like to turn on/off and using a Radio Button (or other Interface Tools) and action to “Enable/Disable Container from Condition.” There are other action types that are also useful if you’d like to implement more logic to the enable/disable approach. As long as you conjoin the outputs of each Tool Container to a Union Tool none of your data streams require records to be output, successfully completing your bypass!
Attached is a short v10.5 example of the approach, using Radio Buttons, and the “Update Value with Formula” action to update the “Disabled” attribute of Tool Containers:
The Tree Interface can be a useful way to allow a user to select input values for an app. Since sometimes setting up the Tree File Data Source can be a little tricky to those new to this interface, this example will step through the creation of the Data Source for a simple Tree Interface.
To use a Custom File or Database as the source for the Tree Interface tool, the source needs to be in a specific format: a table with a Description and a Key field. It will look something like this:
And result in an interface that looks like this:
Let’s start with our original data, some very pretend pet statistics:
The first step is to determine the fields that will be used in the interface; in this case we want to be able to select the fields Pet, Breed, and Year in the Tree Interface. These will become the different levels in the interface.
Next, we need to determine the level in which our fields of interest will appear in the tree -- the Pet field being the most general and Year being the most detailed. Sorting in this order will make sure all the data is aligned properly. All the Cat records will be together, then all the Breed records will be together, and finally all year records.
Once the data is sorted, unique identifiers need to be created for each record to establish the hierarchy.
The first level in the hierarchy is the Pet field. To create an identifier for each unique value in the Pet field, the Tile tool can be configured to look for Unique Values on the Pet field. The unique value for the Pet field will be in the Tile_Num field.
This process needs to be repeated for the Breed and Year fields. The Tile tool for the Breed field will again be configured to Unique, but this time under Unique Fields Pet and Breed will be selected.
A little cleanup was done using a Select Tool. Three things were done: all the Tile_Sequence fields were removed, the Tile_Num fields were renamed to the appropriate Level number to make things a little easier in subsequent steps, and each Level field was changed to a string to they could be concatenated in the next step.
Now we have all the information we need to build a key for each level of our data for each record. A Formula Tool is used to create 3 new fields, one for a key at each level. Our Level 1 Key will just be the value from the Level 1 field. The Level 2 Key will be the Level 1 Key concatenated with the Level 2 field, and the Level 3 Key will be the Level 2 Key concatenated with the Level 3 field.
Now that there is a key for each level we can construct a table that has the necessary Description and Key fields. Using a set of Select tools, select each Level Key field with its corresponding description field; Pet and Level 1 Key, Breed and Level 2 key, Year and Level 3 Key.
Now Union the three Select tools together by position. Add a summarize tool and group by Pet and Level 1 Key. Grouping by these fields will remove any duplicate records. The resulting fields were also renamed to Description and Key in the Summarize tool.
Finally, a Sort tool is added to sort the Key field in ascending order. The results from the sort can then be saved to a file or loaded into a database and used in the Tree Interface tool.
The entire workflow:
Attached is the workflow used to build the Key list, as well as a very simple app that demonstrates the resulting tree created from the key values. (Attached workflows are versioned for Alteryx 10.0 or later)
You’re creating an app that involves dates. You want the user to be able to dynamically select the dates being used in the app, though. The tools you already know may not work. A Text Box would be too messy and allow lots of room for error. Pre-defined Drop Downs and List Boxes aren’t dynamic enough. Ah ha! What about that tool that looks like a calendar? The Date tool in the Interface category provides the perfect solution!