The table is as follows.
The actions are as follows.
If Action “Loop” is set during FormSave, it will be reflected in the spreadsheet as intended.
Next, remove the Action on FormSave and create Automation.
Then, it is an endless loop.
Is this a specification? Is it a bug?
Solved! Go to Solution.
Hmmm, it works for me...
The loop stops after the iteration over the ENUMLIST completes... (the error runs timed out because of the infinite loop)
Try to use SELECT in the Add a Child record action also and see if it works. That is the only difference I see...
I would vote for calling this a bug.
You may have already figured this out but
ISNOTBLANK([values] - SELECT(CHILD[value],[p_id]=[_Thisrow]))
as a work-around works as expected.
I cannot recall exactly under what circumstances but I've found expressions using [Related xxx] construct in bots can be buggy.
Thank you for your reply.
I tried what you suggested, but as I said, an infinite loop occurred here as well.
Hmmm, it works for me...
The loop stops after the iteration over the ENUMLIST completes... (the error runs timed out because of the infinite loop)
Try to use SELECT in the Add a Child record action also and see if it works. That is the only difference I see...
Thank you very much!
You are right, I did change the INDEX expression for “Loop1: Add a child record” to a SELECT function, and I was able to confirm that it works as expected in Automation!
PS.
I have reported this issue as a bug.
id 4-9428000036464
It could be due to behavioral differences between a VC (REF_ROWS) and a SELECT statement in the timing of evaluation... Anyway, at least clarification from Google would be quite helpful.
Using the [Related XXX] construct didnot work for me in automations. Also noted that the same construct works on actions.
Have changed the [Related XXX] to Select Function and the issue was resolved. Thank you @TeeSee1 @イルカのえっちゃん
I recently had to sort through this type of issue myself.
Automation recomputes virtual columns differently than everywhere else. It appears that virtual columns are not recomputed at all during a bot run except those that are directly affected by a normal column changed by the bot. Related ... columns are not directly affected by any column change, so they are not recomputed by Automation.
For actions used by Automation, do not reference Related ... virtual columns and instead use expressions that query the tables directly. This does introduce some inefficiency, so do your very best to keep those expressions as simple as possible.
Thank you for the valuable information.
I received an answer from support, so I'd like to share it with you.
In conclusion, this does not appear to be a bug but intended behavior.
Below is the answer from support:
This is to notify you that we have got an update from our specialists and they mentioned that you were using a virtual column Related child as an exit condition from the looping action and entering into the infinite loop but after using the select function the issue got resolved.
I would like to inform you that this was occurring because the break condition for the looping action was not working, in case of automation bot, bot usually executes at the server side and the virtual column are basically local to the user's device and it is not an ideal choice to use virtual column as a condition in case of automation bots. We would say that this is not a bug but an intended behavior.
So I guess using a virtual column in bot conditions in general is a watch out thing that should be avoided or well tested before releasing into production especially when you expect the values to change during the course of a box execution.
Support is awful.
User | Count |
---|---|
24 | |
13 | |
4 | |
3 | |
3 |