Hi all,
Are there any tutorials or even better - templates? It looks like Sub Flows could potentially be very useful, but there is barely any documentation or examples.
Thanks!
How are you thinking of using them? Any specific use cases in mind? We’re exploring improving the experience of subflows at the moment.
Hi Ash, jumping in because I’ve been starting to implement subflows heavily. My main frustration with them is the need to manually create test/sample inputs and outputs at both ends (calling step and subflow itself). I do understand that the callable subflow doesn’t have any inherent way of knowing what inputs it might get. But the sample outputs should be deterministic from whatever steps are run in the subflow itself. I have to do a lot of exporting and copy paste to generate what should just be there from testing the flow.
The more annoying part is having to specify these on the “call flow” step. Why can’t testing the step just…call the subflow on the given inputs? Creating complex fake results and then pasting them in is both more error prone and less flexible.
For example: Several of my current use cases involve a subflow with a code step that flexibly filters and flattens portions of the JSON input based on other input parameters. I wanted to make this a subflow so I could have one optimized, maintainable approach to plug into what could eventually be dozens of flows that need to work with the same type of input JSON, but where I’ll want different components pulled out, flattened, and otherwise manipulated. The process itself works great! BUT right now…every time I need to use it, I can’t just set the input parameters…I need to take some sample output from a step in the current “main” flow I’m developing, manipulate it so I can paste it into fake input JSON for the subflow, switch to the subflow, test that input in the subflow, get the test outputs specific to that configuration, and paste it all back into the “sample outputs” field for the call subflow step in the main flow. And even then, unless I do further work to edit all of that, I have real process data exposed in a configuration step. It’s not great.
My strong preference would be for there to be none of this, and have (1) testing within the subflow work similarly to how testing a flow initiated by a webhook works; and (2) testing from the main flow work as it does in any other type of step testing.
And in writing that, I just realized: why am I even bothering with your current implementation of subflows if they are just a more-annoying version of flows I can create and call within AP using webhooks? Does the team have a vision for subflows in which the experience is nicer than that?
This is exactly what I’m trying to understand - is how to use them and what are some possible use cases and benefits.
karla, you can think of subflows as a way to make other flows more modular, especially where there is a fiddly set of actions that multiple flows might use. The subflow lets you build that once, have one instance to maintain, and use it where you need it. I think of a subflow as a utility function that (a) can’t be accomplished from a single or simple piece execution; and (b) has reusable value across flows.
A very simple example is a subflow I created for date manipulation. It takes as inputs a text string that might include a date or date time in any one of about a dozen formats as well as a target result format. It automatically detects and extracts date/time values from the input string, prioritizing among multiple matches, then converts that value into the format specified in the input parameters. It’s really just a code step. I could just reuse it by copying that step from one flow to another. But making it a subflow creates fewer headaches for future me. I can add new formats, fix problems, or change the logic once and every flow instantly benefits.