This article was written by Emil Kos and originally appeared on the Alteryx Engine Works Blog here: https://community.alteryx.com/t5/Engine-Works/Starting-the-Conversation-Around-Workflow-and-Process/ba-p/700545#
This article is meant to be a resource for the small teams that recently started the Alteryx Designer implementation. As we all know, this is an excellent tool that delivers plenty of value to various industries, and my goal is to strengthen the foundation in making people more fulfilled while using it.
My main intention is to create a high-level document that can be the starting point for conversation around workflow- and process-standardisation, focused on Alteryx Designer.
Proper folder structure
I cannot count how much time I’ve wasted because of an incorrectly designed folder structure. In my opinion, reorganising the directories is a worthy investment that will pay off during the long run.
Please find an example below that you can implement in your team:
I am not recommending this as is the best structure you can achieve, as each team is different; this can be a good starting point for a conversation about improving it. Thanks to a frank discussion, you and your colleagues will decide what the most efficient way is.
Make your folders clean
Make sure you are removing unnecessary files. Archive the files that are outdated, and most important make it straightforward for everyone what is the last working version of the process.
Descriptive titles and enumeration
Use a naming convention that clearly states what the workflow is doing and what is the proper execution sequence. Small amendments like this can save a lot of time, especially if you have various complex projects to handle by one team.
If you use a naming convention similar to what is shown the example it will be much easier to maintain all of your workflows - especially if you are working in a big team with a significant number of workflows.
Using comments, annotations, tool containers
Thanks to proper use of Comment tools and the annotation function, it will be much easier to maintain workflows. After time, everyone will know why the analyst applied certain logic in the workflow. In addition, it will help you understand your work better, and it will be significant support when you need to go back to a project you’ve probably forgotten about.
There are hundreds of approaches to how to use them, but I would suggest something simple that you and your team can stick to.
Please see example below:
Put your procedure in the workflows itself - if not all, at least majority of it. This way, it will be easier for you to keep it updated and you will not waste time searching for it.
To write the procedure, you can use the Comment tool. Another good practice is to populate the Meta Info tab in the Workflow - Configuration. You can put information like links to documentation, version number, description or the Author name, which can be especially handy in bigger teams.
When your solution is ready - polish it
After you complete your project:
- Revisit your workflow and improve it by cleaning it.
- Investigate if some of the tools are unnecessary.
- Think of what can be removed and optimised.
- The sooner after completion, the easier it will be to remember pertinent details.
Thanks to that, your workflow will be easier to maintain, and it will run faster.
Build automated tests
A good practice is to have an automated test to mitigate the risk of conducting an error. I would especially recommend adapting those tests in situations where you identified a mistake in the past. Implementing tests to prevent errors from happening in the future is the correct approach.
To give you some basic understanding of what the automated test can do for you:
- The test tool can throw an error when you are creating duplicates on join.
- The test tool also can throw an error when not all the data joined correctly.
- You can use the message tool to write a formula to check the data on some condition. One of it can be if the date range of the data meets specific criteria.