5.1 Configuring Table Relationships

Microsoft Certified: Intelligent Applications Builder Associate AB-410

Track your progress as you read

Finished sections get a check mark.

1 Introduction

1.1 About the AB-410 Exam 1.2 How to Use This Study Guide

2 Chapter 2: Designing Power Platform Solutions with AI-Enabled Tools

2.1 Analyzing Requirements and Identifying Components 2.2 Evaluating Built-in Agents for Business Solutions 2.3 Recommending Extensibility Options

3 Chapter 3: Environments and ALM Strategy

3.1 Recommending Environment Types 3.2 Solution and Application Lifecycle Management Strategy

4 Chapter 4: Dataverse Tables and Columns

4.1 Creating and Editing Tables in the Data Workspace 4.2 Configuring Table Properties 4.3 Creating and Modifying Columns

5 Chapter 5: Relationships, AI Data Features, and Data Security

5.1 Configuring Table Relationships 5.2 Configuring Prompt Columns and Row Summaries 5.3 Configuring Public Views and Main Forms 5.4 Configuring Dataverse Security

6 Chapter 6: Model-Driven App Forms and Views

6.1 Creating and Configuring Forms for Model-Driven Apps 6.2 Creating and Configuring Views for Model-Driven Apps 6.3 Creating Generative Pages with Natural Language

7 Chapter 7: Composing, Securing, and Visualizing Model-Driven Apps

7.1 Composing a Model-Driven App 7.2 Configuring Access to Model-Driven Apps, Forms, and Views 7.3 Model-Driven App Charts and Dashboards

8 Chapter 8: Creating and Designing Canvas Apps

8.1 Creating a Canvas App Using Data 8.2 Designing for Accessibility, Performance, Responsiveness, and Usability 8.3 Automating Business Processes from Canvas Apps

9 Chapter 9: Canvas App Components, Variables, and Error Handling

9.1 Reusable Components, Named Formulas, and User-Defined Functions 9.2 Managing Variables and Collections 9.3 Implementing Error Handling in Canvas Apps

10 Chapter 10: Testing Canvas Apps and Creating Agents from Apps

10.1 Testing Canvas Apps with Monitor 10.2 Creating a Copilot Studio Agent from a Canvas App

11 Chapter 11: Cloud Flow Triggers, Connectors, and Approvals

11.1 Recommending Cloud Flow Triggers 11.2 Evaluating and Recommending Connectors 11.3 Managing Approvals with Cloud Flows

12 Chapter 12: Cloud Flow Actions, Control, and Troubleshooting

12.1 Configuring Cloud Flow Actions 12.2 Implementing Flow Control with Conditions and Loops 12.3 Testing and Troubleshooting Cloud Flows

13 Chapter 13: Building Prompts in AI Hub

13.1 Building Prompts from Templates or from Blank 13.2 Adding Inputs to a Prompt 13.3 Adding Knowledge to a Prompt

14 Chapter 14: Prompt Settings, Models, and Consuming AI

14.1 Customizing Prompt Settings and Models 14.2 Consuming Prompts in Apps and Cloud Flows 14.3 Consuming AI Models in Apps and Cloud Flows

15 Chapter 15: Business Rules and Business Process Flows

15.1 Configuring Business Rules 15.2 Configuring Business Process Flows

16 Chapter 16: Calculated Columns and Business Logic Strategy

16.1 Calculated, Rollup, and Formula Columns 16.2 Evaluating Use Cases for Business Logic

5.1 Configuring Table Relationships

Key Takeaways Explain This Topic AI

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.

Last updated: July 2026

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.