What it does

Relationships are the foreign-key links that let Customer Insights walk from a unified profile out to tables that were never part of unification — purchases, stores, products, subscriptions — and back again. The path taken between two tables decides what a segment or measure can actually see, and how many records come back.

Key facts

• Three kinds exist. System relationships are created by unification between the Customer table and each participating source table, with generated key fields like Contact_contactID. Inherited relationships are created at ingestion from relationships that already existed in the source. Custom relationships are the ones you create. Only custom relationships are editable.
• Custom relationships are defined on Data > Tables > Relationships with a name, source and target table, source and target key field, and a cardinality on each side.
• Supported cardinalities are many-to-one and one-to-one. Many-to-many is not native — you build it from two many-to-one relationships through a bridge table.
• Relationship names are case-sensitive, which matters when other configuration references them by name.
• A relationship path is the chain of tables between source and target. Paths are classified as direct, multi-path (source reaching several targets), indirect, multi-hop, and multi-hop multi-path.
• Longer paths return fewer records, because a customer has to exist in every table along the chain. Shorter paths return more. This is the single most important behaviour to understand before debugging a segment that "lost" people.
• When more than one path exists between two tables, the segment or measure builder makes you pick one. That choice changes the result set, silently and substantially.
• The relationship visualiser draws the table graph as a network diagram with cardinality shown, supports horizontal or vertical layout, and exports as an image.
• Activities cannot use inherited relationships. They need a system or custom relationship to reach a customer table.
• System and inherited relationships can be viewed but not modified or deleted, so a bad inherited relationship has to be fixed at the source or worked around with a custom one.

When to use / skip

You need custom relationships the moment a requirement mentions an attribute that lives two tables away from the customer — "customers who bought coffee from a London store" needs Purchases to Stores, because store location is not on the purchase row. That pattern shows up on almost every retail, hospitality or field service project.

You can skip custom relationships entirely on a straightforward implementation where every table participates in unification and all the attributes people want to segment on are already on the profile or on a directly related activity table. That is more common than people expect, and building speculative relationships "for later" just adds paths that confuse the segment builder.

Configuration decisions

• Which tables need to be reachable from the profile at all. Every relationship you add is another path the segment builder will offer, so keep the graph deliberate.
• Cardinality on each side. Getting this wrong does not always error immediately; it shows up as wrong counts in a measure weeks later.
• Naming convention. SourceToTarget reads well, is case-sensitive, and gets referenced elsewhere — agree it once and hold to it.
• Whether a genuine many-to-many needs a bridge table built in Power Query at ingestion, and who owns that table.
• Whether to rely on inherited relationships from a source system or replace them with explicit custom ones you control — worth doing where the inherited definition is unclear or the source schema is volatile.
• Which path is the canonical one for each recurring analytical question, documented so different builders do not pick different paths and produce different numbers.

Gotchas

• Two people building "the same" segment down different paths get different counts, both correct, and the resulting credibility problem is entirely avoidable with a documented path convention.
• Path length quietly filters. A four-hop path only returns customers present in all four tables, which can drop a segment by an order of magnitude with no warning or error.
• You cannot edit or delete system and inherited relationships. If unification produced a link you do not want, the fix is upstream.
• Case-sensitive names bite when a relationship is recreated by hand after a deletion and the casing changes. Activity configuration referencing the old name will not find it.
• Many-to-many via a bridge table is a data engineering task, not a UI task. Budget for it rather than discovering it mid-sprint.
• Deleting a custom relationship that segments, measures or activities depend on breaks them. Check the visualiser and the dependent artefacts before removing anything.

Consultant notes

• Open the visualiser with the client's data architect in the room during design. It surfaces missing links and surprise inherited relationships faster than any amount of documentation review.
• Write down the canonical path for each key business question and keep it with the segment definitions. This is the artefact that stops the "why do we have three different customer counts" meeting.
• When a segment returns far fewer customers than expected, check the path before you check the filters. It is the path nine times out of ten.
• Push back on requests to relate everything to everything. A dense graph makes the builder harder to use and multiplies the ways two people can disagree.
• Before go-live, confirm no measure or segment depends on a relationship that only one person understands. Relationship knowledge is the most common single point of failure handed over at the end of a CI project.

---

Worth another look if many-to-many becomes natively supported, or if path selection in the segment builder changes.