Engine Works

Under the hood of Alteryx: tips, tricks and how-tos.
tristank
11 - Bolide

Introduction

 

One of the best features of Alteryx is the ability to create a self-service app. With a simple workflow, you can help turn what could be a manual, tedious process for the business into an automated one that can be completed in seconds versus minutes or hours. While the immediate benefit of an app is saving time and money, in the long term, you are allowing the business user to focus on work more related to their position and skills, thus likely increasing workplace satisfaction and organizational efficiency.

 

When developing an app, it is important to install safeguards in your workflow to prevent inaccurate outputs or constant developer intervention. Similarly, we want to make the self-service process as clear and as simple as possible for the business. When we take those extra steps, we ensure that our app will continue to function long after we have moved on to another project.

 

In this blog, we are going to explore a few simple ways to validate the inputs and outputs of an app while also touching on how we can make the self-service process easy and digestible for the end user. If you are new to apps and unsure of how to build them, I highly recommend you start with Alteryx’s interactive learning resources on apps and then come back and read this blog. While it may take a little extra work to implement some of these processes, you will save yourself, the organization, and its employees time and money.

 

image001.png

Figure 1: New to apps? Start with the interactive lessons created by Alteryx

 

Integrate Safeguards Into Your Workflow

 

For a developer, one of the scariest things about a self-service app is that we can’t control everything! The user may be able to choose their inputs, what data to filter on, or even what outputs they will download. While this flexibility is beneficial to the end-user, it also comes with an increased risk of workflow failure. As developers, we want to reduce this risk as much as possible, especially if the output we are creating is business-critical or being stored somewhere like a database. By creating safeguards in the workflow, we are preventing an undesirable output that will cost us the time and resources we were supposed to be saving with a self-service application in the first place.


Now that we understand why we need to make our app more robust, what does the application of this logic look like within a workflow? Fortunately, it can be incredibly easy! Generally, an application is broken down into three parts: Validating the selected interface options, acting if problems have been identified, and informing the user of what went wrong so that appropriate action can be taken.

 

image002.png

Figure 2: When designing your app, make it more robust by following this development path

 

Let’s use Input tools as an example, as they are the most frequently interfaced with by users in self-service apps and are inherently risky. When we give the user the option to select any file to drop into our workflow as developers, we must recognize that they may choose the incorrect file, the schema may have changed, or they could be trying to input an empty table. If this is the case, it is our responsibility to prevent the workflow from running and prevent an undesirable output. We start with our first step, which is testing and validating the interface options. Tools from the Data Investigation tool palette, such as Field Analysis or Data Profile, can be used to check for nulls or missing data from the inputted file. We can also use these tools to validate the inputted schema versus the expected schema. Missing or extra fields may, but not always, warrant the cancellation of the workflow.

 

image003.png

Figure 3: Data investigation tools can help you determine potential issues that may arise with user inputs

 

If the inputs we have tested do not meet our standards, it is time to move to step two and act. Usually, this means canceling the workflow from running, as no output is better than a bad output. We can configure the runtime options under the Configuration tab to cancel a workflow when an error arises, but this leads to an important question: If our validation tests fail, how do we trigger an error?

 

The Message and Error tools are the primary tools in Alteryx that can trigger an error in a workflow based on conditional logic testing. Subsequently, this error can cancel a workflow before an output is generated. By linking the results of the validation tests to these tools, a developer can easily test and flag a range of interface options.


image004.png

Figure 4: Messaging tools can help to both cancel workflows and inform the user of potential issues

 

We have now successfully prevented a self-service app that has failed our tests from running.

 

The final step is informing the user why an error led to the workflow being canceled. There are two benefits to ‘lifting the veil’ and providing these details to the self-service user. By providing immediate context for what has happened, the app user can attempt to make fixes to their interface options on their own, as opposed to reaching out to the Alteryx development team. In the long term, the user will have a better understanding of the appropriate interface options, resulting in decreased error rates for the self-service app.

 

If you want to deploy these validation practices to several self-service applications, then you will want to create tidy, packaged macros or validation apps that can be utilized by multiple developers. Below is an example of a field validation app I have created that tests the inputted table against an expected schema, errors if the schemas do not align, and generates a report of the validation tests to the app user. By creating apps or macros for our validation tests, we make it easier for developers to implement these best practices into their workflows. If you are interested in checking out the functionality of this app, you can find it here.

 

image005.png

Figure 5: This app tests an inputted schema against the expected schema and can easily be deployed by multiple developers or converted to a macro

 

Avoid Problems With Clarity and Conciseness

 

While it is important to implement safeguards that will catch and prevent errors during the execution of a self-service app, the best-case scenario is that no errors happen at all! Clearly communicating the expected inputs and outputs of the app to the user before they run the workflow will help to avoid errors while reducing the need to reach out to the developer of the workflow for clarification.

 

First, update the description under the meta info tab of the configuration pane. Here, you can detail the purpose of the workflow, expected inputs, outputs, and potential issues that may arise when executing the workflow in Gallery. The description of the workflow will appear at the top of the workflow in Gallery right next to the run button, so there is a good chance that your user will read it before execution.

 

image006.png

Figure 7: Use the meta info tab to provide a workflow description for the self-service user

 

Second, when you are using interface tools, make sure to be very specific about what you expect the person to input. When possible, include examples in the interface prompt and have a default text that aligns with the expected inputs.

 

image007.png

Figure 8: Create clear user prompts with examples of the expected inputs

 

Finally, provide thorough documentation in an environment accessible to the app user. This is your opportunity to detail the desired schema of the inputs, potential outputs and how to interpret and resolve various errors that may arrive. Alongside the documentation, I will usually have sample input and output files that they can use to adjust their own files.

 

While reducing the error rates of a self-service app is a good reason to implement these various safeguards, you are also saving yourself and the business time. If the app you have designed requires you to help the users run it because they are always running into problems, then there was little point in automating the process in the first place. In Alteryx, we can design products that will last, and it is important to take full advantage of the tools that allow us to do just that.

 

Best of luck with your app deployment, and feel free to tag me in the Community forums or comment below if you have any questions!

 

Comments