We’re making this change because some teams were having deliverability issues with large email sends (e.g. tens of thousands of emails per month).
With this change, teams can send as many emails as they want.
We are also changing the Gmail and Outlook integrations to count updates in the same way.
Sending emails with the Gmail and Outlook integrations will only use 1 update per run instead of 1 update per recipient.
We’ll be contacting primary admins of teams that have used the Send Email action in the last 30 days.
The primary admin of a team is usually the person who created the team. They will receive an email that includes affected app names and the number of emails sent.
If you do not wish to use updates for sending emails, you must remove the Send Email action from running in your apps by September 16th, 2024.
If you have any questions or feedback, please let us know in this thread.
Will there be an increase in update quotas per plan to go along with this change? This is a huge curve ball. Wouldn’t it be a gentler solution to place a separate quota on the send email action instead?
I agree with @Sekayi_Liburd that this is quite a drastic change, especially with those of us building apps on a free plan. The “Send Email” action was the only way to notify users outside of the app, and now we aren’t able to do that.
Validated that you will get an error. We will make it so that you cannot add this action if you are on the Free plan to make this clearer that the Send Email action cannot be used on the Free plan
Another bad move especially for those on the maker plan. “Build an App for your community or school” with unlimited users - but you only have 500 updates which means you can only send 500 emails. Its very difficult to keep up with Glide especially if you are not on an enterprise plan or are in a developing country.
It’s actually not that bad. It’s 1 update per run. Not per recipient. That’s a huge bonus. P.s you can always buy additional updates for just $0.02 per update.
you realize that it consumed no updates (0) before, right? So this change - which will soon consume updates - is not a bonus
$0.02 > $0
Now imagine a free community app that reaches hundreds of thousands of users.
I would think that if you have this type of app that reaches that many users, you should be able to handle that amount of updates. Hundreds of thousands is a lot and I don’t think we have many apps like that around here.
I guess you missed the “free” part, lol. My aim (as in future goal) is really to the have the app be as free as possible for the citizens in my country. To handle that many updates, it would have to be a paid app for sure. I was under the impression that Glide encouraged non-profits and community apps with the maker plan.
I guess what I mean is the Maker plan allows you to have a community app, but under restrictions in terms of users (all of them have to use personal emails, which many people here have only found out when they test their app), and updates.
So, if you aim to have that big of an app, it would come at a big cost to Glide to “host” it, and they have to put restrictions in place to not host it at a loss.
I used to work on some community apps when I started with Glide, but probably in the last 2 years, I pivot to mostly internal apps, which is what I think their main focus is.
We pay for the service and make apps according to what Glide provides. All I am suggesting is a gentler way of making the changes like the one this topic describes. In any business there is loss of trust when changes drastically change the current system or seem to disregard the impact on the client.
yes, I spared no time after the announcement - especially since Glide officials haven’t been participating in this thread. I revised my app and constructed workarounds a few weeks ago. Thanks @Eric_Penn
