cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
Lewis_Baybutt
Helper I
Helper I

How to give basic users access to data based on choice column value or only allow users access to specific views

I have a scenario where a group of tutors need to be able to request students/tutoring jobs who have a stage (choice) column which is set to 'awaiting tutor'. all users need to be able to see student records at this stage but need to either be able to make some sort of request for that record or input their name into the tutor requesting systemuser lookup without being able to edit other columns.

 

How can I give basic users access to only their student records but also student records without a tutor/that they can request.... without giving them access to the entire table of records?

 

Is this a possible scenario?

 

I can make the different views however I don't believe it is possible to restrict views based on role or security? Is there a way around?

17 REPLIES 17
dpoggemann
Super User
Super User

Hi @Lewis_Baybutt,

 

Looking at your requirements here I would probably do a couple things as an approach.

  1. First of all I would create an Access Team Template and assign the Tutors to the records that they are tutoring with specific permissions.  This will allow you to actually have multiple tutors to the student if needed by adding multiple tutors to the Access team on the student.  https://docs.microsoft.com/en-us/power-platform/admin/manage-teams
  2. Student Tutor - You might want to create a Table for this and then utilize it instead of having the field on the Student itself for the Tutor.  The reason I say this is it would better support the ability to have multiple tutors assigned to the student and the Tutor be assigned to multiple Students.  You can add fields on to this table like Start Date, End Date, Subject, etc. and have the status identify if the Tutor request was approved.  
    dpoggemann_0-1624377593935.png

     

  3. The next thing I would do is that when someone "Accepts" the request for the Student and Tutor combination (could be a flow with approvals...) or just changing the status reason to "Approved" on the Student Tutor record, then it could create the Access Team record in Workflow or Power Automate Flow and assign to the Student.  This would give the Tutor the access you set to the template on the student record.

 

Hope this helps.  Please accept if answers your question or Like if helps in some way.

 

Thanks,


Drew

Hope this helps. Please accept if answers your question or Like if helps in any way.

I think Queues might also be a good solution here. While a Student is unassigned to a teacher, assign them to a queue team, and give all teachers access to that queue team (where all teachers have adequate privs), then in your queue settings, do not show items that have been picked from the queue. Now teachers can see their own students and they can see all students in the queue. Once they pick a student from the queue, it gets reassigned to them and it disappears from the queue, so no other teachers can see it.

Lewis_Baybutt
Helper I
Helper I

Thank you both for these suggestions. I'm new to using Dataverse so the many-to-many relationship I believe it is you're suggesting Drew is slightly confusing, but I will definitely look into all of these options and post how I get on. Thank you both! 

dpoggemann
Super User
Super User

Hi @Lewis_Baybutt ,

 

I am actually suggesting not to setup the Many to Many because if you create your own table and setup 1:N relationships with that you can have additional fields for dates etc.  You can setup N:N and that is fine but to me you lose a lot of functionality / flexibility with that.

 

Thanks!

Drew

Hope this helps. Please accept if answers your question or Like if helps in any way.

Yeah, what @dpoggemann is talking about is commonly called a "manual many to many" or a "manual intersect entity" The idea is that you are creating an N:N relationship essentially the same way that Dataverse does in the background, but by doing it yourself you keep control of the intersect entity, which allows you to track metadata about the relationship itself such as valid date ranges, etc.

This is an extremely common approach because that metadata (and history, when the linkages change over time) is often very important data that customers don't want to lose. It does come with some UI complexity for users, but there are lots of workarounds for that, just depends on your use case specifics.

 

Edit:

The most common workaround is just to make the target entity lookup the first column in the subgrid displayed on each side of the N:N so when people naturally click that name they go right to the record they are expecting instead of to the intersect record, but another approach I've seen is to use a PCF to replace the subgrid with one that bypasses the link entity straight for the target and then automate the metadata fulfillment.

Lewis_Baybutt
Helper I
Helper I

Hi Both - Thank you again for this. So is what you're saying that by doing this I can have tutors have multiple students and students have multiple tutors if need be. Then the record that would get created between them could potentially act as a 'case record' with information about that tutoring case so if the student ever came back and was paired again with a tutor it would create another record to pair them being another case? (if I wanted to leverage that way?)

 

I'm not completely sure how to do this but i'm sure i'll figure it out. Thanks for your help!

That's exactly correct.

Lewis_Baybutt
Helper I
Helper I

Hello again,

 

I have set up my data structure in a way so that I have a case table. Then a many to many relationship between case and students and another many to many relationship between users/tutors. So that I can have many students and tutors to a case but many cases per student or tutor as well. 

I am now working on permissions. If I enable auto created access teams for the case table, will any related records i.e. student or tutor (systemuser) inherit the permissions? Or do things get more complicated there?

dpoggemann
Super User
Super User

Hi @Lewis_Baybutt ,

 

Can you help me understand the purpose of the Case table?  You have added a lot of complexity here with multiple N:N relationships and I want to make sure I understand the reasoning to hopefully simplify for you if possible. 

 

There is no inherit on the other tables around the Access Teams.  If you need the tutor to be able to modify the Student then you would need to add this to the Student as an Access Team.  


Another thing to think about is if you are having the Tutor modify things related to the Student and you could have multiple of these happening at one time (with multiple tutors to the student) then would it be possible to move these fields to the Student Tutor record instead of the Student and those fields would be part of this relationship.  Not sure if that is possible but just a thought.  This way you could setup the Tutor as the owner of the Student Tutor records and not even need to do Access Teams on the Student since the fields would be on the Student Tutor table...

 

Thanks,

 

Drew

Hope this helps. Please accept if answers your question or Like if helps in any way.

Helpful resources

Announcements
UG GA Amplification 768x460.png

Launching new user group features

Learn how to create your own user groups today!

Community Connections 768x460.jpg

Community & How To Videos

Check out the new Power Platform Community Connections gallery!

M365 768x460.jpg

Microsoft 365 Collaboration Conference | December 7–9, 2021

Join us, in-person, December 7–9 in Las Vegas, for the largest gathering of the Microsoft community in the world.

Users online (1,259)