Platform Limits

This specific limit is for the new document processing feature not for generating documents.

3 Likes

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

9 Likes

Hi Matt!

We’ll be posting a more detailed response in the next few hours but just to clarify in your specific question. Syncing the app is not counted towards usage events. “Usage events are any automation events, workflow rules, api calls, and user operations (e.g. add/update/delete) performed by the app”

3 Likes

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 :thinking:

9 Likes

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…

4 Likes

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.

5 Likes

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:

  1. 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.

  2. Limits are not enforced to any AppSheet features we have today other than automation.

  3. The page limit for PDF doesn’t affect existing functionality around PDF generation in workflows.

  4. 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.

13 Likes

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

16 Likes

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

10 Likes

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 :exploding_head:

1 Like

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.

4 Likes

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

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.

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

5 Likes

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…

4 Likes

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.

2 Likes

As you can see, this is an interesting topic. I will reinforce something Santiago said — we are identifying generous usage limits based on actual usage statistics so that it is not something 99%+ of our customers need to be concerned about nor any our current customers like all of you with legitimate use cases.

We continue to have unlimited apps in the Premium/Pro plans just as we did before. There is no cause for alarm. This will be a clarification of the current model, not any kind of fundamental change. In the low probabaility event there turns out to be a problem with one of your, we’ll discuss it and learn how to adjust around it.

So please do not be thinking about restructuring your apps or any such. Enjoy the weekend and we’ll try to create less drama next week :]

13 Likes

Thank you @praveen for the guidance.

1 Like

Ha, ha what do you expect when Google becomes involved. You just have you suck it up. Who owns rules!

However, the costly fee for accessing data sources has been removed and this too was unannounced. I am not sure whether those who were paying realize they no longer have to incur such costs.

1 Like

:slight_smile:

2 Likes