Role-based access
The four role levels in KobiGPT: super_admin, admin, manager, and viewer.
TL;DR
Admin, manager, viewer roles in KobiGPT.
Quick facts
- Category
- AI & knowledge management
- Product tie-in
- KobiGPT RAG platform
- Related
- See compare and tools pages
- Locale
- TR and EN site
Why teams choose KobiGPT
- Understand terms before evaluating vendors.
- Link concepts to KobiGPT features (RAG, Kobi Kredi).
- Share glossary links with procurement and legal.
- Explore assistant use cases next.
Product facts
- Ücretsiz plan
- 100 doküman · 2 departman · 120 Kobi/ay(PLAN_CONFIG)
- Starter
- 1000 doküman · 5 departman · 1000 Kobi/ay(PLAN_CONFIG)
- Pro
- 12500 doküman · 25 departman · 12500 Kobi/ay(PLAN_CONFIG)
What the four roles do
KobiGPT defines four roles. super_admin holds the broadest authority at platform level; admin performs management operations within a company; manager carries responsibility at department level; viewer is limited to reading and chatting.
Roles determine which assistant a user can talk to and which management operations they can perform. Uploading documents, creating assistants, and inviting users all depend on role level.
The role model is not sufficient on its own; it works together with per-assistant document scope. The two together form access control.
A common mistake when assigning roles
The most frequent mistake is granting everyone the admin role for convenience. That reduces friction during setup but effectively removes access control; every user comes to see every assistant.
The second mistake is never reviewing roles. Old assignments survive role changes and departures, and within a few years who can reach what becomes unclear.
The practical recommendation is to start with the narrowest role and widen as needs arise. The reverse — starting broad and narrowing later — rarely happens in practice, because nobody wants to take permissions away.
Roles and scope should be designed together
Thinking about roles and assistant scope separately leaves gaps. The right approach defines, for each document set, both which assistant it attaches to and which roles reach that assistant.
That definition should be written down. The part of a deployment kept in someone’s head disappears when the team changes, leaving access decisions unexplained.
A periodic check belongs in the plan too: which user holds which role, and which assistants do they see? Running that check a few times a year keeps access debt from accumulating.
Applying What the four roles do in a controlled workflow
A useful way to evaluate role-based-access is to follow one real question from the source document to the final answer. Record which file was selected, what context reached the model, and what a reviewer would need to verify. This turns a definition into an operational check and makes the result comparable across teams.
The same check should include ownership and change management. Decide who updates the relevant documents, how an outdated result is reported, and which access boundary applies. KobiGPT can provide the assistant and the cited document context, but the organisation still owns the source material, permissions, and the decision made from the answer.
FAQ
What is Role-based in practice?
Admin, manager, viewer roles in KobiGPT.
Does KobiGPT use this?
See product docs and feature pages for implementation details.
More reading?
Visit our blog and FAQ.
Accuracy disclaimer?
Educational content; verify for compliance decisions.
Which roles exist?
super_admin, admin, manager, and viewer. Roles determine which assistant can be reached and which management operations are permitted.
Is a role enough on its own?
No. The role model works together with per-assistant document scope; the two together form access control.
Comparison
| Feature | KobiGPT | Alternative |
|---|---|---|
| SME focus | Yes | N/A |
| Citations | When using RAG | N/A |
| Glossary depth | Growing | N/A |
| Tools | Interactive | N/A |