## Why It Matters

Module access is all-or-nothing: give someone Security access and they see every report; give them Outreach and they see every campaign. Sometimes that's too wide. A sensitive report or a high-stakes campaign should be visible only to the few people running it — and some of those people should be able to *manage* it while others only *watch*.

**Item-level access** gives you both controls on a single item:

- **Restrict** it, so only handpicked teammates (and module admins) can see it.
- **Grant** each of those teammates a role — **Member** to view, **Lead** to manage.

It's the finest layer of access, sitting on top of the two broader ones.

## How This Fits With Roles and Modules

| Layer | Scope | Where you set it |
|-------|-------|------------------|
| [Team role](/docs/team-roles) | The whole account | **Settings → Team**, on the member |
| [Module level](/docs/team-access-control) | A whole product (Hiring, Security, Outreach, Training) | The Modules matrix |
| Item-level access | One specific report or campaign | On the item, or from the member's access page |

Two independent controls make up this layer:

- **Restriction** decides *who can see the item*. An open item (the default) is visible to everyone with the module; a restricted item is visible only to its grantees and module admins.
- **Grant role** decides *what a grantee can do* once they can see it.

> [!NOTE]
> Item-level access adds reach **inside** a module — it never replaces module access. A grantee still needs at least **Member** access to the item's module (Security for reports, Outreach for campaigns) for the grant to take effect. Without it, the grant sits dormant in their access ledger and does nothing until you raise their module level.

## Open vs. Restricted

Every report and campaign starts **open**: anyone with the module can see it, exactly as before. Restriction is opt-in, item by item — nothing changes for your existing items until you decide to lock one down.

Open the item and find its **Access** section. It shows whether the item is open or restricted, with a button to switch:

- **Restrict access** — hides the item from everyone except its grantees and module admins. Grant the right people first (or right after), so no one who needs it loses sight of it.
- **Remove restriction** — reopens the item to everyone with the module.

Only **module admins** can restrict or reopen an item.

## Granting a Role

In the same **Access** section, click **Grant access**, pick the **Team member**, choose a **role**, and confirm with **Grant**. The new row appears right away.

What each role can do depends on the item:

| | **Member** grant | **Lead** grant |
|---|---|---|
| **Security report** | See it, and take part — assess, message, share, link references | Everything a Member can, **plus** triage, assign, and manage who else has access |
| **Outreach campaign** | See it (read-only) | See it, **plus** edit, update, and manage who else has access |

Module admins can always grant. On a security report, a **Lead** can also grant — so a lead can pull in exactly the help they need without waiting for an admin.

## Granting From a Member's Page

When you're already looking at a person — say, setting up someone to run a specific item — grant from their side instead. Go to **Settings → Team → Members**, open the member, and click **Grant access…** above their access ledger. Pick the report or campaign, choose the role, and confirm. The grant lands in their ledger immediately; their module access stays exactly as it was.

## Reading and Revoking Grants

The [access ledger](/docs/team-access-control) on a member's page lists everything they can touch. Each item-level row tells you:

- **Granted by** — who created it, so an audit has a name, not just a date
- **Granted** — when it happened
- **via module admin** — a row with this badge isn't an individual grant: the person reaches the item because their module level is Admin. These rows have no revoke button — to remove that access, lower their [module level](/docs/team-access-control) instead.

Every real grant has its own **Revoke** button, on both the item's **Access** section and the member's ledger. Revoking one only removes that item — module levels and any other grants are untouched. At offboarding, **Revoke access…** on the member's page clears every module level *and* every grant in one step, as described in [Team Access Control](/docs/team-access-control).

## Quick Checklist

- [ ] Restrict only the items that genuinely need a smaller audience — leave the rest open
- [ ] Grant the right people **before** you restrict, so no one loses access mid-work
- [ ] Use **Member** for people who only need to watch, **Lead** for people who run the item
- [ ] Confirm a grantee has at least **Member** access to the item's module, or the grant stays dormant
- [ ] At audit time, read the **Granted by** column — every grant has an owner
- [ ] Don't hunt for a revoke button on **via module admin** rows — adjust the module level instead
- [ ] Before offboarding, remember **Revoke access…** clears all grants at once