LinkedIn
Twitter
I have a bot that is triggered by data being added to a table. This bot triggers a set of looping actions that creates events from a start date to an end date in the same table. The bot triggers fine and events are created through the end date, but if the looping process lasts longer than 5 minutes it seems to trigger an additional looping process for the current row while continuing with the first loop. This repeats at what seems to be 5-minute intervals and I end up with a lot of duplicate events.
I think this must have something to do with mixing bots and actions. I know that bots make the changes at the server while actions make them on the client-side, so could it be that after 5-minutes server changes are synced back to the client and this for some reason disrupts/restarts the action loop?
I have also tried just triggering these actions on form submit, but for some reason when I do this it does not start the loop as it should.
Solved
1 ACCEPTED SOLUTION
Closing the loop on this - I ended up solving it by 1. deleting the first action (2a) in the grouping and having the add date and cadence ID being set as initial values instead; and 2. adding a condition to the 4th action. The main problem was that at the 5-minute mark, if the looping was still running, the trigger row would be reset as if it was being added anew over the existing row. When this happened, because the add date and cadence id were initially blank, they would be cleared and the automation looping would be triggered again. When this happened, step 2a would set the add date to the first in the cadence again and set the cadence id to a new unique value.
Getting rid of 2a and setting the cadence id to an initial value was crucial in helping solve this because now when the row is reset, it resets with the same cadence id as all of the other events that have already been created. I could now compare that reset row with the others to conditionally stop the automation from re-triggering. I knew I couldn't prevent the initial row from resyncing to the database at the 5-minute mark, so I was trying to identify a way to stop the additional loops from running while still allowing that first one to finish. The workaround ended up being to add this condition to the 4th action:
The looping works by updating the add date on the triggering row and creating the subsequent event based on that add date. Each subsequent event is tagged with its add date, but only that initial row has the add date updating with each loop. So If I was creating events every Mon Tue Fri through 2024, at the 5-minute mark I may have x number of events with the same cadence ID (thanks to setting it as an initial value) through 6/9/2023. When the initial row is reset the add date and cadence id are also reset based on the initial value, so the add date of 6/9/2023 would be replaced with 12/6/2022 and the cadence ID would be replaced with the exact same value. When this reset happens, AppSheet treats it as if it's a brand new row and triggers any relevant add bots - this is the central issue i had to workaround. The condition I set on the #4 step essentially compares the add date when a row is added to all other rows with the same cadence id. If the add date on the new row is not within a week of the latest row in that cadence it will not trigger. When testing this worked great. The row was reset at the 5-minute mark, resetting the add date to the initial value, but the automation did not trigger and the add date was replaced with the next up in the initial loop (which would be 6/12/2023 in the above example).
Scratch that. The issue is still occurring! @Steve this workflow is based off your looping actions workflow. When I try to trigger this loop on form submit the action does not fire. Triggering it through a bot works well but I believe this is the source of my issue (though I've yet to figure out exactly why).
If I can get this to trigger on form submit instead I'd imagine the problem would be solved. Any help would be very appreciated. I've attached screenshots of the actions below.
Right now the actions loop triggers on a data add bot (screenshot of task below), but again after about 5 minutes the initial row is deleted and then re-added which causes the bot to trigger again/the loop to restart.
Closing the loop on this - I ended up solving it by 1. deleting the first action (2a) in the grouping and having the add date and cadence ID being set as initial values instead; and 2. adding a condition to the 4th action. The main problem was that at the 5-minute mark, if the looping was still running, the trigger row would be reset as if it was being added anew over the existing row. When this happened, because the add date and cadence id were initially blank, they would be cleared and the automation looping would be triggered again. When this happened, step 2a would set the add date to the first in the cadence again and set the cadence id to a new unique value.
Getting rid of 2a and setting the cadence id to an initial value was crucial in helping solve this because now when the row is reset, it resets with the same cadence id as all of the other events that have already been created. I could now compare that reset row with the others to conditionally stop the automation from re-triggering. I knew I couldn't prevent the initial row from resyncing to the database at the 5-minute mark, so I was trying to identify a way to stop the additional loops from running while still allowing that first one to finish. The workaround ended up being to add this condition to the 4th action:
The looping works by updating the add date on the triggering row and creating the subsequent event based on that add date. Each subsequent event is tagged with its add date, but only that initial row has the add date updating with each loop. So If I was creating events every Mon Tue Fri through 2024, at the 5-minute mark I may have x number of events with the same cadence ID (thanks to setting it as an initial value) through 6/9/2023. When the initial row is reset the add date and cadence id are also reset based on the initial value, so the add date of 6/9/2023 would be replaced with 12/6/2022 and the cadence ID would be replaced with the exact same value. When this reset happens, AppSheet treats it as if it's a brand new row and triggers any relevant add bots - this is the central issue i had to workaround. The condition I set on the #4 step essentially compares the add date when a row is added to all other rows with the same cadence id. If the add date on the new row is not within a week of the latest row in that cadence it will not trigger. When testing this worked great. The row was reset at the 5-minute mark, resetting the add date to the initial value, but the automation did not trigger and the add date was replaced with the next up in the initial loop (which would be 6/12/2023 in the above example).
