Permission gating surprises
A missing button or a "no access" tile usually means a specific, narrow permission is missing — not that something broke.
Club's team permissions are granted in narrow slices, not broad on/off switches per tab. That makes access precise, but it also means a team member can have a tab open and still be missing one specific thing inside it — and the panel is deliberately inconsistent in how it shows that, depending on where the gate sits.
Dashboard metrics fail per key, not per request
A batch read of dashboard metrics (the kind a custom block or a KPI tile makes) never fails all
at once because of one permission gap. Every metric key in the batch is checked on its own: a
team member with only traffic access gets real numbers back for their traffic.* keys and an
explicit "no access" placeholder on any money.* key in the same request — same response, same
200 status, no error banner for the whole card.
What this looks like in practice
A custom block mixing a traffic metric and a money metric shows one tile with a real number right next to one tile reading "no access" — for the same block, the same viewer, the same request. That's the batch working correctly, not a rendering bug.
A fan's spend history is gated, and the panel hides it rather than erring
Opening a fan's card in the inbox calls two separate reads for the trading-history side of the panel: the RFM/lifecycle profile and the purchase timeline. Both require the same specific team capability — a team member without it never sees a broken panel or an error message; the whole right-side spend panel simply isn't shown. If a team member says "I don't see spend/RFM data on fan cards", that's very likely this gate working as designed, not a bug to chase.
The content vault has nine separate action grants, not one
Team access to the vault isn't one "can use vault" switch. Scanning, uploading media, creating or deleting folders, organizing items, AI-tagging, editing tags, viewing performance analytics, and managing posts are each their own grant. A team member can, for example, be able to search and send content but have no organize or delete rights — and the corresponding buttons for those actions won't appear for them, tab access notwithstanding.
The general pattern
None of these are inconsistent bugs to fix — they're the same underlying design read three different ways by three different surfaces: a tab being open, or a request succeeding, never implies every action or every data field inside it is granted. When something looks unexpectedly missing for one team member and present for another:
- Check whether it's a specific action grant, not the tab itself, that differs between them.
- Expect the failure to show up differently depending on where it is — an inline "no access" tile, a hidden panel, or a missing button — rather than one consistent error everywhere.
- Don't conclude the mechanism is broken just because two features on the same page fail differently; that's how these gates are supposed to behave.
What's next
- When an empty block misreads its own cause — a different reason a tile can look empty.
- For how team roles and capabilities are actually assigned, see Team access.
Attribution doc gaps
Stale or misleading claims we found in the previous attribution guide and in the code's own comments — so future edits don't reintroduce them.
When an empty block misreads its own cause
Collapsing four distinct empty reasons into one generic message has caused a real incident — here's what to check before you trust a block's explanation.