►Q◄ use built-in Access Levels, or make your own?

[Jaymer]

Here's why I ask.

Lets say I have this hierarchy OF ACCESS LEVELS at a company:
Developer (thats me. this is a multi-tenant app. this user can see/do all)
Admin (create any user, any level)
Regional Manager (same, see's only level of his and below)
Office Manager (same)
Sales (no create, level is display only)
Staff (same)
Reception (same)

Those are in order of ability to see/edit/run reports/etc.
An Office manager should be able to edit a user - and the only available access levels available should be at his level and lower.
* A salesrep sees his access level, and can't change it. Only Managers can change someone's level
* An office manager should be able to see all users, and edit access levels. But should only be able to change someone to his level or below him.

INITIAL PROBLEM
... was that using the built-in access levels, there's no hierarchy built in. So aside from hardcoding rules, I don't know which levels are "below" the current users levels.
... which meant that using the Access Level COMBO BOX, any user would see all levels available in the system. They could change to Admin, but then a rule has to kick in and tell them they cannot really change to admin.

MY SOLUTION
... was to use the option "Choices are determined at runtime"
and to make a separate table of levels like this:

Developer_0
Admin_1
Regional Manager_2
Office Manager_3
Sales_4
Staff_5
Reception_6

and when I display a pick list, a custom query only shows levels at the user's level or higher.

Also, this method allows you to type anything into the field that you want, so a rule has to make sure you didn't alter anything.

Screen Shot 2018-08-29 at 3.42.54 PM.png (13.78 KiB) Viewed 2631 times

So I'm wondering if others have had to make alternatives to built-in Access Levels, or is the supplied Aware-way sufficient for your applications?
thx, jaymer...

[JonP]

I probably should have done what you did, but I wanted to give my customers even more fine-grained control. I kept AccessLevel for determining User/Admin privileges (admins can purchase/assign licenses and invite users) and then added a table called Role which has a name attribute (i.e. Sales, Developer, etc.) and combo-boxes for what level access (somewhat based on RACI) that role allows for each area of the system. Then an admin can assign a license and a role to a user. Probably overkill for most people.