SharePoint permission relationships Melbrooke Ltd (2026-08-18)

Reading the colours. Access level is blue Read, amber Edit, red Full control. A principal's coloured dot shows the highest level it holds anywhere in view - so a group that is only Read on the site but Full on one item still shows a red dot, flagging that elevation. Each line is coloured for its own specific connection, so a dot and a line can legitimately differ when a principal's access varies across items - the dot is the worst case, the line is the detail. The grey lines from the site out to the Unique permissions column are structural - the path down to an item, not a permission - and a dotted line is a direct (individual) grant rather than access through a group.

Broken inheritance. SharePoint sites and libraries inherit their permissions by default, so every item in the Unique permissions column is an exception where that inheritance was broken. Usually no one did this on purpose - sharing a file or folder with a specific person silently breaks its inheritance and adds them directly. Access differs (red outline) means the item really grants different access than the site, so it is worth reviewing. Same as site (grey) means a frozen copy of the site's permissions - harmless today, but detached, so it won't track future site changes (drift risk). Why the site's groups still appear on a single file: when inheritance breaks, SharePoint copies the site's groups (Owners / Members / Visitors) onto that item as the starting point, then changes are made from there - so those groups genuinely still reach the file. Click any carve-out to isolate it: the lit lines are everyone who can reach it, routed through the site; access differs flags what changed from that copied baseline, not that the groups were removed.

The Library column. Between a site and its carve-outs sits the Library column, one card per document library. Every card says what that library is, and because that is a fact about the library rather than about the view, that phrase is on the card in every view - hover any card whose text runs past its edge to read the whole line. Holds permissions means the library itself carries a permission entry: someone was granted access to that whole library, so everything inside it is included and the library is a real access target in its own right. Contains shared items means the library holds no permissions of its own - none anywhere on the estate, not merely none here - and is drawn only to show where the shared files and folders beside it live. What changes from view to view is which libraries are drawn: a library appears on its own whenever a principal in view holds a permission on it, and ticking Show containing libraries adds every library that a carve-out in view sits inside. That second set is mostly structural, but not always - it also brings in a library that holds permissions whose holders are outside this focus, and its card still says so. The control switches itself off when this view has nothing left for it to add. So a library that holds permissions can still be absent from a view whose principals do not hold them; nothing is hidden, it is simply not part of that picture. Where a shared file or folder sits inside a document library, its own card names that library - for example Folder · access differs · in Documents. A carve-out can also sit outside any document library (a page, a list), and those cards name no location because there is none to name. Documents is the default name for the main library of every site, so where a name would be ambiguous the site is named too: a library card swaps the word Library for its own site and keeps its phrase - Finance · contains shared items - and a shared item whose library name is shared with another library in view reads Folder · access differs · in Finance > Documents - site first, then library, as SharePoint itself writes it. The exception marker is deliberately kept ahead of the location, so that when a long name runs past the edge of the card it is the location that shortens, never the finding; hovering the card shows the whole line.

Grants, scopes, and line thickness. A grant is one permission entry: this principal, at this access level, on this place - one row in the Evidence table. A principal's scopes count is how many distinct places its access touches: the site itself, a library, a folder or a file each count once. So "Security group · 1 scope" means that group's access exists in exactly one place (on this estate, typically its own library - deliberate compartmentalisation, which is good practice). A card can also read 6/43 scopes: its access touches 6 places on the focused site, 43 across the whole estate - the count is estate-wide, the map shows one site at a time. Thicker lines mean a principal reaches more places overall - line width scales with its scope count, so the widest bands are the accounts to review first. Line colour is always the access level, and a dotted line is an individual (direct) grant rather than access through a group. The Principals column is grouped by reach: site-wide access (holds a permission on the site itself), library access (granted into specific libraries only), then item-level only (reaches nothing but specific shared files or folders - SharePoint's "Limited Access", almost always created by sharing rather than by an admin).

Direct (individual) grants. A dotted line is access given straight to a person, bypassing the site's groups - the hardest kind of access to keep track of. If you see a person here you never added, sharing added them: every time a file or folder is shared to someone (a share dialog, a "specific people" link, an org-wide link they opened), SharePoint silently creates an individual entry for them on that item - no admin action involved. When it sits on a broken-inheritance item, the person is tagged item-level; in SharePoint they show as Limited Access on the site, which is traversal only (they can reach that one item and nothing else on the site). This also means a person can hold BOTH a group route and their own sharing-created entry to the same content - the entries are redundant, and the "still via" tag on a carve-out's change panel calls that out. A long list of direct entries is an over-sharing signal - content handed out file by file instead of through a group; the Sharing per-link report shows exactly what was shared and to whom.

Reading one person on one site (narrowing). A person who reaches a dozen sites draws a dozen fans at once, and where one site opens onto several libraries and then onto folders and files inside them, the curves run together. Two things fix that, and neither loses the person. Hover a site and only that site's own onward lines stay lit - the person to that site, that site to its libraries, and on to the items inside them - everything else fades, so you can see where a single site's access actually goes before touching anything. Click that site and the view narrows to it: the person stays the subject, and the map redraws as just their access on that one site. The focus bar then says so in words - "Jane Smith · within Finance" - and carries the two ways out: × all sites puts the rest of their access back, and Open full site view leaves the person and opens the site's own view (everyone who can reach that site, not just this person). Clicking the same site again releases the narrowing, the same way clicking a highlighted card a second time releases it, and Back returns to the un-narrowed person. Note the Access-differs only tick box applies to a site view rather than a person or group view, narrowed or not; use Open full site view when you want to filter a site down to just its genuine exceptions.

Groups, nesting, and why Owners get an extra node. On a Microsoft 365 group-connected site, the group's members auto-nest into the SP Members group (Edit) and its owners into the SP Owners group (Full control) - so group membership grants site access by default. Owners hold a second, stronger grant members do not: they are also Site admins (site collection administrators), which can reach any item even where inheritance is broken - so an extra Site Admin node on a site is correct, not a duplicate. Each group's membership carries a badge for how we learned it: verified (green - we read the SharePoint group directly and saw the nesting), default (amber - the site could not be deep-read, so members are shown via the matching Microsoft 365 group following SharePoint's default nesting; the mechanism is definitive, but this specific site's nesting is not independently confirmed), not read (grey - reached but the group would not enumerate; unknown, not empty), membership restricted (purple - the group's owner set it to hide its membership from non-members, so no read-only assessment can enumerate it; this is by design and is a governance observation, not a coverage gap), and nesting removed (red - we read the group and the Microsoft 365 group is verifiably no longer nested, so its members do not inherit access). Nesting removed is the one badge that also appears up in the Estate overview, as a red tag on the site's row; purple is used for membership restricted and nothing else.