Roles and access control

Roles (for example trainer vs member) are the audience you assign when you invite someone or use Preview as. What they can actually do is a set of capabilities (for example see invoices, refund a payment). Access is enforced by GenieForge, not only by what the screen shows. Name audiences as soon as they differ: who submits, who approves, who sees everyone’s data. Describe that outcome; GenieForge creates and wires roles before you invite real users. The same role name can mean different access in two projects of the same app. Clinic B can give receptionists invoice read access without changing Clinic A, and without creating a second receptionist role. Manage roles under App Blueprint → Roles. Builders invite from project End-Users. Workspace owners invite and change roles from portal People.

How to verify

Confirm roles under App Blueprint → Roles.
Open App Blueprint → Access: findings, per-role explorer, and roles-by-resource matrix.
Preview as each role. Try a path that should fail (for example a requester opening the dispatcher queue).
After permission changes, Preview again. Preview as Owner (or Admin) can hide a member-only page. That is expected when you left them off the list. Builder Chat still sees every page. Shared app access (who can see a table, named extras like refund) applies in Preview and the live portal after you publish. Extra access you add for one project applies immediately.

Limits and notes

Concept	What to remember
Built-in Owner	Full tool and data access, plus this project’s workspace (billing, People, Activity). App Registration assigns Owner. One real Owner per project. Does not see Work unless you grant it. Pages, nav, and in-page blocks still honor their role lists: Owner must be listed on a non-empty list. Empty lists stay Owner/Admin only.
Built-in Admin	Full tool and data access. Does not manage portal Billing or People. Does not see Activity or Work unless you grant those for that project. Pages and nav work the same as Owner: they must be listed when a list is set. `"*"` does not include Owner or Admin.
Reserved names	Do not name a role `_unknown`, `__public__`, or `__share_link__`. Those names are reserved for guest intake.
Page vs navigation	Hiding a nav link does not revoke page access. A page or nav item limited to a custom role (for example member only) is hidden from Owner and Admin unless you also list them. `"*"` is every custom role, not Owner or Admin. The same lists hide in-page controls on a shared page (filters, tabs, columns, KPI tiles, chatbot suggestions, empty-state buttons). That hide is not a data permission.
Model / table UIs	Roles that browse table-backed data need the right model access (at least list when they should read rows). That is page and data access. It does not by itself put the raw table in Chat; see Agents. Child records can be limited to the parent the person owns, so a client sees only their own visits without copying an owner column onto every table.
Code tools	Gated by the tool’s allowed roles, and optionally by capabilities. An empty role list means no custom role can run it. Ask Building to open a tool to every custom role and to public intake when that is the intent. A broken session cannot run it. When Building uses the app’s tables in a tool, those reads follow the row limits you set for that role under Access. A role you did not list there is not limited inside a tool they can run. Ask Building if a tool still shows every row.
Capabilities	Model access (who can list or change a table) plus named extras (refund, send email). Prefer “can they see money?” over “are they a receptionist?” A page or button can require both a role and a capability. If several capabilities are listed, any one of them is enough.
Workspace Activity	Owner can always open portal Activity. You can grant that to a custom role, or add it for Admin in one project. Admin does not get it automatically.
Work inbox	Off until you grant it to a role. Owner and Admin do not get it automatically. Ask Building to turn on Work for the roles that need a queue. Items assigned to a role use that role’s name (for example dentist), not a hidden id.
Search	Search (Command-K) only returns pages, records, files, and chats that role can already open. It is not a separate permission.
One project, extra access	A single clinic or tenant can add capabilities to a role without changing the shared app. That extra access applies immediately, for every row in that project’s data. To keep people to their own rows, set model access with scoping instead.
Public intake	Guest forms cannot require a capability. Anonymous visitors have none.
Ownership	Store “belongs to” with immutable user ids, not email addresses
Agents	Pair roles with Agents when audiences need different AI behavior

A path that works when you test as a builder can still fail in Preview as a customer role until that role’s access matches.

What good looks like

Requesters create requests and see only their own. Dispatchers see all open requests and can assign and complete. Clients never appear in that app.
The coach role may open the roster and assign sessions. Members may only open My plan and the check-in.

Start here

Working with the AI

What's in an app

Tutorials

Operate

Connect

Improve

Secure and launch

Account

Roles and access control

Roles and access control

How to verify

Limits and notes

What good looks like

​Roles and access control

​How to verify

​Limits and notes

​What good looks like

​Related

Roles and access control

How to verify

Limits and notes

What good looks like

Related