Link items across lists — with real relationships.

Key capabilities

• Typed relationships — Related to, Blocks, Blocked by, Duplicates; enable any combination.
• Bidirectional — linking A → B automatically shows the reciprocal link on B.
• Search to link — find items across one or more target lists; already-linked items are grayed out.
• Inline table — shows relation type, direction (incoming/outgoing), and the fields you choose.
• View linked items — open any linked item read-only in a side panel; group by list and customize labels (multi-language).
• Cross-site-collection linking — connect items across site collections. (Enterprise)

1. Decide what can be linked, and how

   Tick the lists users are allowed to link to — any list or library in the site, and on Enterprise, across site collections. Then choose which relation types they can use: Related to, Blocks, Blocked by and Duplicates ship as standard, and you can add your own vocabulary alongside them.

   The lists that store the connections are created for you. They are plumbing rather than content, so there is a switch to hide them from Site contents — they keep working, they just stop cluttering the site for everyone else.

   

2. Each list shows its own columns

   A linked purchase request and a linked vendor are not the same kind of thing, so they should not be summarized the same way. Expand a target list and tick the columns that identify an item from that list, then set the order they appear in. Requests are worth showing with who raised them and where they got to; a vendor is better described by what it supplies. You will see both sets of choices come through further down.

   

3. Find the items, name each relationship

   Pick a list, search it, and tick what you want. Selections collect as chips at the top and survive switching lists, so a vendor and a related request can be gathered in one pass and committed together rather than one dialog at a time.

   The relation type is set per row, not per batch — so the same pass can attach one item as Related to and another as Blocks. That is what keeps the vocabulary meaningful instead of everything defaulting to a generic link.

   

4. Grouped by list, typed, and pointing somewhere

   Back on the form, links sit in their own table grouped under the list they came from, each group showing the columns chosen for it in step two — the request group carries requester and status, the vendor group carries category. Every row states its relation type and carries a badge for direction.

   

5. The other item already knows

   Open the item on the receiving end and the link is already waiting there. Same relation type — still Duplicates, not silently rewritten into something else — with the direction flipped to Incoming. Nobody recorded it twice, and the rejected request now carries the reason it was rejected: the order it duplicates, one click away.

   That is the difference between a real relationship and a pair of lookup columns pointing at each other. The connection is stored once and read from both ends, so the two sides cannot drift apart, and a link made by someone working on one item is visible to whoever opens the other. Each row also opens the linked item read-only in a side panel, so checking a detail never means leaving the form you are in.