Managers set to read only

I’m guessing this has been answered a few times, but I can’t find exactly what I am looking for.

I have a table, “Manager”. On that table are the First Name, Last Name, and email address of managers.
I have several tables that have security filters on them so that only the person who they belong to, can view them, edit them, add or delete. They are their records, and they can do what they want with them. However, I DO want the managers to be able to view (read only) the records as well.

something like USEREMAIL(), “manager”, [email address]? I just can’t get that to work. pardon my computer French. :slight_smile:

I believe your security filters for all tables except Manager table can be

OR([Email 1]=USEREMAIL() , IN(USEREMAIL(), Managers[Email M]))

The above will ensure all the records reach the devices or owner of the record denoted by [Email 1] of that table and managers having their emails listed in [Email M] column of the Managers table.

As for read only, I believe ,you may have the following expression in Add, Edit . Delete system actions’ condition setting of those tables. The expression will prevent other than the record owner from seeing those actions and as a result edit, add or delete records.
[Email 1]=USEREMAIL()

Please do test well as per your requirements because these are important expressions, especially those for security filters.


So, let me make sure I understand, because what I did, did not work.

To me, this looks like there is a table set up with all users on it.
Normal people have their email address in column, Email 1.
Managers have their email addresses in column, Email M
Is that correct?
It keeps telling me that it can not find column [email 1], do you mean email. It’s not looking at the correct table, which I have named, users.

Table Name… Users.
Columns … First Name, Last Name, Email 1, Email
I am entering the information in the filter area of the security settings for that table. Each table doesn’t have to have those columns, do they?

Thank you soooooo much!!!


Thank you for the update. Yes, the email columns names were suggested names. Presume you have substituted them with actual column and table names you have.

The add update modify read only buttons on the table definition has the ability to be dynamic…

So you should be able to adjust that with a Switch expression accordingly… Vice show/hide on the system actions themselves.

Hi @Grant_Stead,

Thank you. I will seek your guidance on the following.

I initially thought of suggesting that approach. But I believe that option may not apply to the case @dan_R has mentioned.

As per my understanding, the add update modify read-only approach will set the permissions globally at the table level based on user emails. So for managers email , for a table, this approach may allow either all records to be editable or all records to be “read-only”.

So if all records are editable for managers, the requirement is managers to have only "read-only’ access to the records of others.

If records are read-only for managers, they may not be able to edit their own records.

I am surely missing some point. I will request your insights.


You’re correct.

1 Like

Thank you Grant.

1 Like

Actually, I think you hit the nail on the head.
The manager in this case, won’t have their own records and I don’t want them to be able to manipulate the records of the drivers. They are to view them only.
This is one area I’m still struggling to make work right. All else seems to be doing great.

Hi @dan_R,

Thank you with your update. If your managers do not have any record of their own, then in that case, the approach suggested by @Grant_Stead will also work. My suggested approach will also work.

My suggested approach will work in either case if managers do have or do not have their own records.

Grant’s suggested approach will work if managers do not have their own records.

Yes, the access-related aspects are a bit crucial to understand. I believe it is a very well-designed system by AppSheet team. It is just that there are multiple record, table, app-level access permission scenarios in real world that we need to find the right combination for configuration.