Here’s a spreadsheet I made calculating what sort of daily user-update quotas you’ll need to keep in mind while developing apps now.

hru · 04-19-2021 11:48 PM

I have just read a document about Platform limits, I really don’t remember reading it before:

Question:

How as an App creator, I can track this EVENT usage?
Is the monthly limits also applicable to the App creator? for example deleting rows, what would happen if the app creator tries to delete rows but events per user license per month quota reached the monthly limits?
For add/update/delete performed by the app, is it count towards each row or for each cell?

Thanks for explanation on this.

Here is the reference.

MultiTech

Sure hope this:

won’t be applied to actions.

Otherwise say goodbye to Looping with Actions.

MultiTech

Here’s a spreadsheet I made calculating what sort of daily user-update quotas you’ll need to keep in mind while developing apps now.

Rafael_ANEIC-PY

Just from the top of my head, this change would just kill:

Looping with actions
Using workflows to refresh values
Bulk actions
Apps that rely on multiple entries of child rows per parent record (inventory and sales apps)
Any app that uses quick edit (especially the ones that have search functions implemented)
My will to live

And that’s without mentioning the 5 pages limit lol

Rifad

Basically Every single APP!

Jeremy_F

With this new update, it means;

Usage of appsheet API is limited - so, no need to use zapier or any external automation tool
Processing of a document is limited to 5 pages - It is more reasonable to limit to a file size
Number of user operations is limited

Case scenario; Suppose a user adds an average of 300 records per month, and edits each record 5 times (actions, quick-edits …), that’s approximately 2,000 operations - Limit reached, and you haven’t even used automations, workflow rules or the API

Martina_Hawkins

Is anyone from Appsheet Team reading all this I wonder. See no replys from them at all !!
We need some explanations asap.

Markus_Malessa

I was wondering the same and was just about to post about this also. I think some clarification needs to be added from somebody at Appsheet.

Austin

We have an app with massive usage. 1 app gets 30+ users on each weekday and I have another app that should get 60+ users every day of the month. Do I need to start taking into consideration what I do in appsheet vs outside? I mean one of my users is over 8000 for the last 30 days. 15 days over 500 and one day with over 1000 interactions. And my largest function isn’t even in appsheet. If I had put that feature in appsheet I would have no doubt that this one user would be well over even the 20,000 limit given that it makes about 60 adds alone along with up to 60 deletes and that’s ignoring any overhead actions I would have to take.

We have another app in our stores that use easily over 15k every month and they aren’t even necessarily using this product to its fullest. They could easily start reaching even that 20,000 limit if they aren’t already hitting over that if these new limits aren’t currently enforced since I don’t think we’ve been notified of these new limits. Unless this is including syncs which they do a ton of so we are a bit lower but even still these users have a handful of other apps that they use in addition to this one. We have almost no users that would be able to continue to use appsheet at anything less than Core/Enterprise Standard

I am very much hoping that some mistake was made on these documents and we’re just blowing up over nothing.

Austin

Everyone should also remember to like the original post to continue to make this the number 1 forum topic since it desperately needs to be seen by everyone that opens the forum.

Markus_Malessa

@Aleksi I know you initially responded to this only yesterday. But under the circumstances some type of response sooner rather than later might be appropriate to maybe put people’s mind at ease or possibly confirm people’s fears.

takuya_miyai

It helps that @Aleksi replied to us first.

I think that getting more frustrated than necessary now will not yield good results.
I trust that AppSheet will update the information to be more correct.
It won’t be too late to communicate with them regarding this Limit after we see what they have to say.

WillowMobileSys

@Takuya_Miyai - Thank you for being a voice of calm and un-biasness. In the end AppSheet is a business too and they need to do what is best for their bottom-line. If they don’t, then there wouldn’t be an AppSheet for all of us to use.

I do disagree about it “won’t be too late”. Based on my past experience in corporations, I believe it is best to voice our concerns now before they make a final decision - if they haven’t already.

Markus_Malessa

I was kind of thinking along the lines of something like this:

https://www.bloomberg.com/news/articles/2021-01-22/microsoft-boosts-price-of-xbox-live-gold-sparking...

takuya_miyai

Yes, I too would like to hear AppSheet’s opinion as soon as possible.
However, I wrote that it is not too late, because realistically, it does not seem like applying hard limits to the existing environment in such an uncertain situation.

I hope our fears will be dispelled soon.

Austin

I would also prefer a well thought out thorough answer rather than a “crap put out this fire quickly” answer. This answer will quiet literally decide the future of whether or not people continue with appsheet or leave as soon as they can.

Aleksi

Yes, I escalated this internally yesterday & today as well, and we are going to give more details for this. I hope later today.

harsh-google

We hear your feedback, and we agree the limits could have been explained in a better way. We are working internally to bring more clarity around limits as most of them only applies to Appsheet Automation and Document Processing . The motive behind is performance and better SLA.

We will get back with more clarity soon.

Stefan_QREW

Is there no way around these limits?

I have a customer who has a single PDF report that has 30+ pages, but saves them something like $60k a year compared to their previous process.

@Harsh_Ch should I prepare them to move off of AppSheet for document generation?!?! - And reinstate their previous process ASAP?

harsh-google

@Stefan_Quartemont this doesn’t apply to PDFs generated as reports. We have a new Intelligent Document Processing functionality as part of Automation. It takes Documents (W2s etc) and that document limit is set to 5 pages due underlying platform. This doesn’t effect existing functionality around PDF generation etc.

The limits are also not enforced to any existing features in Appsheet we have today other than automation. For example the events are purely events configured for Automation feature.

Stefan_QREW

That is very encouraging. Thank you for the clarification.

elco

That’s great to hear but I imagine the action limits affect every “developer” who does not use any document generation or processing? They are simply any update/add/delete operation in the sheet?

The action limits will kill everyone because after you run out of your “limit” this app is kaput!

Literally never heard of an app having a limit on how many times you can press a button per month; this is a whole new level of subscription model

Steve

All of Google apps (Sheets, Docs, etc.) have quotas. You obviously just don’t hit them. It’s not uncommon for some big, complex, heavily-used AppSheet apps to bump into Sheets quotas.

Austin

Very happy to hear especially as from what was visible to me, we were approaching the 20k limit. Is there a place to track that limit by user? I have not seen any place where I could find the breakdown although we have no active processes in the automation tab only workflows.

Austin

Christoph_Bucke

Where do I find updated documentation? Did Appsheet provide guidenance in the meanwhile?

Stefan_QREW

Per Praveen’s comment, these limits should not be as disruptive as they seemed at first. Ie. Rate limits are not something we should not be concerned about at the moment.

Austin

Austin

That at least calms down a small number of concerns throughout this thread.
@Rafael_ANEIC-PY
@Jonathon
@tsuji_koichi
@Sarah_Keown
@1minManager

SantiagoU

Hi all,

Thank you for the feedback. Please give us a couple of hours to clarify some things in that “Platform Limits” document that are causing some misunderstanding. We’ll get back to you shortly.

Santiago

Jeremy_F

It is very logical to set limits to improve performance, but setting a specific limit per month is rather punitive.

For example, the “Google Sheets API has a limit of 500 requests per 100 seconds per project, and 100 requests per 100 seconds per user.” - No daily or monthly limits
When automation/api calls are limited to 2,000 operations per month, Appsheet automation is no-longer unlimited.

My take is that it would be more reasonable if the number of operations were limited per second/minute/hour, and maybe some time-delay i.e If one subscribes to the highest pricing level, he/she can have unlimited automations/API calls/workflow rules per second/minute with no time delay

APiCC_Conor

It is very logical to set limits to improve performance, but setting a specific limit per month is rather punitive.

For example, the “Google Sheets API has a limit of 500 requests per 100 seconds per project, and 100 requests per 100 seconds per user.” - No daily or monthly limits

When automation/api calls are limited to 2,000 operations per month, Appsheet automation is no-longer unlimited.

My take is that it would be more reasonable if the number of operations were limited per second/minute/hour, and maybe some time-delay i.e If one subscribes to the highest pricing level, he/she can have unlimited automations/API calls/workflow rules per second/minute with no time delay

This would absolutely be a better approach to limits…

Austin

Limiting the service on a per second vs per month basis solves different problems. They’re not the same in the least bit and there technically is a limit for googles API its just 2.6m a month per project or 500k a month per user. I don’t think its reasonable to expect even a 10th of Googles performance out of Appsheet. They were bought by Google, they are not Google. The “user operations (e.g. add/update/delete)” is the part that is the most ambiguous. I mean 20k updates can be gone in a week or like tsuji_koichi stated one click if updates count towards the limit. On the other hand if triggering an event and completion of the process is 1 use then it seems like the other plan limits are slightly low cause 20k equates to about 2 events a minute for 40hr weeks or 1 event every 5 minutes on the core plans limit of 2k.

We also don’t know if appsheet has taken a look at how many usage events users have on average right now. Right now users make workflows without hesitation for how often they are gonna fire or how concise they are made. I have 5 workflows that trigger off the exact same event cause I did it by accident while developing too quickly. Would that be 5 uses that I could make 1? Do the usage limits affect the majority of appsheet users? How is it handled if a user hits the limit? Is it an extra charge, do their automations stop, we don’t have any of these answer right now so maybe their should be a special office hours or QA thread about this where we can all ask the questions that affect us. My biggest question is where do I as an admin of my organizations appsheet have the ability to check this in a central location? Where can I monitor my usage to make sure that if we near these limits it does not cause me a massive problem? If we randomly get slapped by some wall, we are rightfully going to be furious. In the document it says I can track the usage in the monitoring section. The only usage stats I can see is individual users on a single app on a bar graph, or how many apps are used by the user and how many users used an app.

^This is a terrible explanation of what a usage event is because a user operation can trigger an automation events and a workflow which each send api calls to make adds and deletes. Give some examples of things people would do in an app and how many usage events that is. My interpretation of user operations is every time I make a change or save a form that would count at least once.

SantiagoU

Hi everyone,

First of all, thank you for the feedback you have provided on this topic. Please be assured that this is an ongoing conversation and we are reviewing both the content of the help docs and the product limits and policies around it. Here are some updates:

We are updating the documentation to bring more clarity on rate limits for the AppSheet platform and overall platform limitations. We will review the rate limits to be on a shorter time frame, as mentioned initially, rate limits are intended to ensure the performance and availability of the platform.
Limits are not enforced to any AppSheet features we have today other than automation.
The page limit for PDF doesn’t affect existing functionality around PDF generation in workflows.
We will post the updated docs soon and will start to socialize plans to usage limits per license on a different help page to make sure we can continue to gather more feedback from the community. Our goal is to have an entitlement that covers at least 99% of the AppSheet use cases we see today.

We will keep you posted on this topic, respond to this thread and continue the conversation.

SantiagoU

Hi everyone,

First, let me apologize for all the angst caused and reflected in this thread. We created a document that caused a lot of misunderstanding and mistrust. Let me try to clarify the intent, explain what is actually changing, and hopefully put everyone’s mind at ease.

The new Automation system is designed to be strictly richer than the old Workflow rules. There are still some feature limitations though, just like every other part of the platform has. These apply to new features that didn’t exist before. We intended to document these limitations (eg: how long can a Wait step wait). The document structure extraction feature also has some unique limitations on page size, etc because it connects with another Google service called Document AI that is both expensive and new. We will soon repost the articles with these limitations, you should find it here in the next few days.
The document alarmed many by mentioning limits on “Documents” — it meant to refer to document extraction via AI (the new feature). Most of you use document generation and there is no change to that capability.
We have a desire to protect the system from surges in use that can overwhelm the service or deny service to others. This will be accomplished through Rate Limits (which are typically limits per account on a short time period — eg: number of updates per minute). All platforms have rate limits for this purpose as does AppSheet, but we have not so far published them explicitly and transparently. There is an ongoing effort to publish transparent rate limits, but we are not yet ready with it yet. It was unintended that Rate Limits were mentioned as part of the document at all. What we can confidently assert is that the rate limits we do publish (soon) will not restrict our current legitimate customers like all of you. They are only meant to avoid intentional or unintentional usage that overwhelms the system.
We have a desire to ensure that plans and licensing are still meaningful as we move beyond end-user facing apps to automation-heavy apps. For example, what does per-user licensing even mean for an app that has no users but only has automation bots? Instead of creating a new measure for licensing and further complicating it, we are going to map automation usage to end-user license entitlements — so N user licenses entitle you to N*X “automation work”. We are selecting these limits generously and based on an analysis of all of our customer traffic – so that the usage entitlements are above the 99th percentile of users. Here again, we can confidently assert that we will not restrict our current legitimate customers like all of you.

Across all of this, it would have helped if we had explained our intent upfront, and made sure the documents were clear. Again, this is our bad! The very last thing we want (or you need) is any disruption or alarm that wastes your time and energy. When you see something that appears dissonant, please consider first that it may be a miscommunication; and that even if not, we are just as open to hearing, listening, and responding as we have always been. We build and run this platform for you.

pravse

The most important thing … “We build and run this platform for you.”

Austin

Just absolutely confirming, this means we have 1 giant pool of actions that everything pulls from?

SantiagoU

Hi Austin,

We are working on the model and will socialize as we get more details and to get more feedback. Our early thinking is on a “pool” but we’ll come back with a more refined definition.

1minManager

My suggestion would be to move to something similar to the Google Maps API that we have linked Sheets to in the past. Whereby you have a free quota level, then you have a paid amount for anything above this. So that the 99% of users are unaffected. But the Appsheet Jedi’s (@MultiTech_Visions @Steve @Aleksi @Bellave_Jayaram @Rafael_ANEIC-PY @tsuji_koichi @WillowMobileSystems etc) can choose to either pay the extra or restructure their Apps to use less quota.

What made me think of this was an error we made when creating the Maps API. Each row had 2 addresses and we setup a Google Script to pull in the LatLong location for each of these 2 adresses. To start with we didn’t notice any problems. Then out of the blue we were hit with a $100ish fine for making 500,000 API calls in a month! The error we had made was to set the script to run every 5mins. So each row was making 17,280 (12 x 24 x 30 x 2) calls per month. What we hadn’t done was to put in a rule so that, unless the address changed, it would not use an API call. Once we added that we haven’t paid a dime since.

Hope this helps, in some way

Suvrutt_Gurjar

Hi @Santiago and all community colleagues,

While I am sure many of us will have their own ideas to share on what is a good absolute number for limits per user, this pool concept of N users will have N*X “automation work”. is in general a good concept.

Most of the app owners have all the users under one account ID. Some of the users in that account ID may only have an employee role and they may use just one app to fill in their own timesheet ( meaning very little usage) . On the other hand, a manager role user may access and approve all employees’ timesheets and he may have access to many more apps.
Bottomline: Even in one account ID, the usage of limits will vary by a large amount. So to optimize usage, the pool concept may be actually a good idea. Underutilized employee role user limits can be used by manager role.

One query is, previous Premium/Pro plans used to have any number of apps allowed per license per month. Request @Santiago to share insights on how this will work in new plan structure.

Grant_Stead

I feel like we should just have transactional cost rates… It’s basically just hitting an API gateway… So, shouldn’t it just follow the same Google cloud limits and costs…