Roles & Permissions

Roles and Permissions in Kibi Connect#

What someone can see and do in Kibi Connect is determined by three things: the roles they hold platform-wide, their role in individual groups, and—for external persons—the user type "Guest". This page explains all three.

The roles are not fixed; you can adapt existing roles to your organization and create your own.

Configuring Roles and Permissions Yourself#

You can find the management interface under "Roles & Permissions" in the Administration section. This area is reserved for System Admins—no other permission grants access, not even managing user accounts.

It consists of three tabs:

• Roles: Overview of all roles; here you can create new ones and edit existing ones.

• Permission Check: Shows for a selected person which permissions they actually hold and where they come from. The quickest way to answer "Why can't this person see this?".

• Permission Catalog: All platform permissions, organized by modules—for reference.

Permissions are assigned per module in levels#

You don’t set 123 individual permissions, but rather a level per module. The "Modules" and "System" tabs separate the functional areas from system administration.

Example for Files: "View" only allows viewing, "Create" additionally allows uploading, editing own files, and sharing, "Administer" also allows editing and deleting others' files.

Creating Your Own Roles#

• Create any number of your own roles, such as "Project Manager" or "Quality Assurance", and assign levels appropriate to the task.

• You can also adjust the pre-configured roles—and reset them to their default state at any time.

• Pre-configured roles cannot be deleted, but custom ones can.

• The "System Admin" role remains unchangeable. It serves as a reference point, allowing a tenant to reopen access for itself if locked out by a faulty role.

The Pre-configured Roles#

Kibi Connect comes with these roles. They are intended as a starting point and are customizable—the following descriptions apply to the default state.

• Colleague: The base role for all employees. View, comment on, and like global content (news, wiki, calendar); chat; view colleague profiles; create groups and collaborate in their own groups according to the group role assigned there.

• HR Manager: Create, edit, and manage user accounts; assign roles without admin permissions; manage personnel files; create closed groups such as departments and manage their members without seeing their content. Only the System Admin can edit the roles themselves—i.e., which permissions a role contains. Only the System Admin can edit admin accounts and assign admin roles.

• Wiki Creator: Create global wiki entries and edit and delete their own.

• News Creator: Create global news and calendar entries and edit and delete their own.

• Content Manager: Manage all content—news, polls, wiki, calendar, and files—and set extended visibility for them.

• Fleet Manager: Manages the fleet: vehicles, logbook, damage reports, and driver's license checks.

• System Admin: Full access to system configuration and user management, including granting admin permissions and role management itself.

Assigning Admin Roles#

Admin roles include the "System Admin" role and any role containing admin permissions—such as for integrations, webhooks, mail management, or settings. Since version 6.32, two additional rules apply to them:

• Only the System Admin can assign them

  Only System Admins can assign or revoke admin roles and edit admin accounts. HR Managers and other roles with the permission to manage user accounts can no longer do this; they continue to manage all other accounts.

• "Address verified" for accounts from an identity management system

  If an identity management system (SCIM, Microsoft Entra ID, or RO.CAS) has set or changed the email address of an account, the platform requires visible verification before assigning an admin role. You will see the address, when and from which source it was set, and confirm with the checkbox "Address verified".

The reason: Whoever controls the address of an admin account can take over the entire organization via "Forgot password?". Therefore, verify that the address truly belongs to this person. The verification applies everywhere an account receives admin permissions: in the user account, in the member list of a role, and when an existing role gains an admin permission. It is logged.

Role with "Integrations" permission: It sees the integrations overview and "SSO & Directory" in read-only mode. Only the System Admin can enable/disable integrations and change identity sources.

Guest Access for External Persons#

For suppliers, customers, planning offices, or other external participants, there is guest access. A guest is not a role, but a user type—that is the crucial difference.

• Guests cannot be assigned roles. What a guest can do is determined by their groups, not by a role.

• A guest has a fixed basic set of permissions: They can chat, as well as access Feed, Wiki, Calendar, Events, and their groups—each only with the content they are entitled to via their groups.

• The general file area remains closed to them. However, they can view and edit the files of the groups they are a member of, just like any other member—according to the group role there.

• In groups, a guest can have at most the "Collaborate" role. They cannot become a Group Admin, as that would allow them to add more people themselves.

• Guests and employees can only see each other if they share at least one group. A guest therefore does not appear in the employee directory, nor can they search it.

Groups and Permissions#

Creating Groups#

• Anyone can create a group; the person who creates it automatically becomes the Group Admin.

• Hidden groups and departments can only be created by System Admins and HR Managers.

Roles Within a Group#

Each member of a group has one of three roles there:

• Read (formerly "Member"): Can read, like, and comment on all content in the group, but cannot edit anything. Default role for new members; the default can be changed.

• Collaborate (formerly "Creator"): Can create content and edit any file in the group—even those uploaded by others. This includes filling out and saving PDF files with the Kibi PDF tool. Only their own content can be deleted.

• Admin: Can create, edit, and delete everything in the group—including others' files—and manages the members.

Overview#

Practical Examples#

• Personnel Group: An HR Manager creates a closed group for personnel topics. Only its members can see the content—even a System Admin cannot, unless they are a member.

• Project Group: A colleague creates a public project group. All colleagues can view and comment on the content, while members with the "Collaborate" role can post contributions and jointly edit the group's documents.

• External Collaboration: A planning office receives guest access and is added to the project group. There, it works on the same documents as the internal team; everything outside this group remains hidden from them.

• Custom Role: An organization needs a "Project Manager" role that administers tasks and files but does not handle user accounts. A System Admin creates it under "Roles & Permissions" and sets the two modules to "Administer", leaving everything else unchanged.