Building Data Models in Dataverse
Tables, columns, relationships, views, forms and security — the Dataverse modelling decisions that everything else in AB-410 is built on top of.
Why the data model comes first
Nadia’s instinct is to open the app designer. That is almost always the wrong first move.
Every AI capability later in this exam — prompt columns, row summaries, generative pages, rollups — reads from the data model. Get the model wrong and those features either cannot be configured or produce nonsense. AB-410 puts data modelling in Domain 1 for exactly that reason: it is the foundation the other two domains stand on.
Standard tables versus custom tables
Dataverse ships with a set of tables that already exist — Account, Contact, and many more. These are the standard tables.
If your business concept is genuinely one of those things, use the one that is already there. If your business concept is something Dataverse has never heard of — like Kite Freight’s “Depot Run” — you create a custom table.
The mistake to avoid is creating a custom “Customer” table when Account and Contact are sitting right there.
The data workspace
Tables can be created and edited from the data workspace in Power Apps — an objective that appears verbatim in the AB-410 study guide. It is the modern, maker-facing surface for working with Dataverse data: tables, columns, relationships, and the data itself in one place.
Why the exam names the surface explicitly
The study guide bullet is “Create and edit tables in the data workspace” — not just “create tables.” When Microsoft names a specific surface in an objective, it usually means questions may reference that surface by name.
Practically, know that the data workspace is where a maker goes to model data, and that it is a Power Apps maker-portal experience rather than an admin-centre one. Mei manages environments in the admin centre; Nadia models tables in the data workspace.
Columns and data types
Choosing the right column type is a recurring exam theme, because several types look interchangeable and behave very differently.
| Column family | Use it when | Watch out for |
|---|---|---|
| Text | You need free-form text of a known maximum length | Choosing a text column for something that has a fixed set of valid values — that is a choice column |
| Choice | The value must come from a controlled list | Local versus global choices. A global choice is reusable across tables; a local one is not |
| Lookup | The value is another record | A lookup is the column side of a relationship — creating one creates a relationship |
| Number / Decimal / Currency | You need arithmetic | Currency columns bring exchange-rate behaviour that constrains what formula columns can do with them |
| Date and time | You need a point in time | Behaviour settings (user local, date only, time-zone independent) change how the value is stored and displayed |
| Calculated / Rollup / Formula | The value is derived from other data | Three different engines with genuinely different behaviour — covered in depth in Domain 3 |
| Prompt | You want AI to generate the value from other columns | It is a Dataverse data type, not a flow action — covered in the next module |
A distinction worth being precise about
A lookup column and a relationship are two views of the same thing. When you create a one-to-many relationship between Depot and Depot Run, Dataverse creates a lookup column on the many side.
This matters because exam questions sometimes describe the requirement from the column side (“each run should record which depot it started from”) and sometimes from the relationship side (“a depot has many runs”). Both describe the same 1:N relationship.
Relationships
Dataverse supports one-to-many, many-to-one (the same relationship seen from the other end), and many-to-many.
| Relationship | Kite Freight example | The consequence that gets tested |
|---|---|---|
| 1:N (one-to-many) | One Depot has many Depot Runs | This is the only relationship type a rollup column can aggregate across |
| N:1 (many-to-one) | Many Depot Runs belong to one Depot | Same relationship, viewed from the child. This is where the lookup column lives |
| N:N (many-to-many) | A Driver can be certified for many Vehicle Types, and each Vehicle Type has many certified Drivers | A rollup column formula cannot include records in an N:N relationship |
Relationship behaviour — the part people skip
A 1:N relationship carries behaviour settings that determine what happens to child records when something happens to the parent — cascading of assign, share, delete, reparent, and merge.
The exam-relevant point is that these are design decisions with real consequences. Cascade delete means removing a Depot removes its Depot Runs. Restrict delete means you cannot remove a Depot while runs still reference it.
If a scenario says “we must never lose historical run records,” cascading delete is the wrong behaviour.
Views and forms
Two surfaces, two audiences, two sets of exam questions.
Public views define what a list of records looks like — which columns, what sort order, what filter. “Public” means available to users generally, as opposed to personal views a user creates for themselves.
Main forms define what a single record looks like when opened. They are the primary form type in model-driven apps, and they are where several AI features surface — the row summary bar sits at the top of a main form, which is why the next module keeps referring back here.
Forms and views are security-relevant, not just cosmetic
Domain 2 contains the objectives “Configure access to forms and views” and “Configure access to model-driven apps.” That is a deliberate signal: forms and views participate in the security story.
Different security roles can be given access to different forms of the same table — so a dispatcher and a finance user can open the same Depot Run record and see genuinely different layouts. This is presentation-level control, and it is not a substitute for record-level or column-level security.
Security
Dataverse security is layered. AB-410 does not ask you to design a security model from scratch, but it does expect you to know which lever solves which problem.
| Lever | Controls | Typical scenario wording |
|---|---|---|
| Security role | What a user can do to a table's records — create, read, write, delete, append, and so on, at defined scopes | 'Dispatchers should be able to edit runs but not delete them' |
| Business unit | The organisational boundary that scopes many role privileges | 'Auckland staff should not see Wellington's records' |
| Team | Grouping users so roles and record shares apply collectively | 'The night shift needs shared access to the same set of runs' |
| Record sharing | Granting access to individual records outside the role model | 'Just this one run needs to be visible to the contractor' |
| Column-level security | Restricting individual columns, independent of record access | 'Everyone can see the run, but only finance sees the cost column' |
| Form and view access | Which layout a role sees | 'Finance needs a different view of the same record' |
The distinction that decides most security questions
Ask yourself: is the requirement about which records, which fields, or which layout?
- Which records → security roles, business units, teams, sharing.
- Which fields → column-level security. Hiding a column on a form is not security; the data is still retrievable.
- Which layout → form and view access.
The classic wrong answer is “remove the column from the form” in response to a genuine confidentiality requirement. That is cosmetic, not secure.
Kite Freight’s model
Nadia’s first pass, after Ravi describes the operation:
| Concept | Decision | Why |
|---|---|---|
| Customer | Extend the standard Account table | Dataverse already models organisations; duplicating it would fragment the data |
| Depot | Custom table | Genuinely specific to Kite Freight’s operation |
| Depot Run | Custom table, 1:N from Depot | A depot has many runs; the lookup lives on Depot Run |
| Driver ↔ Vehicle Type | N:N relationship | Both sides are genuinely many — but Nadia notes this rules out rollups across it |
| Run cost | Currency column, column-level secured | Everyone sees the run; only finance sees the cost |
| Run status | Choice column | Controlled list, not free text |
Mei reviews the security design, because security roles and business units are administrator territory.
Quick recall
Check yourself
Kite Freight must keep Cost as a column on the Depot Run table. Every user must be able to open the Depot Run record, but only the finance team may retrieve the cost value. What should you configure?
Nadia models Drivers and Vehicle Types with a many-to-many relationship. Later, Ravi asks for a column on Driver showing the number of vehicle types that driver is certified for. What is the problem?
Ravi asks for a 'Customer' concept in the new solution. Dataverse already contains the standard Account table, which models organisations. What is the better design recommendation?