Summary. What is the recommended best practice for configuring row-level security in an environment having strict need-to-know information barriers which change month by month (for example, I'm allowed to see a row this month but not next month).
Business Requirements. A group of users in the same business unit ("Enforcement Division") requires temporary, constantly changing, need-to-know-only access to a subset of rows (10-15 at a time) within a table of "Incidents" having ~1,000 rows.
For example, in May, user "David" requires access to rows R1 and R2 (and their descendent rows in another table in a "mater-detail" relationship); user "Eve" requires access to rows R2 and R3 (and their descendent rows); and user "Fred" requires access to row R4 (and its descendent row).
In June, user "David" keeps access to row R1, loses access to row R2, and is granted access to row R3. "Eve's" access remains unchanged. "Fred" loses access to row R4 and gains access to row R2 and R5.
Question
Related Online Resources
In researching this topic, I reviewed the following online resources:
Thank you for any guidance!
Solved! Go to Solution.
Hi @Chris1969,
There's no right/wrong and depends, but an approach I would recommend is to configure your security roles for these tables as user-level owned. That way users will only be able to see what is owned by them or their team(s). Then with the help of Power Automate or manual business processes to update the owner when required. The owner of the records can be a team. User can also change team as need be, but would suggest to try to keep the teams as intact as possible and segregate them. Business Units (BUs) might help but not require to achieve that scenario. Especially if users need to move BUs often will create unnecessary complexity.
The other way is with Access Teams as per the previous post or sharing/unsharing the records, but this require one key owner/admin of the record that manages the accesses and might have a performance impact depending on volume of data and users.
Hope this helps!
Hi @Chris1969,
With Access Teams, which provides the unique explicit access per record, it cannot own a record. Owner teams can own a record. If you only intend to control access via Access Teams, then set the Owner as some generic owner team or a service account in the business unit. Ensure that the security role for the users that will be part of an Access Team have just user level privileges on the table.
---
Please click Accept as Solution if my post answered your question. This will help others find solutions to similar questions. If you like my post and/or find it helpful, please consider giving it a Thumbs Up.
Hi @Chris1969,
There's no right/wrong and depends, but an approach I would recommend is to configure your security roles for these tables as user-level owned. That way users will only be able to see what is owned by them or their team(s). Then with the help of Power Automate or manual business processes to update the owner when required. The owner of the records can be a team. User can also change team as need be, but would suggest to try to keep the teams as intact as possible and segregate them. Business Units (BUs) might help but not require to achieve that scenario. Especially if users need to move BUs often will create unnecessary complexity.
The other way is with Access Teams as per the previous post or sharing/unsharing the records, but this require one key owner/admin of the record that manages the accesses and might have a performance impact depending on volume of data and users.
Hope this helps!
@ChrisPiasecki and @EricRegnier , thank you so much for your guidance on this topic -- very helpful !
The first Microsoft-sponsored Power Platform Conference is coming in September. 100+ speakers, 150+ sessions, and what's new and next for Power Platform.
This training provides practical hands-on experience in creating Power Apps solutions in a full-day of instructor-led App creation workshop.
User | Count |
---|---|
15 | |
10 | |
7 | |
4 | |
3 |
User | Count |
---|---|
23 | |
15 | |
14 | |
9 | |
9 |