Three layers

Access to a Page is the combination of three checks. All three must say yes for a teammate to open a Page and see its data.

1. The Pages surface (segment)

Pages is a workspace segment like Data or Knowledge Base. A member only sees Pages at all if their effective surfaces include it. This is the coarsest layer: it decides whether the Pages section appears in the sidebar for that person, set through roles and per-member surface grants in Settings → Access (see Settings). If a member can’t see the Pages surface, no individual Page is reachable for them, full stop.

2. Per-page grants

Within the Pages surface, each Page has its own grants (its page_grants), and they reuse the same roles you already manage for the rest of the workspace. You grant a Page to a role; every member of that role can open it. There is no separate permission system to learn, a Page is shared with a role the same way a console surface is.

The default is the grandfather rule: a Page with no grants is visible to all members (who can see the Pages surface). You only add grants when you want to restrict a Page to specific roles, at which point it disappears from the sidebar for everyone else. This mirrors how access works elsewhere in Amdahl, no policy means full access, a policy means exactly what it says.

3. Auto-scoped data

Even when two people can both open the same Page, they may see different numbers. The Page’s queries are scoped to each viewer automatically, using the per-member data-scope rules from Settings → Data → Data Access (see Data model). You never configure data scope on the Page itself; it inherits whatever each viewer is already allowed to see across the rest of the product.

Why three layers

The three layers answer three different questions, and keeping them separate is what makes them easy to reason about:

• Surface: can this person see Pages at all?
• Page grant: can they open this Page?
• Data scope: which rows do they see inside it?

A teammate has to clear all three to read a Page’s data: the Pages surface, this Page’s grants, and then their own data scope decides what’s in it.

Editing access

Managing who can open a Page works the same way as the rest of access management, it’s roles-first with a per-member escape hatch, exactly like Settings → Access. You grant the Page to roles for the common case, and add per-member exceptions when one person needs different treatment. Because Pages reuse your existing roles, a new hire who joins a role inherits every Page that role can see with no extra step.

Data scope is never edited on the Page. To change which rows a person sees inside a Page, change their data-scope rules in Settings → Data → Data Access, and the change flows through to every Page, the Data Explorer, the API, and MCP alike.