> ## Documentation Index
> Fetch the complete documentation index at: https://docs.genieforge.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Roles and access control

> Roles control which tools, forms, pages, and data each end user can reach.

# Roles and access control

**Roles** (for example trainer vs member) control which tools, forms, pages, and navigation each end user sees. Access is enforced by GenieForge, not only by what the screen shows.

Every app includes built-in **owner** and **admin** roles for builders; those cannot be deleted and have full access.

Tables that end users browse through model tools or table-backed page data need per-role access on the data model (at least **list** for roles that should read those rows). A code tool that uses semantic search inside its body is gated by that tool's allowed roles, not by granting **list** on the underlying search table (granting **list** would also expose the raw table tool). Owner and admin bypass model rules; other roles do not. A tool that works when you test it as a builder can still fail in **Preview as** a customer role until the tool's allowed roles (and any model access for direct table UIs) match that role.

Pair roles with **Agents** when different audiences need different AI behavior. When you store data that belongs to a person, key it to their user id, not to their email address (emails change).

Manage roles under **App Blueprint → Roles**, agents under **Agents**, and invitations under project **End-Users**.

To review what each role can actually reach (pages, tools, tables, and common access mistakes), open **App Blueprint → Access**. That page shows findings, a per-role explorer, a roles-by-resource matrix, and a reachability graph for the selected role. Use it after you add or change roles, pages, or tool permissions, then confirm with **Preview as** for the same role.