Roles and permissions

The FGA Dashboard uses roles to enforce the Principle of Least Privilege and give your organization control over what each member can see and do. Specific teams, such as Engineering, Support, or IT, can be given the exact level of access they need. Roles were introduced in the dashboard with the Per-Member Authorization feature.

How roles, groups, and members work together

Permissions in the FGA Dashboard are managed through these concepts:

• Roles define what actions a member can perform and what resources they can access.
• Groups bring roles and members together. When you create a group, you assign it one or more roles and optionally scope store-level roles to specific stores.
• Members are the people in your FGA account. Members are added to groups and automatically inherit the roles assigned to those groups.

The Account Owner role is the one exception: it is assigned directly to individual members rather than through a group.

Store-level roles (Store Editor and Store Viewer) can be scoped to specific stores. This means a single member can have different access levels across different stores. For example, a developer can have Store Editor access to a development store while being restricted to Store Viewer access for a production store.

Roles

Account-level roles

Account-level roles manage the overarching organization and administrative functions.

• Account Owner: This role is the super admin with the highest level of permissions in the FGA account. This includes full permissions for groups, members, and stores, as well as any future resources like metrics. This is a privileged role that is assigned directly to an individual member rather than through a group. Grant this role to an administrator who needs full control over the entire FGA account. See Manage Members for how to assign this role.

• Group Manager: Manages groups and group membership. Group Managers can invite members and add/remove them from groups. Grant this role to someone in your organization who manages access to development resources or team membership, such as an IT admin or team lead, but does not need direct access to stores. See Constraints and guardrails for the full list of Group Manager restrictions.

Store-level roles

Store-level roles are intended for members who need access to one or more specific stores. These roles are assigned to groups and scoped to specific stores during group creation or editing.

• Store Editor: Can create and update authorization models, relationship tuples, and assertions in assigned stores. Can also run queries, manage clients, view metrics and logs, and rename stores but cannot delete stores. Store Editor includes all Store Viewer permissions for the same stores. Grant this role to developers or engineers who actively build and maintain authorization models and data in specific stores.

• Store Viewer: Read-only access to assigned stores. Can view models, tuples, assertions, logs, metrics and store credentials (excluding the client secret). Can also run queries such as Check. Grant this role to team members who need visibility without the ability to make changes, such as developers troubleshooting production issues, security reviewers, or operations staff monitoring a store.

note

When new stores are created, groups with Store Editor or Store Viewer roles do not automatically gain access to the new stores. An Account Owner or Group Manager must update the group that needs access to the new store.

Common configurations

The following scenarios illustrate how to combine roles, groups, and store scoping to support common organizational needs.

IT admin managing teams

Create a group named, for example, "IT Group", with the Group Manager role. Members of this group can invite new members, create and manage groups, and manage group membership. They do not have direct access to any stores. This is appropriate for IT administrators or team leads who manage people but do not work directly with authorization models or data.

Dev team with environment-scoped access

Create a group named, for example, "Dev Team", with the Store Editor role scoped to your development and staging stores. Members can create and update authorization models, write relationship tuples, add assertions, and run queries in those stores. They have no access to production stores. If read-only access to production is also needed, add the Store Viewer role scoped to the production store within the same group.

Read-only access for support and non-development teams

Create a group named, for example, "Read-Only Access", with the Store Viewer role scoped to your production store. Members can view authorization models, relationship tuples, and assertions, and can run queries such as Check. They cannot modify anything. This is appropriate for operations teams, security reviewers, or business stakeholders who need visibility without the ability to impact systems.

Mixed access across environments

Create a group named, for example, "Integrations Team", with the Store Editor role scoped to your staging store and the Store Viewer role scoped to your production store. Members can make changes in staging while having read-only visibility into production. This supports workflows where teams need to develop or test in non-production environments while monitoring production.

Permissions matrix

Account-level permissions

Permission	Account Owner	Group Manager	Store Editor	Store Viewer
View account metadata	✅	✅	❌	❌
View account usage metrics	✅	✅	❌	❌
Manage all members (invite, remove)	✅	✅ *	❌	❌
Create groups	✅	✅	❌	❌
Delete groups	✅	✅	❌	❌
Assign/modify group permissions	✅	✅ *	❌	❌
Add/remove members from groups	✅	✅	❌	❌
Create stores	✅	❌	❌	❌
Delete stores	✅	❌	❌	❌

* With restrictions

Store-level permissions

Permission	Account Owner	Group Manager	Store Editor	Store Viewer
View authorization models	✅	❌	✅	✅
Create/update authorization models	✅	❌	✅	❌
View relationship tuples	✅	❌	✅	✅
Write relationship tuples	✅	❌	✅	❌
View assertions	✅	❌	✅	✅
Create/update assertions	✅	❌	✅	❌
Run queries (e.g. Check)	✅	❌	✅	✅
View store credentials (excluding Client Secret)	✅	❌	✅	✅
View Client Secret	✅	❌	✅	❌
View Store Logs	✅	❌	✅	✅
View Store Metrics	✅	❌	✅	✅

Constraints and guardrails

Account Owner

• Account Owner is assigned directly to individual members, not through groups. See Manage Members to assign this role.
• The system prevents removal, role-demotion, or deletion of the last remaining Account Owner. There must always be at least one Account Owner on the account.
• Account Owners cannot remove themselves from the account or downgrade their own Account Owner role. Another Account Owner must do this.

Group Manager

Group Managers have the following restrictions to prevent privilege escalation:

• Cannot add themselves to a group.
• Cannot modify the permissions (roles or store assignments) of a group they belong to. Only an Account Owner or a Group Manager who is not a member of that group can modify its permissions.
• Cannot assign or remove stores from a group they belong to.
• Cannot create or delete stores.
• Cannot invite members as Account Owner.
• Cannot remove an Account Owner from the account.
• Cannot remove or change the Account Owner role from a member.
• Can see list of all stores in the store selection dropdown when configuring groups, but this does not give access to store data. This must be done independently with a Store Editor or Store Viewer role.