Introductie
Deze pagina beschrijft de richtlijnen voor het ontwerpen en configureren van entiteiten en datamodel binnen Dataverse.
Het doel is:
- consistente datamodellen
- duidelijke naamgeving
- onderhoudbare structuur
- voorspelbaar gedrag van data (relaties, mapping en cascading)
1. Algemene principes
- elke entiteit heeft een duidelijk functioneel doel
- vermijd duplicatie van data
- gebruik standaard Dataverse functionaliteit waar mogelijk
- houd het datamodel eenvoudig en logisch
🧱 2. Entiteiten (Tables)
Display name
- enkelvoud
- begrijpelijk voor eindgebruikers
Voorbeelden:
- Account
- Order
- Subscription
Schema name
- publisher prefix verplicht
- technisch en compact
Voorbeelden:
- brenke_productionline
- brenke_registration
- brenke_subscription
🔗 3. Relaties (Relationships)
Relaties maken onderdeel uit van het datamodel en bepalen hoe entiteiten met elkaar verbonden zijn.
Deze sectie beschrijft de naamgeving van relaties (relationships) binnen Dataverse.
Relaties bepalen de samenhang tussen entiteiten en worden gebruikt voor:
- datamodel structuur
- lookup velden
- navigatie en views
- integraties en API’s
👉 Consistente naamgeving is essentieel voor onderhoudbaarheid en leesbaarheid.
3.1. Algemene structuur
De schema name van een relatie volgt het format:
<publisher>_<bronEntiteit>_<doelEntiteit>
Voorbeeld:
brenke_account_contact
brenke_contact_account
3.2. Belangrijk onderscheid
Binnen Dataverse zijn er drie typen relaties:
- 1:N (One-to-Many)
- N:1 (Many-to-One / lookup)
- N:N (Many-to-Many / intersect)
👉 De naamgeving verschilt per type.
3.3. 1:N relaties
Bij een 1:N relatie:
- één record heeft meerdere gerelateerde records
- de lookup zit aan de N-kant
Structuur
<publisher>_<hoofdEntiteit>_<gerelateerdeEntiteit>
Voorbeelden
brenke_account_contact
brenke_account_opportunity
👉 Betekenis:
- een account heeft meerdere contacten
- een account heeft meerdere opportunities
3.4. N:1 relaties (lookup kant)
Dit is de technische kant van de relatie:
- de lookup wordt opgeslagen op de child entiteit
Structuur
<publisher>_<childEntiteit>_<parentEntiteit>
Voorbeelden
brenke_contact_account
brenke_opportunity_account
👉 Dit sluit aan op lookup velden zoals:
brenke_accountId
brenke_primaryContactId
3.5. Naamgeving lookup veld vs relatie
Belangrijk onderscheid:
| Onderdeel |
Naam |
| Lookup veld |
brenke_accountId |
| Relatie |
brenke_contact_account |
👉 Dus:
- veld = data (Id)
- relatie = structuur (entity → entity)
3.6. N:N relaties (Many-to-Many)
Bij een N:N relatie:
- meerdere records aan beide kanten
- er wordt een koppeltabel (intersect) aangemaakt
Structuur
<publisher>_<entiteit1>_<entiteit2>
Voorbeelden
brenke_account_competency
brenke_contact_interest
brenke_user_role
Richtlijnen
- gebruik alfabetische volgorde OF vaste volgorde (bijv. business-priority)
- kies één standaard en blijf consistent
3.7. Intersect entiteit (optioneel)
Bij complexe N:N relaties of extra velden:
Structuur
<publisher>_<entiteit1>__<entiteit2>_link
Voorbeeld
brenke_account_contact_link
👉 Alleen gebruiken indien:
- extra velden nodig zijn
- expliciete entiteit gewenst is
3.8. Navigatie naamgeving
Voor leesbaarheid in UI en code:
1:N
Account → Contacts
N:1
Contact → Account
👉 Richtlijnen:
- enkelvoud voor entity
- meervoud voor collecties
3.9. Richtlijnen
- gebruik altijd publisher prefix (
brenke_)
- gebruik lowercase + underscores
- gebruik duidelijke entity namen
- vermijd afkortingen
- wees consistent in volgorde
- wijzig namen niet per environment
👉 Consistentie is belangrijker dan perfectie.
3.10. Veelgemaakte fouten
✘ brenke_relation1
✘ brenke_lookup_account
✘ brenke_contact1_account2
✘ brenke_acc_cont
👉 Deze zijn:
- onduidelijk
- niet schaalbaar
- slecht leesbaar
3.11. Samenvatting
| Type relatie |
Naamgeving |
| 1:N |
brenke_account_contact |
| N:1 |
brenke_contact_account |
| N:N |
brenke_account_contact |
| Lookup veld |
brenke_accountId |
👉 Relatienamen beschrijven altijd de relatie tussen entiteiten — niet de implementatie.
🛠️ 4. Mapping van data
Relaties kunnen gebruikt worden om data over te nemen bij het aanmaken van records.
Field mapping
Bij een 1:N relatie kan mapping worden ingesteld.
Voorbeeld:
- Account naam wordt gekopieerd naar Contact bij aanmaken
Stapsgewijze instructie: Field mapping instellen
Onderstaande stappen beschrijven hoe je field mapping tussen twee entiteiten configureert.
Stap 1 – Open de relatie
- Ga naar de betreffende entiteit (bijv. Contact)
- Ga naar Relationships
- Zoek de gewenste 1:N relatie (bijv. Contact → Account)
- Open de relatie
Stap 2 – Open mapping
- In de relatie kies je voor Mappings
- Klik op New Mapping
Stap 3 – Configureer de mapping
- Kies het veld op de parent (bijv. Account naam)
- Kies het veld op de child (bijv. Contact veld)
Voorbeeld:
- Account naam wordt overgenomen bij aanmaken van Contact
Stap 4 – Opslaan en publiceren
- Sla de mapping op
- Publiceer de wijzigingen
Stap 5 – Test de mapping
- Maak een nieuw child record aan vanuit de parent (bijv. Contact vanuit Account)
- Controleer of het veld automatisch wordt gevuld
Belangrijk gedrag
- Mapping wordt alleen uitgevoerd bij aanmaken van een record
- Wijzigingen in de parent worden niet automatisch doorgevoerd
- Mapping werkt alleen wanneer het child record via de relatie wordt aangemaakt
Gebruik
Mapping wordt toegepast:
- bij creatie van child records
- bij kopiëren van data vanuit parent
Richtlijnen
- Gebruik mapping alleen voor initiële waarden
- Gebruik mapping niet voor dynamische synchronisatie
- Vermijd complexe afhankelijkheden
👉 Voor dynamische of terugkerende logica gebruik je JavaScript, Flow of Plugin.
👉 Mapping bepaalt initiële data, cascading bepaalt gedrag na wijzigingen.
🧹 5. Cascading rules
Cascading bepaalt welk effect acties op een parent record hebben op gerelateerde (child) records.
Met cascading stel je per relatie in:
👉 wat er met gekoppelde records gebeurt wanneer een actie wordt uitgevoerd op de hoofdentiteit.
Gedrag van cascading
Wanneer een actie wordt uitgevoerd op een parent record (bijvoorbeeld een Account), kan Dataverse:
- dezelfde actie uitvoeren op gerelateerde records (bijvoorbeeld Contacten)
- geen actie uitvoeren (records blijven ongewijzigd)
- de actie blokkeren
👉 Dit gedrag wordt per relatie en per actie geconfigureerd.
Acties waarop cascading van toepassing is
Voor elke relatie wordt het gedrag afzonderlijk bepaald voor de volgende acties:
- Delete → verwijderen van een record
- Assign → wijzigen van eigenaar
- Share → delen van een record
- Unshare → intrekken van delen
- Reparent → wijzigen van de parent-relatie (lookup)
Beschikbare opties
Per actie kan worden ingesteld hoe deze doorwerkt naar gerelateerde records:
Cascade All
→ actie wordt uitgevoerd op alle gerelateerde records
Cascade Active
→ actie wordt alleen uitgevoerd op actieve records
Cascade User-Owned
→ actie wordt alleen uitgevoerd op records van dezelfde eigenaar
Restrict
→ actie wordt geblokkeerd als er gerelateerde records bestaan
No Cascade
→ er gebeurt niets met gerelateerde records
Voorbeeld
Wanneer een Account wordt verwijderd:
Cascade All
→ alle gekoppelde Contacten worden ook verwijderd
Restrict
→ verwijderen wordt geblokkeerd zolang er Contacten gekoppeld zijn
No Cascade
→ Account wordt verwijderd, Contacten blijven bestaan
👉 De gekozen optie bepaalt direct de impact op je data.
Belangrijk
Cascading kan grote impact hebben op data en gedrag van de oplossing.
Let op:
- Cascade All bij Delete kan leiden tot onbedoeld verlies van data
- cascading wordt automatisch uitgevoerd zonder extra bevestiging
- de impact is vaak pas zichtbaar na deployment
👉 Analyseer altijd de impact van cascading rules vooraf.
👉 Mapping bepaalt initiële data, cascading bepaalt gedrag na wijzigingen.
🔤 6. Velden (Columns)
Deze sectie beschrijft de naamgeving van velden (columns) binnen Dataverse.
Doel van consistente naamgeving:
- duidelijke en herkenbare veldnamen
- voorspelbaar gebruik in code en integraties
- betere onderhoudbaarheid binnen solutions
Display name
De display name is bedoeld voor functionele gebruikers en moet direct begrijpelijk zijn.
Richtlijnen
- gebruik duidelijke en beschrijvende namen
- vermijd afkortingen
- gebruik spaties voor leesbaarheid
- schrijf in titelvorm
Voorbeelden
- Email address
- Phone number
- Order date
- Primary contact
Schema name
De schema name (logical name) wordt gebruikt in code, API’s en configuratie.
Structuur
<publisher>_<functioneleNaam><suffix>
Richtlijnen
- publisher prefix is verplicht (
brenke_)
- gebruik lowerCamelCase na de underscore
- geen spaties
- gebruik duidelijke Engelse termen
- vermijd afkortingen
Naming per type veld
Tekst (Single line / Multiline)
- geen suffix nodig
- gebruik beschrijvende naam
Voorbeelden
- brenke_name
- brenke_firstName
- brenke_lastName
- brenke_description
Boolean (Yes/No)
Voorbeelden
- brenke_isActive
- brenke_isCustomer
- brenke_hasContract
Keuzeveld (Choice / OptionSet)
- gebruik zelfstandig naamwoord
- geen suffix nodig
Voorbeelden
- brenke_status
- brenke_type
- brenke_category
Numeriek (Whole / Decimal / Money)
- gebruik beschrijvende naam
- geen suffix nodig
Voorbeelden
- brenke_quantity
- brenke_amount
- brenke_creditLimit
Datum / tijd
- gebruik suffix:
- Date
- DateTime (indien nodig)
Voorbeelden
- brenke_startDateTime
- brenke_birthDate
- brenke_createdOn
Lookup velden ✅
- gebruik altijd suffix
Id
- naam beschrijft de relatie (niet alleen entity naam)
Voorbeelden
- brenke_primaryContactId
- brenke_parentAccountId
- brenke_customerId
Goed
✔ brenke_accountManagerId
✔ brenke_primaryContactId
Fout
✘ brenke_contactId
(te generiek)
Percentage / rates
Voorbeelden
- brenke_discountPercentage
- brenke_interestRate
Technische / integratie velden
Voorbeelden
- brenke_externalId
- brenke_integrationKey
- brenke_erpReference
Consistentie regels
- gebruik dezelfde structuur binnen alle entiteiten
- gebruik vaste suffixen per datatype
- wijzig namen niet per environment
- volg naming conventions in alle solutions
👉 Consistentie is belangrijker dan individuele voorkeur.
Samenvatting
| Type |
Naamgeving |
| Tekst |
brenke_name, brenke_description |
| Boolean |
brenke_isActive, brenke_hasContract |
| Lookup |
brenke_customerId, brenke_accountManagerId |
| Datum |
brenke_startDateTime, brenke_createdOn |
| Numeriek |
brenke_amount, brenke_quantity |
| Percentage |
brenke_discountPercentage |
👉 Deze naamgeving zorgt voor consistente, leesbare en onderhoudbare oplossingen binnen Dataverse.
📊 Samenvatting
Een goed ontworpen entiteit zorgt voor:
- duidelijke data
- betere performance
- minder fouten
- eenvoudiger onderhoud