Appsheet Support Change?

[Trevwiller]

Hello Community,

I am looking to submit an issue to Appsheet support for an automation issue causing hundreds of ghost runs. Issue at hand is I navigating to Appsheet support and it doesnt exist anymore. It says the support has been merged under workspace admin. I do see the below banner message on the Appsheet support page, but when navigating to workspace support and talking with the AI agent and it states I must go to the appsheet support and sends me in a loop.

Message on Appsheet help center:
“Starting June 1, 2026, AppSheet support for Workspace Admin creators will transition to Google Workspace support to provide a more tailored experience.”

[WillowMobileSys]

Do you have a paid account? It was my understanding that the support options no longer appear AppSheet account that are Free - i.e. no deployed apps. But they should continue showing if you are a paying customer.

[Trevwiller]

Hello Willow,

Yes we have enterprise plus plans for each user in my org in our google workspace.

[WillowMobileSys]

Let me rephrase…Is the account you are using to access the apps in AppSheet considered the MAIN (App Creator) account?

If it is not, I don’t think you’ll see the Support options.

For example, one of my clients has a Workspace account and the MAIN account email is info@… MY email under that Workspace account is jbaer@…

I DO NOT see the support options within the AppSheet pages. However, if I log in with the main account (which I have done in the past) I do see the support options.

I hope this helps clarify!

[Trevwiller]

Hello Willow,

Yes the account being used to access support as per normal pre 6/1/26 has been through the appsheet support page to submit a support issue per the same standards of the past years. Now as of today 8/31/26 post 6/1/26 the system has changed. Same SOP for trying to submit a ticket yet the google submital proccess has changed.

[Trevwiller]

[Trevwiller]

[Steve]

This has been an ongoing train wreck from day one, a problem that nobody at AppSheet or Google has acknowledged.

Attn @Jose_Arteaga @devingu @cschalk_ws

[WillowMobileSys]

Yeah, I just checked out the pages. It is a bit different since I last accessed them.

It seems they are trying to move away from direct support. Not many tech companies do direct support - unless it is a paid service.

[Trevwiller]

Well with no support looks like the way to solve the DDOS of our indox was to delete the app. Thanks Appsheet support! Thank you for making gemini the gate keeper as with all things. Future break glass option is just make a copy of the deployed app and delete the deployed app while users are active in it. Now time to get the new app up on the google play store and work on a proper apology to my team on a service we pay good money for each month.

[Jose_Arteaga]

Hello @Trevwiller,

I sincerely apologize for this, this has been escalated and unfortunately it is not resolved yet.

I can help you raise a bug directly for your issue if you will.I’m sending you a PM to gather all the details.

[Jose_Arteaga]

Hello @Trevwiller,

We got a response from the support team. I have shared all the details via PM.

Please let me know if you have any further questions or if it is Ok to close this thread.

[Trevwiller]

@Jose_Arteaga

Hello @Trevwiller,

Thank you for your patience!. The engineering team has identified the exact root cause.

It was not a platform loop or scheduler glitch, but rather an edge-case interaction between the bot configuration and AppSheet’s text evaluation engine.

Detailed explanation:

The Trigger Condition:
The bot had “For each row in table” enabled with the condition: [Key] = TEXT(TOP(Mileage Logs to review for mileage overage[Key], 1))

The Edge Case:
When the slice returned zero records, the expression evaluated to [Key] = “”.

The Text Evaluation:
In AppSheet, the standard equals operator (=) for Text behaves as a prefix/starts-with check. Checking whether a text string begins with an empty string evaluates to TRUE for every record.

The Wildcard Effect:
The expression “Does the Key start with an empty string?” evaluates to TRUE for every single string in existence. This effectively converted what the customer thought was a restrictive filter into a wildcard filter, matching all 4,434 rows.
The server began processing thousands of rows individually. It successfully queued/spawned approximately 4,450 background email tasks before hitting Cloud Scheduler’s strict 300-second (5-minute) HTTP timeout envelope.
At 5 minutes, the main handler thread was terminated via TaskCanceledException.

Why the Monitor Showed 0 Runs:
Dispatching thousands of tasks hit Cloud Scheduler’s 5-minute timeout threshold, which abruptly halted the main process before it could write the final completion record to the audit monitor.

Why Deletion Didn’t Stop It Immediately:
Once background jobs are dispatched to the execution queue, they run independently until drained, even if the parent app definition changes.

Resolution & Customer Guidance

To solve this and prevent recurrence, set up a Digest Report instead of individual row loops:

Turn OFF “For each row in table” in the bot event (this ensures the bot triggers exactly once).
Set the Event Condition to check for data existence:
ISNOTBLANK(Mileage Logs to review for mileage overage[Key]) - This ensures the bot is triggered if the list contains at least one item.
Use <<Start: …>> and <> syntax inside a single Google Doc/Email template to list all overage rows in a single daily digest email.

Thank you for the reply Jose. I do have some issues with this though. The equals is not a starts with conditon and never has been. It has always been compare this value with another value and do they equal 1 = 1 (TRUE) , 1 = NULL (FALSE) , “Qs4ihwef” = “” (FALSE). This has become the standard for our automation runs and is used in a large amount of our scheduled automations. It has changed over the years as one formula works for awhile and then fails in a year due to the app engine no longer recognizing how the formula should work and is expected to work so we get odd automation behavior such as this. Ex. IN([Key], TOP(Slice[Key], 1)) this used to work flawlessly for over a year when we started using it as it was faster and more efficient in runs. One day it stopped working and caused duplicate runs for the same key in the same instance I was told to change my formula as that wasnt the intended behavior. Sure it could be considered improper, but if it works and solves the issue and works for a long time with zero failures in many different apps then that is the know expected behavior and method.

[Jose_Arteaga]

I’m curious, are you using Gemini to evaluate the paragraph?

Let me get back to the engineering team for further clarification and I will get back to you.

[WillowMobileSys]

@Trevwiller

Thank you for the reply Jose. I do have some issues with this though. The equals is not a starts with conditon and never has been. It has always been compare this value with another value and do they equal 1 = 1 (TRUE) , 1 = NULL (FALSE) , “Qs4ihwef” = “” (FALSE).

You are EXACTLY correct! The “=” operator does not and SHOULD NEVER operate as “prefix/starts-with” type operator - ESPECIALLY for a row key!!

If logic was changed to this behavior then it MUST be changed back.

But I think more accurately, someone is WRONGLY assessing the root cause without complete understanding.

@Trevwiller

Ex. IN([Key], TOP(Slice[Key], 1)) this used to work flawlessly for over a year when we started using it as it was faster and more efficient in runs. One day it stopped working and caused duplicate runs for the same key in the same instance I was told to change my formula as that wasnt the intended behavior

Playing devil’s advocate… I’m not sure how this expression above is helpful logically speaking to you?? You can’t order the return from a Slice so you have no control to force a certain desired row to the top in the SLice itself. That implies you might have been relying on a DEFAULT ordering of the rows and shouldn’t really do that - especially if the data source is a database. While sheet based reads tend to retain row ordering, there is never any guarantee of that.

[Trevwiller]

Hello Williow, Thank you for your reply. The IN([Key], TOP(Slice[Key], 1)) was not for choosing the exact top or expecting the top record its more for grabbing any record in the slice so I could proccess it. I didnt care which row came first, but proccess the ones in the bucket one at a time.

[WillowMobileSys]

@Trevwiller

I didnt care which row came first, but proccess the ones in the bucket one at a time.

Ok, I don’t know your implementation. I was just concerned this might not be the most efficient way to process which can run into time out issues depending on number of rows involved and how the rows are processed.

But I also know you have been around a while and probably know what you’re doing!!!

[Steve]

@Jose_Arteaga

In AppSheet, the standard equals operator (=) for Text behaves as a prefix/starts-with check. Checking whether a text string begins with an empty string evaluates to TRUE for every record.

The reply glosses over the complexity of the issue.

Configure data processing - AppSheet Help

[Trevwiller]

Hello Steve,

You have cracked the issue wide open. After reading through the provided documentation I found this. The app is in legacy mode and using the legacy calculation. I will now be diving into all of my application to locate this and confirm we are on consistent. When was this established? It seems the addition of “temp” features are everywhere throughout appsheet. Thank you Steve for the direction on this.

[Steve]

Expressions: New option for faster and more consistent comparisons

Hey everyone! In the coming days, we will enable the option for expressions in apps to use new behavior for comparison operators (=, <>, <, <=, >, >=). This will be an improvement in sync performance and consistency of results. The current behavior will be called the Legacy option and the new behavior will be called the Consistent option. The ability to change an app between Legacy and Consistent will be added under Data > Options > Expressions > Blank value comparison mode. [3X_f_a_fa3232a91…