5.1 Configuring Table Relationships
Key Takeaways
- A one-to-many relationship is implemented as a single lookup column on the child table — the same column defines both the 1:N view from the parent and the N:1 view from the child.
- Parental behavior cascades delete (Cascade All); Referential clears the lookup (Remove Link); Referential, Restrict Delete blocks deleting a parent that still has child rows.
- Configurable Cascading lets you set Assign, Share, Unshare, Reparent, Delete, and Merge independently, with options such as Cascade All, Cascade Active, Cascade User-Owned, Cascade None, Remove Link, and Restrict.
- Column mappings copy parent values into a child record only when the child is created from the parent's context — never on standalone creates or on later edits.
- Use a manual many-to-many (custom intersect table with two 1:N relationships) when the association needs its own columns; a table can have only one self-referencing relationship flagged as hierarchical.
Relationships are the connective tissue of a Microsoft Dataverse data model. For the AB-410 exam you must know which relationship type fits a scenario, what the lookup column actually is, and how behavior settings ripple through your data when records are assigned, shared, reparented, or deleted.
One-to-Many and Many-to-One
A one-to-many (1:N) relationship is created by adding a lookup column to the many (child) table. That single column simultaneously defines the N:1 view from the child and the 1:N view from the parent — there is no separate relationship object to build. In a typical order-entry design, the Order Line table carries an Order lookup column, and the Order table then exposes an Order Lines subgrid on its form.
You create relationships in the maker portal at make.powerapps.com → Tables → open the table → Relationships (under Schema) → New relationship, or simply by adding a column of data type Lookup, which creates the N:1 side inline.
Choosing the right shape: Order → Order Line vs Contact ↔ Account
| Scenario | Relationship | Implementation |
|---|---|---|
| One Order has many Order Lines; each line belongs to exactly one order | 1:N | Lookup column Order on the Order Line table |
| A Contact works for one Account; an Account has many Contacts | 1:N | Lookup column Account (Company Name) on the Contact table |
| An Account names one Primary Contact out of its many Contacts | N:1 | A second lookup column, Primary Contact, on the Account table |
Two tables can have multiple relationships between them; each lookup column is its own relationship. The exam likes to test whether you notice that Primary Contact is a separate N:1 relationship layered on top of the standard Account → Contact 1:N.
Many-to-Many: Native vs Manual
A native many-to-many (N:N) relationship links two tables directly (for example, Contact ↔ Event) and Dataverse maintains a hidden intersect table behind the scenes. Choose it when the association itself carries no data.
A manual many-to-many uses a custom intersect table (also called a join or junction table) with two 1:N relationships — one to each side. Choose the manual pattern when you need:
- Extra columns on the association — for example, a Registration intersect table that stores Signup Date and Seat Number
- The intersect records to appear in views, reports, and exports
- Independent control of cascade behavior on each side
Native N:N relationships cannot carry columns, and their hidden intersect rows are not available to views or reporting — a classic exam trap whenever a scenario says 'track the date each contact registered' or 'record the role each consultant played on the project.'
Relationship Behaviors
Every 1:N relationship has a type of behavior that controls what happens to child rows when the parent row is assigned, shared, unshared, reparented, deleted, or merged.
| Behavior | When parent is deleted | Assign / Share / Reparent |
|---|---|---|
| Parental | Cascade All — children are deleted too | Cascade All — children follow the parent |
| Referential | Remove Link — the child lookup is cleared | Cascade None |
| Referential, Restrict Delete | Restrict — the delete is blocked while children exist | Cascade None |
| Configurable Cascading | You choose per action | You choose per action |
With Configurable Cascading you set each action — Assign, Share, Unshare, Reparent, Delete, Merge — individually, choosing from Cascade All, Cascade Active, Cascade User-Owned, Cascade None, Remove Link, or Restrict.
Exam traps to memorize:
- Parental + Delete = Cascade All: deleting one Order silently deletes every Order Line. If the scenario says 'orders that have lines must never be deleted,' the answer is Restrict Delete, not Parental.
- Merge cascades in parental relationships: child rows are re-parented to the surviving record when duplicates are merged.
- Reparent controls whether a child can be moved to a different parent at all — with Cascade None, reparenting is blocked.
Column Mappings
On a 1:N relationship you can define column mappings that copy values from the parent row into the new child row — for example, copying Price List or Currency from Order to Order Line. Mappings apply only when the child is created in the context of the parent (from the parent's subgrid or associated view). They do not apply when the child is created standalone, and they do not keep values synchronized afterward. That one-way, create-time-only behavior is a frequent distractor.
Hierarchical Relationships
A self-referencing relationship is a 1:N relationship from a table back to itself — the classic example is Account with a Parent Account lookup. Marking that relationship as hierarchical unlocks hierarchy visualizations (the tile/tree view on rows such as account hierarchies or the manager chain on the User table). A table can have several self-referencing lookups, but only one can be flagged hierarchical.
Connections (Awareness Level)
Connections are a legacy, ad-hoc alternative to formal relationships: any two records can be linked with named connection roles such as Former Employee, Influencer, or Stakeholder. Connections carry no cascade behavior, no column mappings, and no referential integrity — they simply record that a relationship exists. Know that they exist and when they are appropriate (informal, many-shaped networks between people and organizations); for a structured data model, the exam expects formal relationships.
Contoso's model-driven app tracks Orders and Order Lines. Auditors require that an Order can never be deleted while it still has Order Lines. Which relationship behavior should you configure on the Order → Order Line relationship?
Fabrikam runs training events. A Contact can attend many Events and an Event can have many Contacts, and the team must record each registration's Signup Date and Seat Number. Which design meets the requirement?