How does Dataverse distinguish between users and contacts?

[MJWhite]

When an authenticated user is registered in Power Pages, a record is created in the Contacts table.  This prompts a number of questions for me:

• Users are a subset of a much larger number of contacts in most applications.  Can non-user contacts be placed in the same Contacts table as the user contact records?  If so, how is it possible to distinguish between the two?
• If a non-user contact is manually added to the same Contacts table as users, will they become registered users?
• Why are there two Contacts tables (see screenshot below)

[Fubar · Accepted solution]

• Each Portal User is a dataverse Contact record.  Yes Portal and other contacts reside int he Contact - think of the Contact record as a Person, where some have been granted portal access and others haven't.  There are a number of fields on the Contact record that are specific to Portal Users - if you look under the Web Authentication Tab on the Contact "Portal Contact" form you will see a field called Login Enabled (another one is Security Stamp).
• Being a Contact does not automatically give Portal Access, but you can Invite an existing Contact to become a Portal User..
• Not sure where it is pulling the Table list from, but it is possible that someone has created their own new Table and given it a Display Name = 'Contact', and the other one is the out of the box Contact table.

[MJWhite]

Thanks Fubar

That's very helpful.

Can you think of any reason why I shouldn't:

• Use the out of the box Contact table to manage user data only
• Create my own tables to manage normalised people, contact, location... data, because the out of the box Account and Contact tables don't manage 'each person has many contacts' (home, work, contact history...) and 'each location has many contacts' very well at all

Re the extra Contact table, it appears if I create a new environment and a new site(portal) i.e. it comes out of the box too.  The prefix in the name suggests it was created by someone else (see screenshot below) and I can't delete it.  I guess I'll need to create a support ticket to get rid of it?

[Fubar]

Re the Contact x2 it might be something to do with the template you selected when you installed it. note: the schema name has a prefix (standard out of the box Dataverse Tables do not have a prefix, other ones provided will usually have a msdyn_ or adx_ prefix the later is for the Portal) so has been created by a Solution with a publisher .that has that prefix defined (also if you look at Dependencies on it it may tell you the Solution it came from or you can look at the publishers and find the prefix then find the solutions from that publisher).

Generally speaking always use Account for Organizations and Contact for People.  You can rename, change and extend them as you need.  There is a lot of out of the box functionality based on Account and Contact - people who try to do there own thing around putting conacts/people in different tables usually end up with problems down the track.  A person ideally should be represented in the system as 1 record (a Contact record), if they have multiple additional items then add them as 1:Many Child entities to the Contact record etc (or out of the box or manual Many-to-Many relationships as needed).

Unless heavily customized, the system does not easily support performing your own complex joins so if you normalize to a point where you have lots of Super-Sub typing types of structure you will find it difficult to bring get the info you need into views etc. 

[MJWhite]

Thanks Fubar. 

As in interim solution, I've renamed the unwanted Contact table as 'Unwanted OOTB Contact'.  I may come across others that I don't want and can't delete, so I'll similarly rename them and then deal with them later as a batch.

I get that there is a lot of out of the box functionality based on Account and Contact and for that reason I will be storing the user data in Contact.  For other non-user contact data, the data structure really is painfully restricting.  I'll need to experiment a bit more before deciding what to do.

I'll accept your earlier reply as the the solution to the original question.