Dataverse: Relationships and Integrity

Introduction to Relationships in Dataverse

In Microsoft Dataverse, relationships between tables define how records interact with each other. Every Dataverse-based application — such as a Power App or a Power Automate Flow — relies on a relational data model that maintains consistency and integrity across entities.

There are three main types of relationships:

• One-to-many (1:N): one record in the primary table is associated with multiple records in the related table.
• Many-to-one (N:1): multiple records in one table refer to a single record in another table.
• Many-to-many (N:N): records in both tables can be associated with multiple records in the other table.

When designing a Dataverse data model, it’s crucial to choose the correct relationship type that best represents the real-world data behavior and logical dependencies within your business domain.

1:N and N:1 Relationships

A 1:N (one-to-many) relationship in Dataverse is configured by defining a primary table (the “one” side) and a related table (the “many” side). For example, one “Account” record can be linked to multiple “Contact” records.

The inverse N:1 relationship represents the same connection from the opposite perspective: each contact belongs to a single account. In practice, Dataverse implements both directions, allowing bidirectional data navigation.

When creating relationships through the Power Apps Maker Portal, administrators define the behavior and integrity rules that determine what happens when related records are updated or deleted.

1:N relationships form the foundation of many business models, enabling hierarchical structures, assignments, and dependencies between tables while maintaining data consistency.

N:N Relationships and Intersection Tables

N:N (many-to-many) relationships in Dataverse are managed through intersection tables (also known as linking tables) automatically created by the system. These tables contain the primary keys of the two related tables, establishing a bidirectional connection.

For instance, the relationship between “Users” and “Projects” can be many-to-many, since each user can work on multiple projects, and each project can have multiple assigned users. Dataverse represents this relationship with a hidden table that associates records from both entities.

N:N relationships are ideal for representing complex scenarios without data duplication, improving database normalization and long-term maintainability.

Integrity Rules and Cascading Behaviors

Each relationship in Dataverse can be configured to define how related records respond to specific events, such as deletion, assignment, sharing, or reassignment of a primary record. These settings ensure referential integrity within your data model.

The available behaviors are typically:

• Parental: changes to the parent record (for example, deletion or assignment) automatically cascade to child records.
• Referential: changes to the parent record do not affect related records; the relationship is logical, not enforced.
• Custom: allows defining custom behavior for each event (Delete, Assign, Share, Unshare, Reparent).

For example, in a cascading delete scenario, when an Account is deleted, all related Contacts may be deleted automatically (Parental) or remain independent (Referential).

The choice of cascading behavior depends on business context and application logic. In CRM systems, it’s often best to maintain referential relationships to avoid accidental data loss.

Designing Relationships: Best Practices

Designing proper relationships is one of the pillars of an efficient Dataverse model. Some best practices include:

• Use 1:N relationships to represent natural hierarchies (e.g., Company → Contacts).
• Limit the use of N:N relationships to necessary cases, as they increase query complexity.
• Define integrity behavior based on actual business processes and data management policies.
• Document each relationship, specifying direction and behavior type.
• Monitor query performance for heavily related datasets, especially in Power BI DirectQuery reports.

In the Maker Portal, you can view and modify all relationships in the “Relationships” section of each table, including cascading rule management.

Relationships and Data Security

Relationships in Dataverse interact with the security model. Related records may inherit permissions depending on the configured roles and cascading behavior.

For instance, in a Parental relationship, when a record is shared, related records can also be automatically shared with the same user or team. This simplifies data access management in complex scenarios.

When fine-grained control is required, you can apply column-level or row-level security (Row-Level Security), integrating relationships with Dataverse security policies.

To learn more, visit the official Microsoft documentation on Microsoft Dataverse: Data and Security Overview.