Dataverse: five design mistakes that cost you later

On a Dataverse project, the most expensive decisions get made in the first two weeks, by someone who hasn’t seen the real data yet. They’re cheap to fix in month one and close to impossible to undo after go-live.

Here are the five I run into most.

1. Creating a custom entity where a standard one would do

The instinct is understandable: the standard Account entity carries 80 fields and you use 12, so you create new_client — clean and minimal.

What it costs you:

• You lose native capability: hierarchies, duplicate merging, standard relationships to opportunities and cases.
• Connectors, Power BI templates and Microsoft’s own documentation all assume standard entities.
• Every new developer has to learn your model instead of the one they already know.

The 68 unused fields cost nothing — hide them on the form. Create a custom entity when the business concept doesn’t exist in the standard model, not when it exists but you don’t like it.

2. Using a text field instead of a choice

new_status as free text, because “the list will change often”.

Six months later your database holds Approved, approved, Aproved, APPROVED (with the trailing space) and Apprvoed. Every report has a different WHERE clause. Every Power Automate flow has missed at least one variant.

A choice (optionset) takes five minutes to add. Cleaning a polluted text column takes days — and it’s never complete, because someone keeps typing new variants while you clean.

The “the list changes often” argument doesn’t hold: editing a choice is a configuration change, not a development one.

3. Confusing security roles with form visibility

“This user shouldn’t see the Salary field” → hide the field on the form.

The field stays reachable through advanced find, Excel export, the Web API, a report, or a Canvas App. Hiding a field on a form is not security. It’s layout.

Field-level security exists for this. It’s heavier to set up, and that’s exactly what makes it work: it applies everywhere, whatever door you come through.

If the data is genuinely sensitive — HR, health, financial — this isn’t a layout detail. In Belgium, it’s also a GDPR question.

4. Modelling an N:N where you needed an intermediate entity

A native N:N relationship is tempting: two clicks, no table to manage.

But it can carry no attributes. The day — and that day always comes — the business asks “since when has this contact been on this project?” or “what’s their role on it?”, the native relationship cannot answer.

Migrating an N:N to an intermediate entity after the fact means recreating the data and rewriting the views, flows and reports. Up front, it’s one more entity in the model.

My rule: the moment an association has any chance of carrying a date, a role, a status or a comment, create the intermediate entity now.

5. Not separating environments from day one

“There are three of us, we’ll develop straight in production and split it out later.”

Later never comes. What comes instead:

• An unmanaged solution in production that can’t be cleanly uninstalled
• No record of who changed what, or why
• An urgent fix that breaks a demo in progress
• Test data mixed into real data that nobody dares delete

Dev → Test → Prod, with managed solutions in Test and Prod, costs half a day to set up at kickoff. Retrofitting that separation onto a polluted environment takes weeks, and always at the worst possible moment.

What they have in common

All five share the same shape: a visible saving today against an invisible cost tomorrow. The text field is quicker to create. Straight-to-production skips configuring a pipeline. The custom entity looks tidier.

The question in modelling isn’t “what’s fastest right now?” but “what will be hardest to change later?”. The things that are hard to change — the data model, security, environment topology — deserve the time. The rest can be redone.