You have just made somebody Read Only, or Restricted, and the obvious question is the one the interface will not answer from your own account: what will they actually find when they sign in? This page is the map. It covers what disappears from navigation, what the page tree hides, and the two places where the honest answer is “less than you expect” or “more than you meant”.
One distinction to fix first, because it accounts for most of the confusion. A screen hidden by your role is simply not there — no card, no tab, no explanation. A feature blocked by your plan is visible and tells you so, with an upgrade prompt where the feature would be. If a teammate reports a blank space, that is a role question and this page answers it; if they report a prompt, see When a Feature Is Gated.
The rail
The 72-pixel rail down the left edge is the first thing a role changes. Five tabs are defined, and each one carries the privilege that decides whether it renders at all.
| Tab | What it opens | Privilege | Minimum role |
|---|---|---|---|
| Know | Know Dashboard — analytics | analytics:read | Read Only |
| Design | Design Workspace — the page tree and editor | ungated | Anyone |
| Engage | Engage Workspace — contacts and accounts | contact:read | Read Only |
| Plan | Plan Calendar — the schedule | contact:read | Read Only |
| Deploy | Deployment History and Status | deployment:read | Read Only |
That is what makes the rail predictable, and it is also why a Restricted member sees exactly one tab — Design — no matter how much content you have opened up for them. They reach their pages through Design; everything else is gone.
The rail itself — what each tab holds, and how it remembers the section you were last in — is covered in Touring the Workspace. One display quirk to know when you compare notes with a teammate: documentation pages live under Design but do not light the Design tab while you are on one.
Settings
Settings Home is a grid of thirteen cards in four groups. Each card is gated on its own privilege and is either present or absent — there is no grayed-out state, and Leed also skips the count lookup behind a card you cannot see, so an invisible card costs nothing and gives nothing away.
| Group | Card | Privilege | Minimum role | Documented on |
|---|---|---|---|---|
| Workspace | General | company:read | Read Only | General Site Settings |
| Workspace | Team members | user:read | Read Only | Managing Team Members |
| Workspace | Billing & plan | billing:write on the billing resource | Administrator, or the Billing checkbox | Managing Your Subscription |
| Content model | Page types | pagetype:read | Read Only | Page Types |
| Content model | Labels | label:read | Read Only | Labels and Series |
| Content model | Journey stages | journey:read | Read Only | Journey Stages |
| Content model | URL paths & redirects | path:read | Read Only | URL Paths and Slugs |
| Capture & engagement | Forms | form:read | Read Only | How Forms Work |
| Capture & engagement | Emails | contact:read | Read Only | How Email Works in Leed |
| Capture & engagement | Dynamic CTAs | dynamiccta:read | Read Only | Dynamic CTAs |
| Capture & engagement | Recommendations | dynamiccta:read | Read Only | Recommendations |
| Automation & AI | Automations | autolinks:read | Read Only | Autolinks |
| Automation & AI | Search & autolinks | pagetype:read | Read Only | Search for Your Documentation |
Dynamic CTAs and Recommendations are two cards pointing at the same screen, so they appear and disappear together. Every card’s destination, and the rest of the map, is in Settings Home and the Settings Map.
The practical reading of that table: every card except Billing & plan needs only Read Only, so a Restricted member sees Settings essentially empty, a Read Only member sees twelve of the thirteen cards, and the billing card is the one that needs either the Administrator role or the checkbox.
Developer Setup
Developer Setup is not a settings card. It is an item in the profile menu behind your avatar, and it appears only for members who hold developer access — which is the Content Publisher role or above, or the Developer checkbox on their row. Developer access is a checkbox, not a role: see Billing and Developer Access.
The page tree for a Restricted member
Restricted is the only role whose page list is filtered down rather than shown whole. For a Restricted member, Leed reduces the tree to the pages reachable through one of their overrides at Read level or better — an override on the page’s type, an override on the page itself, or an override on any label the page carries — and the result count is recalculated to match.
That last detail matters more than it sounds. The tree is honest: a Restricted member is never shown “148 pages” above a list holding four. What they see and what the count claims agree.
A Restricted member with no override at all, and no byline, has an empty tree. To open a section for them, grant the override on the resource — Resource-Level Access Overrides covers the three pickers — or put them on the byline of the individual pages they are working on.
Pages nobody but their creator sees
There is one filter that runs for every role, Administrator included: a page marked private is dropped from the list for everyone except the person who created it. It is the one case where being an Administrator does not mean seeing everything, and it is worth knowing before you conclude that a page has been deleted.
The flag, how a page gets it and what it means for publishing are covered in Private Pages.
The override side effect
Most permission checks in Leed name the resource they are about — this page, this label, this page type — and only overrides on that resource can satisfy them. A large number do not.
The design intent is defensible — an override holder is a colleague rather than a stranger, and the reads in question are structural: the workspace’s own override list, another member’s profile record, path, form and dynamic-CTA reads, asset reads. It is still not what most administrators picture when they tick one box, so picture it now: the moment you grant a Restricted member their first override, they stop being a stranger to a good part of the workspace. A byline counts too, because the byline grant is assembled as a page-level override like any other.
Contact and lead data is the deliberate exception. Those routes scope their check to the contact resource specifically, so an unrelated page override cannot open them and contacts stay closed to everyone whose role does not qualify. The surface itself is Contacts.
Things roles do not hide
Three cases where the interface implies a boundary that is not really there. None is dangerous; all three generate support questions.
- The team list is not permission-checked. The Team members card is gated, so a Restricted member cannot navigate to the screen — but the underlying list of members is served without a privilege check. Treat the roster as visible to anyone in the workspace, not as secret.
- The Delete item on a team row renders for everyone. Open the ⋮ menu on a member row at any role and Delete is there. Only an Administrator’s click succeeds; everyone else gets a permission error from the server. See Managing Team Members.
Role by role, in one line each
- Administrator — everything: five rail tabs, all thirteen settings cards, every page except somebody else’s private ones.
- Content Publisher — five rail tabs and twelve settings cards; Billing & plan is missing unless the Billing checkbox is ticked. Developer Setup is in their profile menu.
- Content Approver — the same navigation as a Content Publisher, minus Developer Setup, which starts at Content Publisher. The rank itself unlocks no screen of its own.
- Content Writer — five rail tabs and twelve settings cards; they see the whole page tree and can edit pages, but not create, publish or delete them.
- Read Only — the same navigation again: five rail tabs, twelve settings cards, the full page tree. What changes is that every write is refused. This is the role people misjudge — Read Only is a full view of the workspace, not a reduced one.
- Restricted — one rail tab (Design), a page tree holding only what an override or a byline opened, and a Settings screen that is effectively empty. This is the role to reach for when someone should see one corner and nothing else.
Which privilege each of those refusals names is in the Privilege Matrix, and the roles themselves are introduced in Roles and Permissions.