1

Hello everyone, I have seen several discussions on the forum about this subject, some use different approaches and I was wondering what is the best way, the most reliable or the one with the least problems, to check the last item processed to make sure that the list provided was finalized before any further action was taken.

I ask this because I’m having a some race issues when trying to update the same field, and I would like to perform a final verification step when SAWOL finishes.

Thank you in advance for any suggestions.g on my side.

2

Have an ‘isLastItem’ yes/no parameter.

Suppose we’re scheduling on a List of Users.

In that parameter, we put This User is List of Users:last item.

That will be ‘yes’ when it’s the last workflow that was scheduled to run. It will not guarantee that they complete in order (though they generally do, unless you’re dealing with external APIs that have variable response times).

1 Like
3

@Lumyna when using the approach it might be better/cheaper for the parameter of last item to be text, send the unique id of that last item and use condition this item unique id is last item parameter.

This way you do not carry the thing through each loop for the last item.

2 Likes
4

What do you mean? That’s not what we’re doing. We only have one item per API workflow.

CleanShot 2024-09-09 at 15.02.42@2x
CleanShot 2024-09-09 at 15.02.42@2x640×1298 77.3 KB

And the schedule action looks like this (it only list uses numbers because of a quirk of the plugin I’m using in this particular workflow but same principles apply)

CleanShot 2024-09-09 at 15.04.40@2x
CleanShot 2024-09-09 at 15.04.40@2x728×1432 149 KB

The ‘isLastSection’ parameter is then ‘yes’ when it’s the last section, and I can reference that within the workflow. And no Things (as it’s yes/no) so no WU :grin:

2 Likes
5

Thanks guys, I’ll try this approach.

1 Like
6

Its scheduled to run on a list of things…so every parameter you send back, I believe is going to be fetched for each item in the list a backend workflow scheduled on a list would run, so if you have 100 items in your list, and send a parameter of a type (not necessarily the same type of thing as the list, but just a thing) that that thing you send for as the parameter value when scheduling on a list is retrieved each time the backend workflow runs, so 100 times for a list of 100 things.

Yes, these are the same principles laid out in past threads about best way to know when is the last item on a list ran to avoid race conditions.

That a neat little twist on the approach. Instead of referencing a parameter to equate it to the last item from the list in the backend workflow itself, using a yes/no to denote its the last item when scheduling. I like it. Saves time on the conditions in the backend workflow itself.

7

Ah yes, but I don’t think making them texts would optimise anything. If you schedule on list of unique IDs / texts you’ll have to Do a search for the unique ID in the workflow anyway to access the Thing you originally wanted to SAWOL on.

Passing List of Things as List of text unique IDs can save WU if both the following are true:

  1. You need to pass a list of Things into the API call
  2. You don’t need to access every Thing in the list of things (e.g only the first / last item)
8

No just reference the previous steps ‘things’ unique ID and you have it for the condition on when to run the action at the end of all items being processed.

9

Well guys, thank you both for the tips and comments, I really appreciate it.

The approach apparently works when there is no external API involved. When the creation of new things depends on obtaining data from another external API, apparently there must be some delay or something that is intrinsic to this communication, which probably means that the list is not executed in the correct order, or maybe it is, but the last item processed may not be the last item flagged in the parameter all the time. So, in some cases the verification fails.

Anyways, thanks for the help.

10

Hey @Lumyna - you should look into recursive workflows.

SAWOL can be unreliable when needing to

  1. rely on the previous item being updated,
  2. update the same thing as the other workflow (handling race conditions) and
  3. handle actions that are variable in completion time (e.g. external API, plugin actions, heavy workflows)
2 Likes
11

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