LinkedIn
Twitter
Itโs painful but doable to handle LISTS and ENUMLISTS.
Have to keep adding Branch if Condition steps for as many as required until max length of LIST.
Please consider a way to specify a step which is essentially a loop over the LIST or ENUMLIST.
We do plan to add support for looping over a set of rows inside a process in the future.
Currently you can process a set of rows using the for each attribute in โScheduledโ events. In this case the process that is selected in the bot will execute N times, where N = the number of rows in the selected table.
Hi @prithpal as mentioned in my previous post, using the scheduler-event as outlined above just does not work for my use case. Dishearten 
to see the ability to create new Workflows has been disabled; I assume in readiness to switch-over to Bots.
However since the Automation I have seen does NOT support loops, why has the ability to create new workflows been disabled? 
See screen-shot below of the disabled new Workflow rule
Just so I understand:
โ this was never available within workflow rules to begin with.
So a workflow could not call an Action that executed a series of steps Correct?
That is what I was going to attempt before the Workflow got disabled in favour of Bots. 
Just to add here is a screen-shot of the โnewโ Bot.
The Repeat Member add does the following:
-
Repeat member add task
- calls โ Loop (repeater) Action | Create ProductGroup Member
-
Loop (repeater) Action | Create ProductGroup Member
- calls โ Loop Action | Create ProductGroup Member
-
Loop Action | Create ProductGroup Member
- calls โ Action | New 1st group member then
- calls โ Loop (repeater) Action | Create ProductGroup Member (step 2)
@prithpal Would like to know if it is possible to trigger recursive actions from within a Bot?
Steps 2, 3.1 and 3.2 check there are remaining_members left to process.
Would welcome your thoughts. 
Hi @Dan_Bahir apologies for the delay, was an AL.
A good example is given above in the screen-shot. In this instance products that belong to a group have to meet a specific criteria. Once identified, a record is created in an intermediary table called: ProductGroup_Has_Member
These records need creating to maintain the many-to-many relationship between ProductGroup has many products and a Product can belong to many ProductGroups.
The trigger is saving the details of a ProductGroup which may have amended the criteria. Hence the start condition: Check | Product group members to add
In the detailed outline of this discussion is mentioned looping over a list of โsomethingโ until that list has been processed. Since there is no LOOP construct in AppSheet, we have to make-do with Actions calling each other. The recursive actions are outlined again below:
- Loop Action | Create Product Group Member calls โ
Add | First Product Group Member
Loop (repeater) Action | Create ProductGroup Member*
The action: Loop (repeater) Action | Create ProductGroup Member calls โ Loop Action | Create Product Group Member hence creating the recursive loop.
But, as explained earlier, doing this on the client-side is too slow as it temporarily freezes the SAVE action, meaning the user has to wait for some of the processing to have been completed, before the using the app further.
Hence the question asked here: about placing this in a Bot, so it can be used server-side. Having tried most of the solutions outlined, still not found one that works without issues for maintaining a many-to-many relationship. Never got an answer from AppSheet as to what is the recommended approach for dealing with many-to-many relationships. I am sure there are lots of AppSheet community members who would like an answer to that question.
So Iโve got a system inside an app Iโm working that does exactly what youโre asking for @Bellave_Jayaram - but with actions.
- From a Parent level, we create child records, then associated grandchild records (with the grandchildren being related to both the parent AND the appropriate newly-created child).
I spent some time this morning trying to figure out how I could port this process over to the automation sideโฆ and I think I got it figure out - but I only got as far as looping through the list and creating the child records and ran into a bug due to a cycle. 
If we could get processes to accept cycles - as long as the first step in that process is a condition - we could โeasilyโ implement a system that would allow us to loop over lists.
- And since processes allow us to essentially โpushโ data into other tables, it would solve something thatโs been desperately missing from the platform FOREVER.
@prithpal
Thisโฆ might be a long video - just fyi. (^_^)
I agree totally with with the comments from @APiCC_Conor and @Rifadm817. AppSheet is a great platform to work with, but appears to be missing an important construct enabling Loop capability both instantly on the client-side and in the background, server-side.
I have tried 3 of the suggested work-arounds, with limited success. For my use-case: to use the Scheduled Event it would have to poll for updates every few minutes, 24/7, which cannot be an efficient approach.
Now attempting a 4th solution iteration removing dereferences for Select statements as suggested by @Steve in an attempt to speed-up the โloopโ updates.
I am new to AppSheet and am struggling to automate the creation of tasks for a related request upon request submission. Please see the attached flowchart for the desired behavior. I thought this would be an easy ask, however, upon Googling examples of Event triggered loops in AppSheet I was distraught to find this community post about how this functionality appears to be completely lacking.
Can someone assist me with a workaround, please?
Sure! First, a caution, this past week an issue surfaced (I think a bug) where iterative actions from a Bot only processed the first row. The same action set, activated on Form Save behavior, processed all rows as expected. So, I would advise to begin implementing the below on the Form Save behavior when entering a new Request. This will avoid any potential bug while creating the process and there is no lost effort this way.
Here is the looping construct I would create. It takes advantage of a recursive call ability to repeat adding Task rows WHILE there are still Categories that have NOT been added to a Task. The Steps are:
1) Create a looping control action. It basically starts off the recursion but has the check as to WHEN to stop looping. It looks like the below image - wait to add the Reference Action. Thatโll be done in a later step
The critical part is the Behavior criteria that allows the action to run and stop. I used this expression:
COUNT(SELECT(Categories[Category ID], NOT(IN([Category ID], Select(Tasks[Category], [Request] = [_THISROW].[Request ID]))))) > 0
2) Create the action that adds the Task Rows. See below.
To assign the Categories, the action simply picks off the first one in the list of Categories that have NOT yet been assigned to a task for this Request. No Behavior criteria on this one.
ANY(SELECT(Categories[Category ID], NOT(IN([Category ID], Select(Tasks[Category], [Request] = [_THISROW].[Request ID])))))
3) Create a Grouped Action that calls the action to add the Task Row and then calls the โtopโ action to loop again. It looks like the below and no Behavior criteria.
4) Add the Grouped action from 3) to the action in 1) as the Reference Action.
5) Attach the action in 1) to the Form Save behavior and Test!
Here is an example run
Categories are:
No Requests or Tasks:
Add a Request. Immediately switching to the Tasks view shows all rows there while updates are still being made to the server. See image.
If your use case requires the use of a Bot, simply add the โloop controlโ action to the Process Step and you are good to go!!
I hope this helps!!
Good news!! I created a Bot and attached the above action set and all the expected rows were created. Either the issue I mentioned is only for certain use cases or it has been fixed.
