Which is the best way to extend user/account entity?

Recently I’ve seen in a learning path that it creates an entity then a relation (1-1) between this entity and Account entity. In a project that I made in mendix I created an entity and made a generalization of User. So which scenario is the best to extend entity that Mendix uses to log in/out? Lets imagine that I wand to add some more fields such as phone number or address to the user that creates an account. So far I see these possibilities: Just to remind, Administration.Account entity is a generalization of System.user entity. Either I make my new entity a generalization of Account or User (in this case, which one should I choose and why?) Either I make a one-to-one relation to Account or User ( which one should I use and why?)  Maybe Mendix creates a one-to-one relation when creating a generalization entity so both approaches would be okay?   Thanks in advance.  
2 answers

As mentioned by Jermaine it is not recommended to modify the Administration module (Account entity for example) because your changes might be overridden when you update the module. And that applies to all App Store modules.

Having that said, you are now left with the options you present above:

  1. Creating a specialization of the entity User or Account.
  2. Creating an entity that is linked to User or Account through a 1-1 association.


To answer the “Account or User entity?” question: I have found that it is recommended to extend the Account entity instead of the User entity because some App Store modules (and reusable modules from other projects that you work on) might rely on the Account entity (and the administration module) which means that you will have to modify them every time you add or import one to your project that extends User directly. It will also enable you to make use of the pages and microflows included in the Administration module without having to modify much; however, I did not try to extend user directly before, therefore I cannot tell you much about the consequences of going down that path.

You need to answer 2 simple questions before you can decide which approach is better to extend the account entity, and those are:

  1. Are the attributes that you are trying to add closely related to the user accounts?
  2. Do you need those attribute for every user account in your system?

If the answer to both questions is “Yes”, then the best approach from my experience is to create a specialization from Account which will include your additional attributes; however, if the answer to either of the two questions is “No”, then the best approach from my experience is to create a specialization from Account first (because you might want to add attributes that answer “Yes” to both of the questions above in the future) and to then create another entity that relates to that new specialization entity through a 1-1 association, and that entity should be the one including your new attributes. Because those attributes are either:

  1. Not closely related to the user accounts which makes them more of “profile”, or “employee details” attributes, therefore they should be added to a “Profile” or “EmployeeDetails” entity that relates through a 1-1 association to the specialization of Account.
  2. Or if the answer to the second question is no then you might want to isolate those attributes in a different entity (that relates through a 1-1 association to the specialization of Account) in order to avoid creating them for user accounts that don’t really need them.


You might want to consider additional approaches depending on the specifics of your requirements. You can, for example, create two different entities that are specializations of Account, because you have two completely different groups of user accounts where no account could switch from one group to the other, and where the attributes required for each group is completely different. And so on.

NOTE: I did not clearly get your question in point #3, so please reply to this answer if what I’ve mentioned above does not address all your concerns; however, if you mean to say that you want to create an entity that is a specialization of Account and then to link that entity to Account through an association then that is a BIG “NO”. I’ve heard of projects where the developers have done something similar and in my opinion, it is a huge mistake.



Having gone through some of the learnings, I believe they will state that the one best practice involves making an entity and then a generalization of Account. 

Now personally I would do it the same way. For security reasons (no direct access to account entity or associations) and because Administration is considered an “App Store module” in Mendix. 

Updating modules*
For updating modules you usually overwrite the old one and you will lose your changes. Now I have not had a case with Administration in the past. To me Administration is like a “java library item”  and usually you do not edit libraries unless absolutely necessary (knowing that updating it will lose your changes).