LinkedIn
Twitter
I have already contacted support, but I think this is a serious issue, so I am posting here as well.
Branch conditions involving [_Thisrow] in Automation are not being determined correctly.
It appears to me that the following problem, which occurred last December, is occurring again.
I will share my verification details.
If the following branch condition is True, the data added will be deleted.
COUNT(SELECT(Data[ID], [ID]<>[_Thisrow]))>1
However, it should always be False because only one record currently exists.
But now, no matter what record is added, it is determined to be True and the registered data is deleted.
If my verification is lacking in consideration, please let me know.
Note that there has been a problem with the display of the emulator recently, and this Gif is also experiencing this phenomenon. However, this is not the main issue, so please ignore it.
I am typing this message out of frustration contacting support. Each time they make sure they don't know anything about appsheet. They are not even able to answer very basic questions.
I asked them a question
My question is: I have a VALIDIF formula in REF type column and it shows 'ADD' button. Is it correct behaviour ?
I just wanted to know if its a bug or intentional behaviour.
The reply from support was surprising.
"I understand your concern, Could you please try adding the Editable_if as "false" and confirm, if it removes the add button"
He wanted me to make the column above Sales Order Acceptance Items ID to FALSE so it will hide the REF type column 'Add' Button that is referenced to Parent Table.
I am unaware how updating EDITABLE IF as False will hide the add button in REF Type.
I am aware if we use a slice with readonly then add button will be hidden. But was confused and had to ask this if I am right.
Not sure where this is heading to. This is one of my many bad support experiences and I told him his answer is 'Stupid'.
In my cases they close the chat without even understanding its a bug. I am very sure whole appsheet team will be unaware of this bug if its a bug. Because when we report it they do are capable of identifying it even after explaining. All the developers or mangers see is closed tickets and no bugs.
Again as someone said:
Now onwards every time I am disappointed by support I am going to come here and post it. Bugs are never being reported into the appsheet team even after reporting it.
@Rifad wrote:
@devingu wrote:
please understand this is a new support team and the team may need time to ramp up
That's certainly a challenging situation--I've been in your same position in my own company.
I'm glad you continue to focus on this, and hope your seeming optimism that improvement is on the horizon is warranted.
Meanwhile, as you're acknowledging, the experience for users is indeed problematic. Besides the inaccurate and misguided responses like those referenced in this conversation and like others you and I have discussed, case staleness is also an issue. I certainly don't need frequent responses that reflect lack of platform knowledge and counterproductively eat up my time in re-explaining, but it would be helpful to get issues actually resolved. Here's a sample of issues for which I haven't received any update in weeks.
I am not sure if the same [_Thisrow] issue. I have an action that works perfect but when I use same action in an automation bot it does not work properly. I have [_thisrow] used inside an action of looping action to fetch data from current parent table and lookup from other tables and add to child table.
Makes me think if its issue with automation because if i press that action directly from app it works perfectly fine. Same action in bot is not fetching data and returns empty row.
Again, this works perfectly fine when manually triggered using action. Any help would be highly appreciated.
This is likely to cause problems:
Generally speaking, never dereference [_THISROW] outside of a query function (SELECT(), etc.): it produces inconsistent results. You can use it standalone to refer to the row's key column (outside of a query), but don't dereference it (outside of a query).
