An often overlooked but invaluable feature of any repeatable workflow, error reporting is deceptively simple but very effective. These tools can be manipulated to send out exernal alerts from Alteryx when workflows fail, or just to error and abort running a workflow if the values are not consistent with expectations.

In this blog, I will run through two such tools - "Message" and "Test" - and explain their functionality, as well as potential use cases within Alteryx.

Message

The Message tool is the more flexible of the two when it comes to error reporting, allowing the designer to output a message in the results pane, based on the data results passed through the tool. Here is an example of the configuration someone may use when implementing this tool (I have set this up to work on some UK university data).

The first option is when to send the message: either before any data passes through, based on a condition (if that condition ends up being true), after the last record has passed through, or after all tools in the flow have completed their processes.

In this example, my set-up may look confusing, but has a logical step to it. I have connected this tool to the R Output anchor of a Join tool, where I expect no lost data, and for all of my data inputs to move through to the J Output. If this isn't true (i.e. if data reached the R Output, where my Message tool is connected), then I always want an output; hence, by putting "1=1" (something which will always be true if the tool has to run), then I will prompt that message every time the Join gives an unexpected result.

The message type can also vary: for example, if your Message tool is set up to alert to data conversion errors, you can set the Message to be the same orange and with the same alert sign. Similarly, you can do that for warnings and errors - even stopping the workflow from running past that point of erroring. Furthermore, if this tool is contained within a Macro (or Macros), setting the message priority will force that message to show, depending on the level of priority you give the tool.

Finally, you have the option to change the message itself, and this is where the flexibility of the tool really comes to the fore. For example, the input of this part of the tool gives the option to use both fields involved in the flow (and also constants and variables, such as the record number), increasing the functionality of the tool.

Here, I am using an expression that benefits from providing the specific record that has failed through the Provider's ID code (UKPRN), surrounded by a string of relevant context, written as:

"The provider " + [Provider UKPRN] + " is NOT stored in the metadata"

This string will be displayed each time this workflow reaches the Message tool without me wanting it to. The Message tool's "run after all tools have finished" can just be useful as a signpost in the Results pane of the ending of a run.

Test

Test is an equally useful (albeit more rigid) reporting tool when encountering errors and discrepancies in workflows. Although slightly less customisation than with the Message tool, this tool can have as many inputs as you would like, therefore allowing stacking of error criteria from any of the tools in your workflow.

Here is another example of the configuration and one of my own inputs. Although simple, the intricacies come when creating an test (through the "Add" button): clicking this will open a window where you can input a test name, the connection input (i.e. which of your datastreams this test is relevant to), the test type (equalling a set value or just if the response is true), and then the test value  (which can relate to expressions, as with the Message tool). My configuration is quite simple, and again, works off the premise of no data coming through the R Output of the Join tool.

Here, I am setting up the connection to expect no records to come through (hence the final two fields and their configurations). Thus, if these conditions are not met, the tool will error, and the message will appear in the results section. One persky feature to look out for here - the option right at the bottom of the configuration tool ("Don't report errors if there are other errors in the workflow") is automatically checked, but maybe not desired. This would prevent errors being discovered here, just because of potentially unrelated errors elsewhere in the workflow. Therefore, more often than not, I leave this unticked.