Engine Works
Under the hood of Alteryx: tips, tricks and how-tos.
Introduction
If you are here, then you are already aware of chained apps and how they work. In short, Chained Apps allow you to orchestrate the Apps so that when one app finishes, the next starts automatically.
Wonderful, but let’s take it a step further and make the second app an option as well. That will essentially allow users to run a specific custom app rather than a fixed app with multiple questions.
This will make the process simpler since you don’t have to manage a big workflow handling the whole process, and instead, you can have multiple SubApps doing that. This also allows users to work more efficiently and faster if multiple users are handling different SubApps.
Now, how you want to do it will depend on you. Let me walk you through the concept here.
Architecture
Below is the basic architecture.
Below are the flow details:
- App1 is the first analytical app that the user will be interacting with.
- App2 is the second analytical app in the chain. App1 always triggers App2.
- The green circles (SubApp1, SubApp2, SubApp3) are the analytical apps that are stored in the same folder as App1.
Process Details
Now, the following is what happens in the background inside App1 (refer to the snip of App1 below):
- Dropdown tool contains the list of all SubApps (Manually added in my example).
- User selects the App they want to run next.
- Blob input picks up the SubApp selected
- Formula tool creates the output path, where we also rename SubApp with App2.yxwz
- Blob output replaces the existing App2.
In the settings of App1, we are chaining App2 as shown below.
What will happen is that App1 will always trigger App2, but while processing App1, we have changed what App2 is, thus making the process dynamic.
Below is the folder structure for my example.
The first two apps are my SubApps.
Conclusion
This dynamic app framework enables seamless runtime and easy workflow management. Instead of a heavy second app in the chain, a user can have multiple apps that can be run by choice, making it easier for users to create processes and debug.
A heavy workflow takes longer to debug or update; multiple smaller workflows allow users to easily make the required changes and have a team work on different subApps, making the development faster.
Potential Use Cases
- A big workflow can be broken into smaller workflows, making the process much easier and simpler.
- Users can easily onboard new processes into the main workflow, without risking the whole process downtime.
- If you are running for multiple clients that have similar datasets, your first workflow can transform the data into a standard data model, and based on the client’s second flow, it will be chosen and run. This will help in keeping each client flow independent.
- You can potentially create two different approaches for achieving a goal, and identify which logic works better for your task. This is like picking which LLM model suits your needs.
Use cases here are endless based on imagination.
