Answered

Standard vs. Custom Tables for Party Data (Account, Contact, Organization...)

(1) Share

Report

Posted on by CF-07111227-0

We are developing an application on the Power Platform with Dataverse as the backend.

Our core architectural challenge is determining the best way to implement a party based data hierarchy using the standard dataverse tables: Account, Organization, and Contact. What are the specific roles of these three standard tables, and is it best practice to extend them for our custom model if they fit in instead of creating new, parallel tables?

For example we have a Party table which shall be related with a Person and Organization (Company, ...)

Categories:

Microsoft Dataverse with Power Apps

I have the same question (0)

All responses (4)

Answers (1)

Verified answer

Michael E. Gernaey 53,932 Moderator on at

Like (1)

Report
Copy link

Link copied!

Hi @CF-07111227-0

I do not recommend setting up parallel tables. There is nothing wrong with extending and I want to be specific (do not use organization), Account and Contact.

Use Contact for Person and Account for the other and extend as needed.

You can use things like lookups, connections etc between records so as you extended your model its easy to link these tables together.

You also have the option of using the polymorphic "customer" which can be EITHER a contact or an account. and you would have to use a check in your expressions for whether you are using a contact or an account record in that field type.

I would look at adding custom fields as you need too and add custom entities (tables) and then link them to those 2 tables.

I honestly have yet built a customer solution where I intentionally created different tables for those specific things.

Not that you can't I just do not do it.

If these suggestions help resolve your issue, Please consider Marking the answer as such and also maybe a like.

Thank you!
Sincerely, Michael Gernaey

Was this reply helpful? Yes No
CF-07111227-0 8 on at

Like (0)

Report
Copy link

Link copied!

Hi Michael E. Gernaey,

Thank you for your response.

Since in our case a contact can have many accounts and an account can have many contacts (a many-to-many relationship), what is the best practice: using a relation entity, adding contextual data, or using connections?"

If i understand it correctly, the connection should be used for informal relationships?

Thanks

Christian

Was this reply helpful? Yes No
Suggested answer

Michael E. Gernaey 53,932 Moderator on at

Like (0)

Report
Copy link

Link copied!

Hello @CF-07111227-0

In that case I would create an intersect table, or in the old days a mapping table between them. This will allow you to not only capture the many to many but allow you to add additional contextual data that will now be part of the formalized schema.. No do not use connections, they are a waste in this case. The biggest reason is simply that while you can relate records together, you cannot then assign additional meta-data (columns) related to the connection.

I have no idea what additional fields you would want to create, but an silly one that will auto exist (created on), but let's pretend you wanted to know the last time a contact, for company X was contacted. The last time, not every time ( you could track that too ), then an intersect would allow you to generate that extra field and easily populate it. It's also much easier when you build apps to use it. If you only had relationships its not really possible.

Cheers,

-Michael

Was this reply helpful? Yes No
Fubar 8,463 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!

As per Michael's response... use the existing tables rather than creating others Contact = Person, Account = Organisation.

Connections fit certain scenarios, but one of the downfalls is that it is a complex data structure and so for some reporting or querying can add additional complexity (and is also not good to work with if you are then also going to add Power Pages portal into the mix if the role on the connection becomes important for record access), it can also be a bit 'clunky' for a user when assigning them particularly if they are configured for connecting to many different table types.

If you are wanting to add additional attributes, create a manual many-to-many relationship (i.e. create a table with a lookup column to Account and another column to Contact) and add additional attributes/columns to that table. (as you are doing a many-to-many, one example could be something like Position/Title as it could be different for different organisations the contact is associated with).

Was this reply helpful? Yes No