Dataverse relationship

What is a Dataverse relationship?

A Dataverse relationship describes how records in two tables connect to each other. Apps use relationships for lookups, related lists, navigation, queries and certain security and cascade operations.

Each relationship has a schema name and metadata about the tables involved. Its meaning should be a real business link rather than a convenient screen connection. Examples are Customer has Cases, Case contains Documents, and Employee works on Projects.

The idea is close to a foreign key in a relational database, but Dataverse manages the link as a first-class object with its own navigation, forms behaviour and rules.

One-to-many and many-to-one

In a 1:N relationship, one record can be linked to many records in another table. One customer, for instance, can have several cases.

The many side holds a lookup column that points to the record on the one side. Seen from the Case table, the same link is N:1 back to Customer, so many-to-one is simply the child's view of a one-to-many relationship. Adding a lookup column to a table is what creates the 1:N relationship in the first place.

The lookup stores the record reference. The display name a user sees can change without the link breaking.

Many-to-many

An N:N relationship allows many records on both sides, for example employees and projects. Dataverse manages an intersect table behind the scenes to hold the pairings.

A standard N:N relationship fits when the link itself carries no business data. As soon as the connection needs a role, a start date or a percentage, it should become its own table.

That association table turns the relationship into a full business object that can be secured, audited and automated in its own right.

The customer case model

Customer has a 1:N relationship with Case. Case has 1:N relationships with Document and Assessment. Each child record carries a lookup to its parent.

Case and Theme have an N:N relationship when a case can take several independent labels. If each label also needs an assessment score, CaseTheme becomes a separate table.

Forms show related records through subgrids, and flows and queries can follow a lookup to fetch the linked customer.

Referential and parental behaviour

Relationship behaviour decides what happens to related records when you act on a parent. Referential behaviour limits cascades: you can navigate between related rows, but an action on one does not ripple to the other. Parental behaviour lets actions flow down to child records, and a variant called referential restrict delete blocks a parent from being deleted while children still exist.

Cascades can be configured for operations including assign, share, unshare, reparent, merge and delete. Not every combination is allowed for every relationship.

A cascade delete can remove every dependent record. Choose it only when child records have no independent meaning or retention duty once the parent is gone.

Security and ownership

A relationship does not automatically grant read access to the linked record. Security roles, ownership, teams and sharing still apply on top.

A cascade for assign or share can affect access, though. An over-broad setting can hand many records to another owner or group without anyone intending it. Test relationships with realistic roles and record structures, because an administrator's wide rights hide what an end user would actually experience.

Relationships versus text keys

Storing a customer number as plain text on a case is not a Dataverse relationship. The platform then cannot offer referential navigation or lookup metadata around it.

Use a lookup for internal links and, where needed, an alternate key for integration. External source keys can live alongside as separate columns. Avoid two independent truths where both the text number and the lookup can drift apart, and record which source leads.

What to watch out for when changing relationships

Forms, views, flows, plug-ins and reports all use relationships, so check dependencies before you change a schema or cascade behaviour. A new required parent relationship needs a migration for existing child records: make the lookup optional first, fill in the data, then tighten the rule. Document cardinality, meaning, ownership and delete behaviour so the model stays legible when apps and teams change later.