Connection records in Dataverse

The standard way to relate records in Dataverse is through lookup fields — a Customer field on an Opportunity, a Manager field on a User. Lookups are 1:N relationships with fixed semantics. But sometimes the relationship is dynamic, has multiple flavours, or doesn't fit a standard hierarchy. Connection records are Dataverse's flexible record-to-record relationship mechanism for these cases.

The model. A connection is a special record linking two other records:

• From record — one endpoint.
• To record — the other endpoint.
• Connection role — defines what the relationship is.
• Start date and end date — when the connection is effective.
• Description — optional context.

Connections work between any two records in Dataverse — the from and to can be different tables, the same table, even different types of relationship.

Connection roles. A connection role is a named relationship type. Each role has:

• Name — Sponsor, Influencer, Partner, Mentor, Competitor, Stakeholder, Spouse.
• Reciprocal role name — what the reverse relationship is called. "Sponsor" might pair with "Sponsored By"; "Manager" with "Reports To".
• Permitted record types — which tables the role can connect (e.g. role "Influencer" can connect a Contact to an Opportunity).

When you create a connection, you pick the role; the system automatically creates the reciprocal connection from the to-side.

Use cases.

• Influencer mapping in B2B sales — A buyer has multiple stakeholders involved in a decision: an Economic Buyer, a Technical Influencer, a Champion, a Blocker. Each is a contact connected to the opportunity through specific roles. The seller can see at a glance who's in the deal and what they do.

• Competitor tracking — An opportunity has 1-3 competitors. Each is an Account record connected to the opportunity with role "Competitor". Reports show win rate against specific competitors.

• Mentor relationships — Internal mentorship pairings between employees, with role "Mentor" / "Mentee". The HR system tracks who mentors whom.

• Customer-to-customer relationships — In a network business (industries with referrals, partnerships), customers refer each other; each referral is a connection with role "Referred By".

• Spouse / family relationships — In wealth management or insurance, related individuals (spouse, dependents) connect through family roles.

Filtering and querying.

Each record has an associated subgrid of connections on its form — typically labelled "Connections" or similar. The user adds, edits, deletes connections inline.

Queries can filter:

• Connections of a specific role.
• Connections to records of a specific type.
• Active vs expired connections.
• Connections with specific date ranges.

Reports can analyse: "show me all opportunities with at least one Influencer connected" or "show me competitors I've won against in the last year".

Configuration. Connection roles are configured per environment:

• Create roles for the relationships your business cares about.
• Define reciprocal pairs.
• Specify permitted record types per role.

Common starting roles: Sponsor / Sponsored By, Partner / Partnered With, Spouse / Spouse, Manager / Direct Report, Mentor / Mentee, Influencer / Influenced.

Vs many-to-many relationships.

• N:N relationship — defined in the schema; binary (associated or not).
• Connection — flexible, role-based, with timeline and additional attributes; ad-hoc per record-pair.

Connections suit relationships that aren't structural enough to warrant schema-level N:N — relationships that emerge from specific business events.

Vs custom intersection entities.

• Custom intersection entity — heavy modeling; full audit, security, lifecycle on the intersection record. Best for complex relationships with substantial structural meaning.
• Connection — lighter; pre-built form, less customisation.

For most "ad-hoc relationship" needs, connections suffice; for structural relationships with rich data, a custom intersection is better.

Limits.

• Connections aren't shown on the main timeline by default — they live in their own subgrid.
• Audit history on connections is limited compared to first-class entities.
• Reporting depth — connection-based reports can be complex; not all tools handle them cleanly.
• No native cascade delete from parent — deleting the source record doesn't automatically delete its connections in some scenarios.

Common pitfalls.

• Connection sprawl — too many ad-hoc connection roles produces an inventory that's hard to govern. Limit to meaningful roles.
• Connections used where lookups would suit — standard 1:N lookups are simpler and more performant; reach for connections only when the dynamic / role-based aspect matters.
• Stale connections — relationships end; nobody updates the end date; reporting shows wrong current state.

Operational reality. Connections are an underused Dynamics 365 feature that solves real B2B sales and relationship-mapping problems. Configure thoughtfully; use them where they genuinely model the business; report on them to extract value.