We announced AppSheet in Gmail’s dynamic emails GA a few months ago and we’ve received great feedback from the community since then. Based on all the feedback, I’m excited to announce several new changes for Dynamic Emails that we will be rolling out over the next few days (some have been rolled out already):
Cross-domain support: Many of you have asked for this feature and we’re finally adding in support for sending dynamic emails to recipients outside of your domain. Please see the Cross-domain section below for caveats.
Users with public domains (e.g: @gmail.com) can now use the dynamic emailsfeature.
Ref column support: You can now add editable Ref columns in your dynamic emails.
EnumList/Enum with base type Ref support: EnumList/Enum column types in dynamic emails also support. Note: If you use Valid_if to populate an EnumList, the Valid_If will not be evaluated upon save.
Smart Redraw: Editable_If, Show_if, Labels, and Values will automatically update without having to refresh the dynamic email. Note: There are some cases in which we cannot update parts of the email and in this case we will show a warning banner at the top to prompt the user to refresh.
Formatting Rules: Initial support for formatting rules (currently only available for action buttons).
Require_If support for Data Change actions: When you update a dynamic email using a data change action, we will now evaluate Require_If expressions for all editable fields.
Cross-Domain Email Quota
Dynamic Emails that are sent to recipients outside the app creator’s domain are called Cross-Domain Dynamic Emails. This domain is based on the default email connected to your account.
Every app creator will be given a quota of 50 cross-domain dynamic emails per day. If you reach this quota, dynamic email tasks will no longer send emails outside of the app creator’s domain, but will continue sending emails to users within your domain.
For app creators with public domains (e.g: gmail.com), once the daily quota is met, you will no longer be able to send dynamic emails at all until the next day when the quota resets. This is because all dynamic emails originating from an app creator using a public domain are considered cross-domain.
If you wish to request an increase for your daily dynamic email quota, please contact our support team through the support form with the following information:
Short description of your use case
How many cross-domain Dynamic Emails will you be sending per day? (An estimate is fine)
How many different domains will you be sending Dynamic Emails to? Please list them out.
Sample App
We’ve updated the Task Manager app to showcase all the new features that are now available. Simply add a task using the “New Task” button at the bottom and you will receive a dynamic email in your inbox where you can perform update actions (with formatting rules applied) or connect a task with a project:
For all other information, you can visit the Sending dynamic email from a bot article for instructions on how to set up a dynamic email task and for a full list of limitations.
As always, please feel free to reach out to me directly or reply to this thread with any comments.
Can you explain the difference between how users where able to use Dynamic Emails before and after this post? I misunderstood that we could use it even if we don’t use Google Services for email and it seems like it’s not posible at all from your last comment
Before this post, Dynamic Emails could only be sent to recipientswithin the app creator’s domain. After this post, Dynamic Emails can now be sent to recipients outside to the app creator’s domain as well. In both cases, the recipient must be viewing the Dynamic Email in a Google Gmail client to see the dynamic app view.
The limitation for recipients who view the Dynamic Email in non-Gmail clients remains unchanged. If the recipient opens a Dynamic Email in a client like Outlook, they will not see the Dynamic content but a static email instead.
Could a recepient be someone who is not a user of the app?
For instance, im sending a dynamic email to a visitor expected to arrive to the company and he fills a form in the email. He won’t be using this more than once.
Well, there are google services and api’s that have a quota and you can also be charged for exceeding those services. Why not apply same rule here. At the end of the day/month you are charged per usage rather than per user.
As for forms, well, a dynamic email looks much better than a form and has more features as well.
Can you re-consider to remove limit for 50 quote per creator for enterprise lisense users? We are on enterprise plan, but we dont have much of benefit by riding on highest tier, as we are only given the same limit as core plans, which is not financially making sense.
)