Role-Based Access Control

Granica uses role-based access control (RBAC) to govern what each user can see and do in the Console. Every user is assigned one of three roles: Viewer, Editor, or Admin. Roles are assigned when a user account is created and can be changed at any time by an Admin.

Roles overview

Role descriptions

Viewer

Viewers have read-only access to the Granica Console. They can monitor the platform and review optimization results, but cannot make any changes.

Viewers can:

• View the dashboard, including savings metrics and compression ratios
• Browse the table list and inspect per-table details and optimization opportunities
• Review query history

Viewers cannot onboard tables, create schedules, or modify any settings.

Editor

Editors can configure and run optimizations. This role is appropriate for data engineers and platform engineers who manage day-to-day operations.

Editors can do everything a Viewer can, plus:

• Onboard tables and manage their optimization policies
• Run evaluations to assess compression candidates
• Create, update, and delete Crunch schedules
• View platform configuration

Editors cannot manage users, configure SSO, or modify platform-level settings.

Admin

Admins have full access to all platform capabilities. Assign this role to users who are responsible for deploying, configuring, and securing the Granica platform.

Admins can do everything an Editor can, plus:

• Create, edit, deactivate, and delete user accounts
• Assign and change user roles
• Configure and enforce SSO authentication policy
• Manage catalog connections
• Modify platform settings (table size thresholds, job configuration, etc.)

Manage users and roles

Admins manage users from Settings → Users in the Granica Console. From this page you can:

• Invite a new user — Enter an email address and select a role. The user receives an invitation email with a link to set their password.
• Change a role — Click the role badge next to any user and select a new role. The change takes effect on their next request.
• Deactivate a user — Deactivated users cannot log in but their account and history are retained.
• Delete a user — Permanently removes the account.

See Manage Users for step-by-step instructions.

API token permissions

API tokens are scoped independently of the user role that created them. When generating a token, you select exactly which resource actions it can perform (for example tables:read or schedule:write). A token can never exceed the permissions of the creating user's role, but it can be scoped to a subset.

See API Token for details on creating and managing tokens.