What is the correct approach when using a recursive backend workflow?

Hello everyone, I need some info here.

What is the approach you use when working with a backend workflow recursively?

I mean, how do you pass a list of items that should be processed in sequence and remove the processed item in the next iteration?

Would it be something like that?

Ex: a backend workflow with a list parameter.

1 - Schedule the backend workflow (not in a list)
2 - Provide the list as Do a search for {thing}...
3 - Process steps/actions using the {Provided List} :first item
4 - Re-schedule the same backend workflow, but now removing the processed item from the previous list {Provided List} :minus item {Provided List} :first item

Is this right?
I appreciate any help.

Actually, like reported by some others users, better to use a list of text with the unique ID and search for this item using the unique item.

However, actually, this is best to use workflow on a list instead if possible. This was not the case before, but now it’s a lot faster, more reliable and can run on very large list (100 000). This cost less WU too.

3 Likes

Thanks for the answer @Jici . But just to clarify, if for some reason I need to use this approach in the future, the way to remove items from the provided list would be as I mentioned, removing the already processed item?

Yes. But I don’t see any reason to use this except for API type

Source : Part 1: How to set up Recursive Workflows - Amlie Solutions

Is this still true? Knowing when it’s done can be quite important.

All true. But something not mentionned here are WU (a lot more with recursive vs sawol) and also racing issue that could happen. For racing issue, this could be solved in most case by increasing delay between each item. Finally, API rate limit is something to consider when running on a list.

Also, this documentation is probably not up to date with recent sawol update and pricing change.

1 Like

This topic was automatically closed after 70 days. New replies are no longer allowed.