Forum Discussion
Sharepoint view level permissions
Hello, I’m facing an issue in SharePoint. I have a main list where I need to create two views
one for “A” users and another for “B” users. What should change is, for example, that “A” users can only see column “A” and “B” users can only see column “B”.
And being sensitive data, they shouldn't be able see each other's columns.
Using different lists is the only viable way I currently see this working, which i don't really want since this requires a lot more of work, unless someone can suggest a better solution.
Note that currently I'm using two different pages inside the same website for user's "A" and "B".
Thank you very much.
1 Reply
Unfortunately, SharePoint views alone won’t give you true column‑level security.
- Views can hide columns, but they don’t prevent access.
- If a user has permission to the list, they can still see all columns
- So, views are a usability filter, not a security boundary.
I could suggest 3 options for your SharePoint use case:
1) Create separate lists based on your use case:
- One list for users who should have A‑type security (only see column A).
- Another list for users who should have B‑type security (only see column B).
- This way, sensitive data is physically separated, and you don’t risk exposing hidden columns through views or exports.
2) Item‑Level Permissions - Works well if the requirement is “users should only see their own records.”
If your use case is more about item ownership (not column‑level security):- You can configure the list so that A users only see items they created, and B users only see their own items.
- This is achievable with item‑level permissions in SharePoint list settings:
- Go to List Settings > Advanced Settings > Item‑level Permissions.
- Choose “Read items that were created by the user” and “Edit items that were created by the user.”
3) Power Apps Custom Form
- Keep one list but replace the default form with a Power Apps form.
- In the form, show/hide fields depending on whether the user is in group A or B.
- This hides sensitive columns in the UI, but note: the raw list data is still accessible if someone queries it directly.
- Good for user experience, not strict compliance
“If my post solved your issue, please mark it as Solution and give it a Like.”
