Configuring Dataverse Connection Roles and Relationship Categories: Modeling Party-to-Party Associations Between Records in Model-Driven Apps

Introduction

Imagine you're building a CRM-style app for a consulting firm. You have contacts, accounts, and projects — but the relationships between them aren't just structural foreign keys. A contact might be a "Sponsor" on one project, a "Technical Reviewer" on another, and the "Primary Point of Contact" at an account. Another contact might serve as "Legal Counsel" for multiple accounts simultaneously. Standard one-to-many relationships with lookup columns can't express this richness — they'd require a separate lookup column for every possible role, and that falls apart quickly when roles are dynamic or a single contact plays multiple roles on the same record.

This is exactly the problem that Dataverse Connection Roles solve. Connections are a native Dataverse mechanism for creating named, typed, bidirectional associations between records — including records from different tables. Rather than building custom junction tables for every "person plays role on project" scenario you encounter, you configure connection roles that users can apply at runtime, describe the nature of the relationship, and surface in subgrids on any form. By the end of this lesson, you'll have a fully working connection role configuration for a realistic professional services scenario, and you'll understand the design decisions that make connections the right tool in some situations — and the wrong tool in others.

What you'll learn:

• What Dataverse connections and connection roles are, and how they differ from standard table relationships
• How to create and configure connection roles with appropriate categories and reciprocal role pairs
• How to restrict which tables a connection role applies to, and why that matters for data quality
• How to surface connections on model-driven app forms using the Connections subgrid
• How to design a cohesive connection role taxonomy for a real-world app scenario
• Common pitfalls: misconfigured reciprocal roles, missing table restrictions, and security role gaps

---

Prerequisites

You should be comfortable with Dataverse table relationships and know how lookups and many-to-many relationships work — if you need a refresher, Designing a Dataverse Data Model: Relationships, Lookups, and Choice Columns covers that foundation. You should also have a working model-driven app to configure, and access to the Power Apps maker portal (make.powerapps.com) with a System Customizer or System Administrator security role in your environment.

---

Understanding the Connection Architecture

Before you touch the maker portal, let's build a clear mental model of how connections work under the hood. This matters because the UI presents connections in a slightly abstracted way that can be confusing if you don't understand what's actually being stored.

The Connection and ConnectionRole Tables

Every connection you create in Dataverse is a record in the system connection table. Each connection record holds:

• Record 1: A polymorphic reference to the "from" record (stored as record1id + record1objecttypecode)
• Record 2: A polymorphic reference to the "to" record (stored as record2id + record2objecttypecode)
• Record 1 Role: A lookup to a connectionrole record describing the role Record 1 plays
• Record 2 Role: A lookup to a connectionrole record describing the role Record 2 plays
• Effective date and End date: Optional date range for the relationship's validity

The connectionrole table stores the role definitions you configure — things like "Project Sponsor," "Legal Counsel," or "Technical Reviewer." Each role record belongs to a Connection Role Category (a global option set), which gives you a way to group and filter roles in the UI.

Connections vs. Standard Relationships

This is the design decision you'll face most often. Standard relationships (the kind covered in Configuring Dataverse Table Relationships in Model-Driven Apps: One-to-Many, Many-to-Many, and Cascade Behaviors Explained) are structural — they live in the schema, support cascade behaviors, and enable rollup columns, calculated fields, and filtered views. Connections are runtime data — they're flexible but can't participate in rollups, formula columns, or cascade deletes in the same way.

Use connections when:

• The role a record plays in a relationship is variable or user-defined
• The same two records might have multiple relationships simultaneously
• You need effective/end dates on the relationship itself
• The relationship spans heterogeneous table types (contact-to-contact, contact-to-account, account-to-project, etc.) and a fixed schema would become unwieldy

Use standard relationships when:

• The relationship is structural and fixed (every Project has exactly one Account)
• You need rollup columns, cascade delete, or security inheritance
• You need to query the relationship with high-performance filtered views or reports

In practice, well-designed Dataverse apps use both: structural lookups for the core data model, and connections for the soft "who plays what role" associations that business users define and manage over time.

---

Anatomy of a Connection Role

Let's break down what you're actually configuring when you create a connection role.

Connection Role Category

Every role must belong to a category. The Connection Role Category is a system option set (not customizable beyond adding values through solution customization) with these built-in values:

Category Value	Typical Use
Business	Professional or organizational relationships
Family	Personal relationships (used in nonprofit/social sector apps)
Social	Informal or community relationships
Other	Catch-all
Sales Team	Relationships related to a sales team member
Stakeholder	Project or initiative stakeholders

You can add custom option set values here, but most professional apps work fine with Business or Stakeholder. Categories primarily control filtering in the connection role picker — they don't enforce anything structurally.

Reciprocal Roles

Connection roles can (and usually should) be paired. A "Project Sponsor" role has a natural counterpart: the project being sponsored might be described as "Sponsored Project" from the contact's perspective. This pairing is called a reciprocal role.

Reciprocal roles are important because connections are bidirectional records. When you look at a contact and see their connections, you want to see that they're a "Sponsor" of Project Alpha — not just see a raw connection record. When you look at Project Alpha, you want to see that it "Has Sponsor" — not the same label from both ends.

Table Type Restrictions

By default, a connection role can be used with any table that has connections enabled. This sounds flexible, but it creates data quality problems: users can accidentally assign "Project Sponsor" as the role for a connection between two accounts, which is probably not what you intended.

Every production connection role should have explicit table restrictions. You restrict a role by associating it with specific tables — only records from those tables will be eligible for that role on a connection.

---

Enabling Connections on Tables

Before you can create connections between records, connections must be enabled on the participating tables. For standard system tables (Contact, Account, Lead, Opportunity, etc.), connections are already enabled. For custom tables, you need to turn this on.

Navigate to make.powerapps.com, open your solution, find your custom table, and open its settings. Under the General tab, look for the Connections checkbox in the collaboration section and ensure it's checked. Save and publish.

For our professional services example, we'll be working with:

• Contact (system table, connections already enabled)
• Account (system table, connections already enabled)
• cr7f2_Project (custom table — enable connections in table settings)
• cr7f2_Engagement (custom table — enable connections in table settings)

---

Building Your Connection Role Taxonomy

Before creating individual roles, invest time in designing your taxonomy. Ad-hoc connection roles created by different team members over time become a mess of overlapping, inconsistently named roles that confuse users. Design first, build second.

The Professional Services Scenario

We're building a project management app for a consulting firm. The business needs to track:

1. Who is the client-side Sponsor for a project? (a Contact at an Account)
2. Who are the Stakeholders on a project? (Contacts, possibly from multiple Accounts)
3. Who serves as Legal Counsel for an Account? (a Contact, possibly from another Account — an external law firm)
4. What is the relationship between two Contacts? (e.g., "Reports To" / "Manages")
5. What firm does a Contact belong to? (beyond their primary Account — for consultants who work across clients)

This gives us a clean set of role pairs to design:

Role Name	Category	Reciprocal Role	Table 1	Table 2
Project Sponsor	Stakeholder	Sponsored Project	Contact	Project
Project Stakeholder	Stakeholder	Has Stakeholder	Contact	Project
Legal Counsel	Business	Represented By	Contact	Account
Legal Client	Business	Provides Counsel To	Account	Contact
Reports To	Business	Manages	Contact	Contact
Manages	Business	Reports To	Contact	Contact
Secondary Affiliation	Business	Affiliated Contact	Account	Contact

Notice a few design choices here:

• "Reports To" and "Manages" are mutual reciprocals of each other
• "Legal Counsel" and "Legal Client" describe the same relationship from different table perspectives
• Every role has a clearly named reciprocal

---

Creating Connection Roles: Step-by-Step

You create connection roles through the classic interface in the Power Apps maker portal. The modern solution explorer doesn't yet have a full connection role editor, so you'll navigate through the legacy path.

Accessing Connection Role Configuration

1. Open make.powerapps.com and select your environment
2. Navigate to Settings (gear icon, top right) > Advanced Settings
3. This opens the legacy Dynamics 365 interface. Navigate to Settings > Business Management > Connection Roles

Alternatively, from the maker portal, go to your solution and look for Connection Roles in the left panel under the Objects section. If it's not visible, use Add Existing to find and add existing connection roles, or create new ones from the Advanced Settings path.

Creating the "Project Sponsor" Role

Let's walk through creating the first role in detail. The rest follow the same pattern.

1. From the Connection Roles list, click New
2. Fill in the Name field: Project Sponsor
3. Set Connection Role Category to Stakeholder
4. In the Description field, enter something meaningful: The client-side executive who champions and sponsors this project engagement. Good descriptions matter — users see them in the connection role picker.
5. Save the record (don't close it yet — you'll add table restrictions next)

Adding Table Restrictions

With the Project Sponsor role record open:

1. In the subgrid at the bottom labeled Record Types (or Connection Role Object Type Codes), click Add New Record Type or the + button
2. In the dialog, search for and select Contact
3. Save
4. Add a second record type: Project (your custom table)
5. Save

This means "Project Sponsor" can only be the role for a Contact record when that contact is connected to a Project record. The system won't allow a user to assign "Project Sponsor" to an Account-to-Account connection.

Creating the Reciprocal "Sponsored Project" Role

1. Create a new connection role: Sponsored Project
2. Category: Stakeholder
3. Description: A project for which this contact serves as the client-side sponsor.
4. Add table restriction: Project (only)
5. Save

Linking the Reciprocal Pair

Now go back to the Project Sponsor role record:

1. Find the Reciprocal Connection Role lookup field
2. Set it to Sponsored Project
3. Save

Then open the Sponsored Project role and set its reciprocal to Project Sponsor. The relationship is bidirectional — both roles need to point to each other.

Repeat for All Roles in Your Taxonomy

Following the same process, create all the roles from your taxonomy table. Pay particular attention to the "Reports To" / "Manages" pair — since both roles involve Contact-to-Contact connections, each role should have only one table restriction: Contact.

---

Creating Connections Between Records

With roles configured, let's create actual connections in the app. Understanding the end-user experience helps you design better forms and troubleshoot issues.

From the Connection Subgrid

In a model-driven app, connections appear in the Connections subgrid, which is a standard system subgrid available on any form for a table with connections enabled. If you followed the guidance in Designing Model-Driven Forms: Sections, Tabs, Subgrids, and Quick View Forms, you know how to add subgrids to forms.

To add the Connections subgrid to your Project form:

1. Open the form editor for your Project table's Main form
2. Add a new tab or use an existing one — connections often go in a "Relationships" or "Team" tab
3. Insert a subgrid
4. Set the Table to Connections (connection)
5. Set Default View to All Connections or create a custom view filtered to your project-specific roles
6. Save and publish

When a user opens a Project record and clicks the + button in the Connections subgrid, the connection dialog opens. The user selects:

• Connect To: The record they're connecting (e.g., a Contact named "Sarah Chen")
• As This Role: The role Sarah plays in relation to the project (e.g., "Project Sponsor")
• This Record's Role: What the project is called from Sarah's perspective (e.g., "Sponsored Project" — this auto-populates if you've set up reciprocal roles correctly)
• Description: Optional free-text note
• Start Date / End Date: Optional date range

After saving, the connection appears in the subgrid on both the Project record and the Contact record.

---

Querying Connections with Advanced Find and Views

The Connections subgrid shows connections for a single record. But you'll often need cross-record views: "Show me all contacts who are Project Sponsors across all active projects" or "Show me all projects where we have no named sponsor."

Building a Custom Connections View

Because the connection table is a standard Dataverse table, you can query it in Advanced Find and build views on it. Navigate to Advanced Find in your model-driven app, and choose Connections as the primary table. You can then filter on:

• Record 1 Role (Connection Role) = Project Sponsor
• Record 2 (Project) Status = Active

This gives you a flat list of all Project Sponsor connections. You can add columns for the connected record names and export or surface this in a dashboard.

Using Connections in Power Automate

You can also query connections programmatically. In a Power Automate flow using the Dataverse connector, use List rows on the connections table with a filter like:

record1roleid/connectionroleid eq 'YOUR-CONNECTION-ROLE-GUID'
and statecode eq 0

Replace YOUR-CONNECTION-ROLE-GUID with the GUID of your Project Sponsor connection role (find it in the URL when you open the role record in the legacy interface). This returns all active connections where Record 1 is playing the Project Sponsor role.

To get the GUID cleanly, open the connection role in the Advanced Settings interface and look at the browser URL — it contains the connection role ID in standard GUID format.

---

Surfacing Connections in Context: Form Design Strategies

Raw connection subgrids show everything — every connection on the record, regardless of role. In a complex app, this becomes overwhelming. You want users to see structured, role-specific panels, not a generic list of associations.

Filtered Subgrids by Connection Role

The Connections subgrid supports filtering, but the native filter doesn't easily filter by connection role in the standard form editor. A practical workaround is to create custom views on the Connection table that pre-filter by role:

1. In Advanced Find, query Connections where Record 1 Role = Project Sponsor
2. Save this as a shared view named Project Sponsors
3. On your Project form, add a Connections subgrid and set its default view to Project Sponsors

This subgrid now shows only the Project Sponsor connections for the current record, giving users a clean "Sponsors" panel rather than a cluttered catch-all list.

You can add multiple such subgrids to a single form — one for Sponsors, one for Stakeholders — each filtered to its relevant role. If you're building a detailed relationship management tab, this approach creates a structured, readable layout that mirrors real business concepts. Review the guidance in Designing Model-Driven Forms: Sections, Tabs, Subgrids, and Quick View Forms for the mechanics of tab and subgrid layout.

Using the Timeline for Connection Context

The Timeline control on forms automatically logs connection creation events as activities. This means when a new sponsor is added to a project, that association appears in the timeline with a timestamp and the user who created it. For audit-conscious clients, this is valuable — it gives you a record of when relationships were established without any custom configuration.

---

Security Considerations for Connections

Connections introduce a non-obvious security dimension: users need privileges on both the connection table and the connectionrole table to create and manage connections. Out-of-the-box security roles include connection privileges, but custom security roles often miss them.

Required Privileges

For a user to create connections, they need:

Table	Privilege	Minimum Level
Connection	Create	User
Connection	Read	User
Connection	Write	User
Connection	Delete	User
Connection Role	Read	Organization
Connection Role	Append	Organization
Connection Role	Append To	Organization

The Connection Role table requires Organization level read because roles are shared across the entire environment — they're not owned by individual users or business units. If a user has only User-level read on Connection Roles, they won't see any roles in the connection picker.

Who Can Manage Connection Roles?

Connection role records themselves (the definitions, not the connections) can only be created and modified by users with the System Customizer or System Administrator security role. End users cannot create new connection role types at runtime — they can only use the roles you've defined. This is appropriate: you don't want users inventing ad-hoc role types that undermine your taxonomy.

---

Hands-On Exercise

Let's put this all together. You'll build the complete connection role configuration for the professional services scenario and wire it into a model-driven app form.

Setup

1. Ensure you have a custom Project table in your environment with connections enabled
2. Open your model-driven app solution

Part 1: Create All Connection Roles

Following the taxonomy table from earlier, create all seven role pairs. For each pair:

• Set the name, category, and description
• Add the appropriate table restrictions (refer to the taxonomy table)
• After creating both roles in a pair, link their reciprocals

Work through the pairs in this order (it's easier to link reciprocals if both exist first):

1. Create all seven role names as separate records first
2. Then go back and set reciprocal links
3. Then add table restrictions to each

This ordering avoids the frustration of trying to set a reciprocal to a role that doesn't exist yet.

Part 2: Create Test Connection Records

Open a Contact record (create a test contact if needed — "Sarah Chen, Project Consultant"). Open the Connections subgrid on the Contact form (it should be there by default on system Contact forms). Create a connection:

• Connect To: your test Project record
• As This Role: Project Sponsor
• This Record's Role: Sponsored Project
• Description: "Primary executive sponsor for Q3 engagement"
• Start Date: today's date

Save and verify the connection appears in the subgrid on both the Contact and Project records, with the correct role label on each end.

Part 3: Add Role-Specific Subgrids to the Project Form

1. Open the Project table's Main form in the form editor
2. Add a new tab named "Relationships"
3. In the tab, create two sections: "Sponsors" and "Stakeholders"
4. In the Sponsors section, insert a subgrid:
   • Table: Connections
   • Default View: All Connections (you'll filter by view later)
   • Label: "Project Sponsors"
5. Repeat for Stakeholders
6. Save and publish

Then in Advanced Find, build a Project Sponsors view on the Connection table filtered by the Project Sponsor connection role, save it, and update the subgrid to use it as the default view.

Part 4: Verify Security

Create a test security role that mirrors what your app users will have. Ensure it includes:

• Connection: Create, Read, Write, Delete (User level)
• Connection Role: Read, Append, Append To (Organization level)

Assign this role to a test user and confirm they can create connections with roles using your app.

---

Common Mistakes & Troubleshooting

Mistake 1: Reciprocal Roles Set Only on One Side

Symptom: When you view a connection from Record 2's perspective, the role label is blank or shows the wrong name.

Fix: Open both connection role records and ensure each one's Reciprocal Connection Role field points to the other. The linkage must exist on both sides.

Mistake 2: Table Restrictions Too Broad

Symptom: Users can assign "Project Sponsor" to Account-to-Account connections, creating nonsensical data.

Fix: Add explicit table restrictions on every production connection role. Audit existing roles using Advanced Find on the Connection Role table and check which ones have no associated Record Types.

Mistake 3: Empty Role Picker for End Users

Symptom: Users open the connection dialog and see no roles in the dropdown.

Fix: Check the user's security role for Connection Role: Read at Organization level. Also verify that your connection roles are in an Active state (check the status in the connection role list view).

Mistake 4: Connections Not Appearing on the Correct Table's Form

Symptom: You created a connection, but the subgrid on the second record shows nothing.

Fix: Verify connections are enabled on that table. Then check whether the subgrid's view is filtering in a way that excludes the record. The default "All Connections" view should show both sides, but if you've customized the view's filters, double-check the filter logic.

Mistake 5: Connection Roles Not in Your Solution

Symptom: You created connection roles in your dev environment, but they don't appear in the target environment after solution import.

Fix: Connection roles must be explicitly added to your solution. In the solution editor, go to Add Existing > Connection Role and add all the roles your app depends on. They are not automatically included just because you created them while working in the solution context.

Mistake 6: Assuming Connections Support Cascade Behavior

Symptom: You delete a Project record and expect all its connection records to delete automatically.

Fix: Standard cascade delete does not apply to connections the same way it does to standard relationships. You'll need a Power Automate flow or a plugin to clean up connection records when the primary record is deleted, if that's a business requirement. Plan for this explicitly in your data lifecycle design.

---

Summary & Next Steps

Dataverse connection roles give you a flexible, user-managed way to model party-to-party associations that don't fit neatly into the fixed-schema world of standard table relationships. The core pattern is clear: define role pairs with meaningful names, link reciprocals, restrict to appropriate tables, surface through filtered subgrids, and secure with correct privileges on both the Connection and Connection Role tables.

The professional services scenario we worked through — project sponsors, stakeholders, legal counsel, and reporting relationships — illustrates the kind of real-world complexity that connections are designed to handle. A contact can be a sponsor on one project and a stakeholder on another; an account can have legal counsel from an external firm; contacts can have management relationships that are tracked separately from their organizational hierarchy. All of this lives in runtime data rather than schema, which means your data model stays clean and your users can evolve the relationship landscape without needing a developer.

Where to go from here:

• If you need to model even more complex role-based access patterns around these connections, explore Model-Driven App Security: Configuring Security Roles, Field Permissions, and Team-Based Access for Table Data for fine-grained access control
• If your connection records need to trigger business logic (e.g., notifying a contact when they're added as a sponsor), review Configuring Dataverse Plug-in Steps and Business Event Handlers: Triggering Server-Side Logic on Table Operations for server-side event handling on the connection table
• For many-to-many scenarios that require connection attributes beyond what the system Connection table provides (e.g., a "role level" or "commitment percentage" per connection), consider Configuring Dataverse Many-to-Many Relationships with Intersect Tables in Model-Driven Apps: Custom Junction Table Attributes, Filtered Subgrids, and Advanced Relationship Behaviors — custom intersect tables give you schema-level control that the connection table can't match

Connection roles are one of those features that experienced makers often overlook in favor of building custom junction tables, but once you've used them correctly, you'll recognize how much unnecessary complexity they can eliminate from your data model.