SharePoint permission relationships Melbrooke Ltd (2026-10-01)

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 lines from the site out to the Library and Unique permissions columns are the path down to each item - one line per item, coloured by the strongest access into it - and a dotted line is a direct (individual) grant rather than access through a group. Where one card meets many. Most lines are curves from one card to the next. Where the space between two columns is so crowded that its curves would lie on one another as a solid bar - more than 300 of them within one screen's height, as when a site has thousands of shared files or a person reaches hundreds of sites - every line there is drawn instead as a short trunk from its card to one straight vertical line per colour and style, and a branch from that line to the card at its other end: every card keeps its own branch in its own colour, thickness and style, so nothing is left out. Lines of one colour and style in that space share one vertical line, so which card a branch comes from is read by hovering a site (in a person or group view) or clicking a card, not by following the line. Wherever the space is less crowded than that, the curves stay exactly as they are.

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). Site administrators are set aside. SharePoint lists a site's administrators - the owners of its Microsoft 365 group, drawn as the Site Admin node - on every item that has its own permissions and never on the site's own permission list, so they are not counted when an item is compared with its site: an item that differs only by them reads same as site, and the change panel lists them on a row of their own rather than as a change. Another site's owners group granted on an item is a real difference and is counted. Other site collection administrators. Any other site collection administrator - an IT group added to every site, for example - is listed the same way, so it is drawn once, as Full control on the site, and set aside like the owners, never as a grant on every library holding a shared item; the Evidence table says whether it was read from the site's own admin list or inferred from that pattern. 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. Where the library's own permission list and its site's were both read, and the site's list grants anyone directly, the card also says how the two LISTS compare: own list same as its site (the library stopped inheriting but its own list still grants exactly what the site's does - often left over from a migration or a script) or own list differs from its site (the one worth reviewing). The comparison is of the two lists only: grants that reach the library from items inside it are drawn on the card but not compared. Plain holds permissions means no comparison was made - one of the two lists was not read, the library has no list of its own, or the site's own list grants nobody directly. 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. Permissions not read means the library's own permission list could not be read, so whether it holds permissions of its own is unknown - not empty; where grants on it were captured anyway, the card reads holds permissions · list not read, because the list behind them was not. 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. When this view has nothing left for it to add, the control greys out and says why in brackets; a tick carried in from another view stays ticked. 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 are the distinct places its access touches: the site itself, a library, a folder or a file each count once. They come in two kinds, and every count shows both. A place adds access when the principal holds nothing as strong there already; a library or an item repeats access when the principal already holds the same level or stronger on its site or its library, or administers the site - a broken-inheritance copy of access it has anyway. A site the principal administers counts once, as a place that adds, although administration is not an entry on the site's own permission list. A repeat is still a real permission entry, and it stays in the Evidence table and in the spreadsheets, but it gives nothing new. So a card reads 12 scopes +340 repeat: twelve places where this access is what lets the principal in, and 340 more that repeat what it already holds. "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: 6 of the places where its access adds are on the focused site, 43 across the whole estate - the count is estate-wide, the map shows one site at a time - and any repeats beside it are the estate-wide figure, which the card says (+340 repeat estate-wide). The 50+ scopes card in Discrepancies counts people by the places that add, shows the repeats beside each name, and lists separately anyone who reaches 50 or more places only by repeating access they already hold. Thicker lines mean a principal adds access in more places overall - line width scales with that count, so the widest bands are the accounts to review first, and a site administrator whose thousands of item entries only repeat the site it administers does not drown out everything else. 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. A card tagged signed in is the account this assessment signed in with to read the SharePoint groups and permission lists: what is drawn for it is access the estate gives that account, marked so you know whose it is rather than set aside.

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, or the whole site could not be deep-read and no Microsoft 365 group shows who is in it; 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), everyone internal, everyone incl. guests and broad-access claim (on a principal that is a SharePoint claim, not a group, and has no membership list: “Everyone except external users” is every internal user; “Everyone” is every user including external guests; and a map that did not record which of the two a claim is says so rather than guessing - wherever one holds access, everyone it covers has it), 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.