Skip to main content

Users and groups

A QRY tenant has users (individual accounts), groups (named collections of users for collective grant management), and roles (capability bundles assigned at the tenant or group level). This page covers the day-to-day admin: who exists, in what group, with what role.

Where users come from

Three sources feed your tenant's user list:

  • Direct creation — admin creates an account in Admin > Users with email + temporary password. The user resets on first login.
  • OAuth self-registration — when enabled (Admin > System Settings > Authentication), users with allowed email domains can sign in with Google / Microsoft / GitHub and an account is auto-created.
  • Invitation — admin sends an email invite with a one-time signup link, scoped to a specific role.

Domain matching is by OAuth provider id, not just email — so a user who first signed up via Google alice@example.com and later switches to Microsoft with the same email is recognised as the same account.

Roles

Roles are tenant-level. Common defaults:

RoleTypical capabilities
adminEverything: user management, datasource config, system settings, all features.
power_userUse all features. Cannot configure tenant-wide settings.
analystRead access to permitted datasources, can create conversations, dashboards, notebooks.
viewerRead access only — can view shared dashboards / conversations but can't create new content.

Tenants can define custom roles in Admin > Roles. A role is a set of capability flags — granular enough to express "can use Forge but not ML Hub" if you need it.

Groups

Groups are how you grant the same set of permissions to many users without per-user clicks. Common patterns:

  • data-team — group of analysts who all need access to the same datasources.
  • executives — group with read-only role and access to the executive dashboards workspace.
  • external-consultants — limited group with a tighter quota template and short-lived accounts.

Group membership composes with direct assignment: a user gets the union of every grant they have through any group plus their own.

Creating a user

In Admin > Users, click + New User. Required:

  • Email — must be unique in the tenant.
  • Display name.
  • Temporary password — user resets on first login.
  • Role — at least one tenant role.
  • Groups — optional initial memberships.

Click Create. The user appears in the list and (if email is configured) receives an invitation email.

Creating a group

In Admin > Groups, click + New Group. Provide:

  • Name — appears in user-list filters and grant pickers.
  • Description.
  • Default quota templateStandard, Monitoring, or Power user (see Task Quota Templates). Members inherit this unless overridden per user.
  • Initial members.

Removing a user

In the user's row, Remove. The account is deactivated but soft-deleted — their conversations stay accessible to admins for the retention window (90 days by default), then the cleanup cronjob removes them. To restore an account within the window, contact tenant operations.

Removing a user does not delete their content — workspace conversations they authored stay in the workspace; their personal conversations are no longer accessible.

Domain rename note

Internal users for puedata.com migrated to ixen.ai on 2026-04-23. OAuth matches by oauth_provider_id first, so existing accounts kept working through the rename. New OAuth setups should use the current internal domain.

Common issues

OAuth login fails with "domain not allowed". The user's email domain isn't on the allow-list. Check Admin > System Settings > Authentication > Allowed Domains.

A user has access to a datasource I didn't grant directly. Group inheritance. Click the user's row → Effective permissions to see every grant and where it came from.

Removed user's audit log entries disappeared. Audit log entries are retained even after user removal — they reference the user id, which stays in the database. If they look "gone", it's likely the audit log filter is hiding deactivated users by default.

Quota template change isn't taking effect. Per-user override beats group default. Check the user's Effective quota in their profile; remove the override if you want the group default to win.

See also

  • RBAC — datasource / catalog / schema / table grants per user or group.
  • License management — user count caps come from the GCP license.
  • Audit and compliance — audit logs of admin actions including user changes.
QRYA product of IXEN.