What it does

Relationships define how rows connect to each other. Dataverse has exactly two kinds — one-to-many and many-to-many — and the N:1 you see in the designer is just a 1:N viewed from the child side. Adding a lookup column creates the 1:N relationship for you.

Key facts

• N:N relationships use an intersect table. You get no columns of your own on it, so anything you want to record about the association means modelling a proper junction table with two lookups instead.
• Cascading behaviours are set per action: Assign, Reparent, Share, Unshare, Delete, Merge and Rollup View. The options are Cascade All, Cascade Active, Cascade User-Owned, Cascade None, Remove Link and Restrict, and not every option is valid for every action.
• Delete only offers Cascade All, Remove Link or Restrict. There's no "cascade active deletes" option.
• A relationship counts as parental if Assign, Reparent, Share or Unshare use one of the Cascade options, or if Delete is Cascade All. A child table can only have one parental relationship pointing at it.
• A custom table can't be the primary table in a cascading relationship with a related system table. You can't set Cascade All, Cascade Active or Cascade User-Owned in that direction.
• Cascading actions don't fire if the requested value already matches, or if the parent row is already mid-cascade from another operation.
• Assigning a row automatically deactivates any workflows or business rules currently running on it. The new owner has to reactivate them.
• Switching Reparent or Share from a cascading setting to Cascade None triggers an inherited access rights cleanup system job, which strips inherited access but leaves directly granted access alone.
• Connections are the informal alternative — named links like spouse or former employer, set up through connection roles, with optional reciprocal matching roles. The table needs Can have connections enabled first.

When to use / skip

Model a formal relationship when the link is structural, queryable and something you'd report on — an opportunity without a customer is meaningless, so that's a lookup. Use connections for the soft stuff nobody filters on: who knows whom, who used to work where. The test I use is whether anyone will ever write a view or a report against it. If the answer is no, connection roles keep it out of your schema. And if the association itself has attributes — a start date, a percentage, a role — skip N:N entirely and build the junction table, because you'll want those columns within a month.

Configuration decisions

• Which relationship is the parental one for each child table, since you only get one and it dictates how sharing and ownership flow.
• Delete behaviour per relationship: Restrict to protect referential integrity and force users to clean up, Cascade All to tidy children automatically, Remove Link to orphan them.
• Whether Share cascades, which is the quiet decision that determines how far a single share reaches through your data.
• Whether Assign cascades to all children, active children only, or only those owned by the previous owner.
• N:N versus junction table, decided on whether the association will ever need its own data.

Gotchas

• Cascade All on Delete is a loaded gun. Deleting one parent account can remove thousands of descendant rows across several levels, and there's no confirmation that tells the user how far it reaches.
• Share cascading is how "why can this user see everything?" happens. One share on a parent propagates down every cascading relationship, and it's not visible anywhere obvious.
• Turning cascading off doesn't retract access on its own — the cleanup job does, asynchronously, and it can fail. Don't assume the permission is gone the moment you save.
• The single-parental-relationship rule bites when you add a second lookup later and find you can't configure it the way the first one is. Customer lookups and activity regarding lookups are the documented exceptions.
• A lookup leaks the related row's primary name. Anyone who can read the row holding the lookup sees the related record's ID and its primary name value, whether or not they have read access to the related record itself. Dataverse documents this as by design, so never put anything sensitive in a primary name column — a contract reference, a case subject, a person's name on a restricted table.
• N:N relationships give you no place to store anything about the link, and converting to a junction table afterwards means migrating the intersect data by hand.

Consultant notes

• Document the cascade matrix for every custom relationship as a deliverable. It's the single most under-documented part of most Dataverse builds and the first thing you'll wish you had during a security investigation.
• When a client asks for "just delete the parent", ask what should happen to five years of child records. They usually mean deactivate, not delete.
• Warn that assign cascades can generate enormous background workloads. Reassigning a territory of accounts with Cascade All on activities is not a lunchtime job.
• Connection roles are solution-aware but their status isn't — imported roles come in active regardless of how they left. Check after deployment.

---

Revisit if the data workspace designer gains support for many-to-many, or if cascade behaviour picks up new options.