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.

Solved Solved
1 18 3,352
1 ACCEPTED SOLUTION

@Phil
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.

@Mike
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.


[USERS TABLE]


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


[ACCESS PRIVILEGES TABLE]


[ID] - Text, Key
[User ID] - Text, Ref > Users, isPartOf: TRUE
[Email] - Email, De-ref [User ID].[Email]
[Table1] - ENUM, Type: text, Valid_if: {“READ_ONLY”, “ADDS_ONLY”, “UPDATES_ONLY”, “DELETES_ONLY”, “ADDS_AND_UPDATES”, “ADDS_AND_DELETES”, “UPDATES_AND_DELETES”, “ALL_CHANGES”}
[Table2] - ENUM, Type: text, Valid_if: {“READ_ONLY”, “ADDS_ONLY”, “UPDATES_ONLY”, “DELETES_ONLY”, “ADDS_AND_UPDATES”, “ADDS_AND_DELETES”, “UPDATES_AND_DELETES”, “ALL_CHANGES”}
.
.
.
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

View solution in original post

18 REPLIES 18
Top Labels in this Space