When we have more than 1000 entries, Do a search for things is way faster than List of things when having a RG (repeating group) or something being displayed on a user’s device.
But what happens when I need to do a recurring backend workflow, does Do a search for things or List of things are different? Since it isn’t happening on a user’s device.
For example:
A user clicks a button that schedules an API workflow that is a recurring workflow with 1 parameter that is a list of things. The literal expresion for scheduling the API workflow is better with Do a search for things than doing a List of things, right?
Inside de Backend recurring workflow, when scheduling itself, is there a difference between scheduling itself with a Do a search for things, or scheduling itself with a List of things? Since again, this is happening on the server and not on a user’s device.
When running a workflow that reschedules itself, I try to avoid searches. No scientific reason here. Just an intuition that sending lists should be orderly implemented.
Having said this, during my latest projects … searches work fine as I am building as light objects as possible. One way inverse relationships and locating unavoidable needed listed objects through searching.
I would say that the best way to go in your specific situation is to run tests for both and time them … and also compare both for completeness. Reason I say the latter is that the “design” of the order of operations needs to be done as best as possible inside the loop. Use log objects to gather completion data in key actions.
I don’t use lists as a data field unless I expect it to never exceed 20 items. Otherwise, I do 1:1 relations on a separate data type.
Always try to send your list for backend workflows during trigger. Avoid as much as possible searches in your workflows, especially recursive because you’ll just be searching on each recursive instance.
