Authorization is based on user-role. That means you don’t need a specialization per user-role but can simply create an account per user and grant it either ‘User’ or ‘SuperUser’ roles.
Often you will see a project where there is also an ‘Employee’ entity that has a one-to-one reference to the account entity. Data can be referenced to this Employee object.
Hi Acar, despite Lennart’s answer being totally correct, here is another piece of good of advice:
Remove module Adminstration, as it is based on a faulty domain model. You should have an entity like Empoyee and associate is to System.User. Unfortunately Mendix only allows a many-to-one Employee-to-.User association, so many-to-one it will be.
Now things are getting interesting. So instead of Administration.Account, I should use System.User?
My current domain model looks like this:
What will be the difference after changing to System.User?
Is the faulty domain model fixed in mendix 10?
But what about the Administration.Account_Overview Page. Should I also avoid using it and making one by my own?
And what about SSO Login. Does it work without the the Admin Pack?