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.
