Role-based access control
Manage access to SeekrFlow resources through organizations, teams, and role-based permissions.
SeekrFlow uses a team-based access model to organize users and control what they can do. All resources – agents, fine-tuning jobs, deployments, files, and vector databases – belong to a team, and access is enforced based on a user's role within that team.
Manage permissions (UI)
Create and manage teams and members through the SeekrFlow web interface.
Manage permissions (SDK and API)
Manage teams and members programmatically with the Python SDK and REST API. Coming soon.
Organizations and teams
An organization is the top-level container for a SeekrFlow account. All users, teams, and resources belong to a single organization.
A team is a group of users within an organization. Resources are scoped to a team, meaning each team has its own isolated view of agents, fine-tuning jobs, deployments, files, and vector databases. Users can belong to multiple teams and switch between them to access the resources associated with each.
When a new account is created, a new organization is provisioned if the user doesn't already belong to one. An existing organization owner can also invite new users. For self-hosted deployments, a default organization is created during installation. Teams are not automatically provisioned in either case. Each user also gets a personal workspace – a private team with no other members.
Roles
Every user has an organization role and, within each team they belong to, a team role. Together these determine what a user can see and do.
Organization roles
Owner – Full organization access to manage settings, teams, and roles.
Member – Access limited to assigned teams and their resources.
Team roles
Admin – Full team access to manage members, roles, and settings.
Creator – Can contribute within assigned teams without managing roles or access.
Permissions summary
| Action | Owner | Member + admin | Member + creator |
|---|---|---|---|
| Create, rename, delete teams | ✓ | ✗ | ✗ |
| Add and remove team members | ✓ | ✓ | ✗ |
| Change member roles | ✓ | ✓ | ✗ |
| Create and manage resources | ✓ | ✓ | ✓ |
Resource isolation
Resources are scoped to the team they were created in. When a user switches their active team, the resource lists – agents, fine-tuning jobs, deployments, files, and vector databases – update to show only what belongs to that team. API and SDK calls are similarly scoped to the active team, and requests for resources outside a user's teams are rejected.
Migration from single-user deployments
Existing users are migrated to an organization, and select users are assigned the Owner role. Existing resources move to each user's personal workspace. No teams are automatically created and no team roles are automatically assigned. Self-hosted customers need to upgrade to the version that includes role-based access control and perform the migration manually.
Updated about 12 hours ago