Dataverse: vijf ontwerpfouten die u later duur komen te staan

In een Dataverse-project worden de duurste beslissingen genomen in de eerste twee weken, door iemand die de echte data nog niet gezien heeft. Ze zijn goedkoop te corrigeren in maand één en nagenoeg onmogelijk terug te draaien na de go-live.

Dit zijn de vijf die ik het vaakst tegenkom.

1. Een custom entiteit maken waar een standaardentiteit volstond

De reflex is begrijpelijk: de standaard Account-entiteit draagt 80 velden waarvan u er 12 gebruikt, dus maakt u new_klant — proper en minimaal.

Wat het kost:

• U verliest native functionaliteit: hiërarchieën, samenvoegen van duplicaten, standaardrelaties naar opportuniteiten en cases.
• Connectoren, Power BI-sjablonen en de documentatie van Microsoft gaan allemaal uit van standaardentiteiten.
• Elke nieuwe ontwikkelaar moet uw model leren in plaats van het model dat hij al kent.

De 68 ongebruikte velden kosten niets — verberg ze op het formulier. Maak een custom entiteit wanneer het businessconcept niet bestaat in het standaardmodel, niet wanneer het bestaat maar u het niet aanstaat.

2. Een tekstveld gebruiken in plaats van een keuze

new_status als vrije tekst, want “de lijst verandert vaak”.

Zes maanden later bevat uw database Goedgekeurd, goedgekeurd, Goedgekeurd (met spatie) en Goedgekuerd. Elk rapport heeft een andere WHERE-clausule. Elke Power Automate-flow heeft minstens één variant gemist.

Een keuze (optionset) kost vijf minuten om toe te voegen. Een vervuilde tekstkolom opschonen kost dagen — en is nooit volledig, want iemand blijft nieuwe varianten typen terwijl u opruimt.

Het argument “de lijst verandert vaak” houdt geen stand: een keuze aanpassen is een configuratiewijziging, geen ontwikkeling.

3. Beveiligingsrollen verwarren met zichtbaarheid op het formulier

“Deze gebruiker mag het veld Salaris niet zien” → verberg het veld op het formulier.

Het veld blijft bereikbaar via geavanceerd zoeken, Excel-export, de Web API, een rapport of een Canvas App. Een veld verbergen op een formulier is geen beveiliging. Het is opmaak.

Field-level security bestaat hiervoor. Ze is zwaarder op te zetten, en net dat maakt haar effectief: ze geldt overal, langs welke deur u ook binnenkomt.

Is de data echt gevoelig — HR, gezondheid, financieel — dan is dit geen opmaakdetail. In België is het ook een GDPR-kwestie.

4. Een N:N modelleren waar een tussenentiteit nodig was

Een native N:N-relatie is verleidelijk: twee klikken, geen tabel te beheren.

Maar ze kan geen attributen dragen. De dag — en die dag komt altijd — dat de business vraagt “sinds wanneer hangt dit contact aan dit project?” of “welke rol heeft hij erin?”, kan de native relatie geen antwoord geven.

Een N:N achteraf migreren naar een tussenentiteit betekent de data opnieuw aanmaken en de views, flows en rapporten herschrijven. Vooraf is het één entiteit extra in het model.

Mijn regel: zodra een associatie ook maar enige kans heeft om een datum, een rol, een status of een commentaar te dragen, maak de tussenentiteit meteen aan.

5. Omgevingen niet scheiden vanaf dag één

“We zijn met drie, we ontwikkelen rechtstreeks in productie en splitsen later wel.”

Later komt nooit. Wat wel komt:

• Een unmanaged solution in productie die niet proper te verwijderen is
• Geen spoor van wie wat wijzigde, of waarom
• Een dringende fix die een lopende demo breekt
• Testdata vermengd met echte data die niemand durft te verwijderen

Dev → Test → Prod, met managed solutions in Test en Prod, kost een halve dag bij de kickoff. Die scheiding achteraf aanbrengen op een vervuilde omgeving kost weken, en gebeurt altijd op het slechtst mogelijke moment.

Wat ze gemeen hebben

Alle vijf hebben dezelfde vorm: een zichtbare besparing vandaag tegen een onzichtbare kost morgen. Het tekstveld is sneller aangemaakt. Rechtstreeks in productie bespaart u een pipeline. De custom entiteit oogt netter.

De vraag bij modelleren is niet “wat gaat nu het snelst?” maar “wat wordt later het moeilijkst om te wijzigen?”. Wat moeilijk te wijzigen is — het datamodel, de beveiliging, de omgevingstopologie — verdient die tijd. De rest kan opnieuw gedaan worden.