User Table Ownership

[DarrenMcGINOV8]

Hi,

I have been trying to develop a Model-Driven app that our employees can use to update their personal details.  I wanted to allow each user to update their own details in the 'User' table but because of the ownership type of the table, I can't set the 'Write' permission level to 'User', it needs to be 'Business Unit' or above.  This is an issue as this means anyone else in that business unit can update another employee's details.

Is there a way that I can amend this to allow each user to edit their own record in the 'User' table but not anyone else's (Unless they are a manager etc but I can handle that)?

Thanks,

Darren

[LinnZawWin]

What OOB table did you use so that it only allows None or 'Business Unit' or above permission? (and doesn't allow you to set the 'Write' permission level to 'User')

For the custom tables, the permission can be

- None/Organisation (for Organization-owned tables) or

- None, User, BU, PBU, Org (for User/Team-owned tables)

depending on the ownership type of the table.

[DarrenMcGINOV8]

Hi Linn,

The table I am using is the 'User' table, schema name is 'systemuser', the OOB table that all lookup columns for users are linked to.  It is the one that made most sense to use to provide the most information to everyone. 

It just doesn't seem to let me set the permission level to 'User', just jumps straight to 'Business Unit'.

Thanks,

Darren

[rfainter123]

Hi Darren,

Yes, it is true that the User table security cannot be controlled at the Write level by the User setting. As a workaround, you could potentially use either:

1) Make a canvas app interface that can manage the row level security you are looking for, i.e. ingest data from the User dataverse table to view if their login matches the Owner of the record, then use a patch to update the dataverse User record.

2) Create another table that is identical to the User table with a relationship to the User table and have your users update that table, then use a Power Automate flow or a Dataverse process/workflow to update the User record.

Let me know if you have questions, or mark as solution if one of these works!

[LinnZawWin · Accepted solution]

@DarrenMcGINOV8 

I guess there might be some logic behind the scene that we are not aware of caused these kinds of limitations.

You will just have to use the workaround solutions (provided by @rfainter123) if you are going to use the OOB User table for that purpose. Another workaround solution that I propose would be 

3) Write a JavaScript on the User form and disable all fields if the user does not have a specific role (System Admin, User Admin, Manager, etc.) and the record is not the same as the current user. You can also implement your other custom logic in JavaScript (e.g. enable the fields if the user has a Manager role and the current logged in user is the manager of the opened User record)

4) If the restriction is business-critical (i.e. you cannot let the users overwrite the JavaScript validation somehow and update the data intentionally), you might have to implement the same validation in the plugin (in case if they know how to use browser tools like Level up or disabling the scripts of the forms)

[DarrenMcGINOV8]

Thanks for the responses to this everyone.  I have went down the route of creating a custom table for the fields we want people to be able to update themselves.

I do think this is a bit of a strange decision on MSFT part, surely each user should be able to maintain their own address, phone numbers, emails etc? I understand there are other fields in there that maybe they shouldn't be able to edit themselves, but that could be covered by column security profiles I believe.

Thanks,

Darren

[rfainter123]

@DarrenMcGINOV8 yes, agreed, as you pointed out it is probably to prevent users from editing other more sensitive fields. In your use case, you probably could do a workaround using column security profiles that you configure, but you'd have to place it on all fields to avoid other users being able to update. I imagine that would get cumbersome and probably be just as much work as creating a custom table.