Recommend a Security Model

Brass Contributor


Here is the scenario I'm trying to decide what would be the best security model for:


We have about 300 customers. Every customer is managed and contacted by a different group of employees from our company, i.e., customer A is managed by employees l, m & n, and customer B is managed by employees x,y,z.

I want to create a SharePoint team-site for every customer, with the managing employees being the members of this site.

But I also want to have a common central list in SharePoint, where every customer is a record in that list, so I can specify some metadata for every customer in different columns in that list.

Executives in the company need to be able to see all the customers/records in this list, but regular employees should be able to see only customers/records that they manage.

This should be implemented as a security requirement (permissions), not as a visibility requirement (i.e., not just create filtered views, but to actually prevent access to other customers records).

Every customer is managed by more than one employee, so I can't use the out-of-the-box Read/Edit item-level permissions for allowing access only to item that were created by the user.


I read a lot about breaking inheritance, or item-level permissions, not being a best practice and should be avoided, but I can't think of another solution for this rather (in my opinion) common and basic scenario.


How would you go about and achieve these requirements?

Thanks for your time,


3 Replies
So I've had similar requirement and my tip is to make an powerapp and Embedd it to a site, so that the users can access it. This Powerapps uses a SharePoint list with the different clients and that list is tagged who can see what. So instead of breaking permissions, you just have the Powerapps filtering the permission. As managing broken permissions will be a headache

@NicolasKheirallah, thanks for your response.

As I mentioned in my post, I need item visibility based on true permissions and not on filtering. The solution you proposed will allow employees to access data they shouldn't see, whether from the list itself or from whatever app they can build for themselves, and just add this list as a data Source.



As stated, You can always break the permission, but that is going to be an headache to manage as it grows. It's not a viable option unfortunately in the long run.

But if you still want to do it, just have a flow trigger on the list item that breaks the permission on the item and adds users when a new item is created, and then have another list or the site as a ref for each client and their members.