Sending Notifications to all registers app users?

From the help info below, it does not look like there is an easy way to automate sending notifications to “all registered users”. I see we can send to a complete column of email addresses, and manually to all users, but not automatically? Did I miss a way to do this without having to maintain a registered user table?

Wish you could define the TO: as _AllRegisteredUsers.

1 Like

Hi Mike,

Are you asking for a way to do a “Broadcast Notification” from a workflow rule?
Like the “Broadcast Notification” described in this article

If so, I do not know of a way do it today, but it does sound useful.
Maybe someone in the community has a trick I have not thought of.
If not, please add to to the list of new features.
It might not be too hard to implement.

1 Like

Provided you set a a Users table containing all the email addresses of those users, besides the scheduled notifications, you can use that table for many things inside the app. USERS table is the very first things to construct when we develop an app. It helps a lot.


@Phil - yes. I am looking to leverage the broadcast notification capability so I can communicate to ALL my app users, but it seems the notifications require an independent user list and there is no system variable to pull that. Since the Appsheet “manage users” section contains the allowed users, i wanted to avoid having to manage my own user table like @LeventK suggested. I am just lazy I guess and wanted to leverage the existing user management system in Appsheet. Can do it manually, but not automatically…

Might have to start setting up users table myself but wanted to avoid that extra maintenance. :slight_smile:

Giving that extra effort for a table will save you from a lot of troubles and settings inside the app, believe me :slight_smile: Saying this as per experience bud

1 Like

Quick question - what columns do you typically have in your users table, and do you have an automatic way to pull the user emails (or do you manually maintain)?

Levent makes a good point!

Having said that, I still think having the ability to send a Broadcast Notification from a workflow rule makes sense.It would allow you to send either scheduled or event triggered BroadcastNotifications to all users.

1 Like

You might have a right but what happens when you need to notify only a small user subset which might confuse other users if they are totally irrelevant to the notification content? Just shouting out loud.

I generally have 2 or 3 “sections” in my Users table depending on the nature of the app. But I always include an Access Privileges table as ref with the isPartOf property set to TRUE. This allows the app admin to specify how he wants his app users interact with the tables. With a simple LOOKUP(…) expression I set the table access expression:

LOOKUP(USEREMAIL(),"Access Privileges","User Email","TableName")

TableName here refers to the [ColumnName] as I set with the same name of any app table.
In the gSheet structure, I generally have the below columns. I may add extra columns depending on the nature of the app or by client’s request i.e. address, licence (Y/N), licence expiry date etc.


[User ID] - Text, Key
[First Name] - Name
[Last Name] - Name
[Phone] - Callable, Textable, Phone
[Email] - Email


[ID] - Text, Key
[User ID] - Text, Ref > Users, isPartOf: TRUE
[Email] - Email, De-ref [User ID].[Email]
I repeat the same for all tables that I do want to include.

If the users will interact with workflow email and/or scheduled reports, I also add some additional columns with TRUE/FALSE values. For example the client might request that not every user could send a workflow email or only specific people can receive the workflows etc. etc.

This design is totally dynamic as per app specifications set by the client.

In addition to these, we also set a VARIABLES table which we mostly refer within the app whilst setting up the dropdown content. We generally import this table to the app as App Settings so that the user can change the content if needed. And the beauty is, you don’t need to set any VC columns to in each table to revert those values into lists because you can now do that with the combination of SPLIT(…) and INDEX(…) easily.

Phew…Wrote a lot…Sorry :slight_smile:


@LeventK - thanks for sharing all of this👏. It’s a huge help to learn how to approach effective app layout. Saves tons of headaches later. I always set up tables for Help and AppNews by default. In fact, what triggered this conversation was the idea that I want to be able to “broadcast” the titles of the AppsNews to all users.

I will have to read through all your tips on User management tables so I can really understand the implications.

Just another thought - might help a lot of users to add a post in tips and tricks to address fundamental base tables that help manage any app - like users, help, etc. @Peter - adding you in case you are looking for good fundamental tipsAndTricks topics.


In fact there a lot of tricks that can be used and it’s in totally related with how you think and how you approach your design intent. In all of our client apps, we always retain as co-authors by nature. So as superusers we can reach everything easily. For example:

Client requests an addition/change or an additional feature. Though we might have a quite good time because of the time gap with the client (generally), the users shall be sleeping whilst we are working with the app build :slight_smile: Well at least we expect it to be like that. So; somehow we should not clash with the app user(s) or we humbly don’t want the users to interact with the app whilst we are editing the structure. So we thought on “HOW?” a bit and came up with a solution where we developed a MAINTENANCE MODE :slight_smile:

This is actually a record in that VARIABLES table with a simple Y/N value. In addition to that, we build a simple table with 2 columns, 2 rows (including the header) and import this table to the app as READ_ONLY and set a UX view as:

Type: Detail
Mode: Ref
Main Image: Column1
Column Order: Column2

The main image is a simple wrench image or any similar, and Column2 is a Long Text field with a simple message i.e. “Your app is under maintenance. Please try later”*

We simply set/append an expression for the Initial View property too which is something like below:


and hide any other app views as well if the MAINTENANCE toggle is ON.

I believe I have flooded the topic :-))))))))))))


@LeventK - That’s super awesome! I am always amazed what human imagination + great tools can do. I love this idea and really appreciated your willingness to share so openly.

These kinds of examples make you realize (1) many of us are in a very early stage of learning, and (2) some of “us” (like you) have discovered really imaginative ways to leverage this platform. (like your inbox message approach).

Again… thanks for leading, sharing, and opening up the possibilities :slight_smile:

Hello @Mike,
As you are very keen about “interesting” examples/design approaches that might power up an AppSheet app, I have newly added a new topic post under Tips&Tricks section about how to create an automated backup utility to any AppSheet app. If you are interested and haven’t noticed it yet, here is the post URL for your ease of information:


@LeventK - I just noticed that and am very interested. The combination of Appsheet and GAS makes a powerful combination. I will have to read through your approach. Thanks for so openly sharing!

We still have to rely on the backend services being alive (eg: google and Appsheet), but this approach helps with the other elements like images and documents. Will be interesting to see how you handled restores… again, thanks for sharing and making the community stronger!

I haven’t integrated any kinda “restoring” code to that because restoring backup data is completely another messy thing, and hence the backed-up gSheet will not be in the app as a table, showing/displaying the backup data in a form view or letting the user to choose a restore dataset is a bit tricky job to do actually.

1 Like

@LeventK - LOL. thats why I asked. It’s a bit complicated to deal with restore without taking a lot of risk. The backup is a the key part anyway. One thing I feel is, when trying to keep the appsheet front end in-sync with a google scripted back end, documentation becomes a critical issue or there is a lot of chance to break things. I have started adding entity diagrams and schemas into by gsheets, but am concerned that may actually start to effect performance (as the sheet size grows).

Do you document in the same sheet that drives the app, or another sheet? Since you have suggested “importing” the variables sheet and the and now the backup configuration, should I assume you keep something separate?

@Mike - We had developed an app - we call it AGILE App, taking the name from AGILE Project Management techniques for IT projects - where we document our app development process for all our apps. However it’s a bit time consuming work and it’s not so realistic to accomplish both the app development and the documenting. Most of the time we are in a mood of “how the hell we had done that:slight_smile: and it’s relatively not 100% possible to log everything you have done with an app unless you don’t have someone just for doing this job. We are 3 partners and our hands are always in dirt so honestly we can only log down may be %70 of what we have done.

For the general app development, we do have an empty template app which holds the major features that we had developed so far. Provided it’s not required to continue with the client’s app and a start from scratch is needed, or client’s had built poorly that starting from scratch is relatively easier than fixing/updating the existing one, we just take a copy of this app and build everything upon this app. It saves a lot of time actually because you don’t need to rebuild everything again and again.


So you guys are like the rest of us after all!! :smiley:

1 Like

The only Alien amongst us is definitely and solely @Aleksi :smile::smile::smile: