```meta
title: Admin app visibility
subtitle: Which roles see which screens, and what the screen hides once it is open.
tag: DRAFT
```

The admin app has five roles and eight screens. A role sees a screen in full, sees it with some fields hidden, or does not see it in the navigation at all. The rules below are the source for the navigation, the route guard, and the API filters, so all three agree.

```callout
tone: note
title: Assumptions
body: "The request did not name the roles or the screens. This document assumes one workspace per customer, five fixed roles, and the eight screens the current navigation shows. Custom roles are out of scope."
```

## The five roles

Each user holds exactly one role per workspace. A user who belongs to several workspaces can hold a different role in each.

```glossary
terms:
  - Owner — The person who created the workspace. Holds every permission and cannot be removed.
  - Admin — Runs the workspace day to day. Sees everything except billing payment methods.
  - Support — Handles customer cases. Sees customers and orders, with personal data masked.
  - Finance — Handles invoices and payouts. Sees billing and orders, not the customer list.
  - Auditor — Reads the audit log and settings for compliance reviews. Changes nothing.
```

## Roles against screens

The grid is the contract. `Full` means the screen is in the navigation and every field is visible. `Masked` means the screen is visible and some fields are hidden (the next table lists them). `—` means the screen is not in the navigation and a direct URL returns a 403.

```matrix
id: access-grid
corner: Role / Screen
cols: [Dashboard, Customers, Orders, Billing, Users & Roles, Audit Log, Settings, Integrations]
rows:
  - { label: Owner, cells: [Full, Full, Full, Full, Full, Full, Full, Full] }
  - { label: Admin, cells: [Full, Full, Full, Masked, Full, Full, Full, Full] }
  - { label: Support, cells: [Full, Masked, Masked, "—", "—", "—", "—", "—"] }
  - { label: Finance, cells: [Full, "—", Masked, Full, "—", "—", "—", "—"] }
  - { label: Auditor, cells: [Full, "—", "—", "—", Read, Full, Read, "—"] }
```

`Read` on the Auditor row means the screen is visible in full but every action is disabled. That is a write restriction, not a visibility one, and it is listed here because the navigation shows the same screen to Auditor and Owner.

## What a masked screen hides

A masked cell in the grid hides specific fields; the rest of the screen is unchanged. The API strips the fields before the response leaves the server, so the client never receives them.

```table
title: Hidden fields per masked cell
columns: [Role, Screen, Hidden fields, Reason]
rows:
  - [Admin, Billing, "Card number, bank account, tax ID", "Payment credentials stay with the Owner"]
  - [Support, Customers, "Email, phone, postal address", "Support works from the customer ID and case history"]
  - [Support, Orders, "Unit price, discount, margin", "Pricing is a Finance concern"]
  - [Finance, Orders, "Customer name, shipping address", "Finance reconciles by order ID and amount"]
```

## How the app decides

A screen is shown only when three gates all pass. The gates are checked in this order, and the first failure decides the outcome.

```composition
title: Effective visibility of one screen
result: The screen is in the navigation and its route loads
gates:
  - { label: Membership, desc: "The user belongs to the workspace in the URL.", kicker: Gate 1 }
  - { label: Role grid, desc: "The role's cell for this screen is Full, Masked, or Read.", kicker: Gate 2 }
  - { label: Feature flag, desc: "The screen is enabled for this workspace. Integrations is off on the Starter plan.", kicker: Gate 3 }
```

A failed membership check redirects to the workspace picker. A failed role or flag check hides the entry and returns 403 on a direct URL. The Dashboard has no flag and every role sees it, so a signed-in member always lands on one screen.