Required Roles: Workspace Manager (to grant access); Any user (to view/access areas granted)
Required Permissions: Varies by role. See Roles & Permissions for limits per role.
Index
Summary
Kivo’s permission system is designed to make access control simple, flexible, and compliant. Permissions determine who can see or interact with specific areas of your workspace, such as Document Management (DMS), Activities, and Projects, based on a user’s role and access granted by a Workspace Manager.
Permissions within an area of the Kivo app are determined by two key factors:
User Role: Each user has a role that defines a maximum set of actions they can take. A user cannot exceed the capabilities of their role, even if they’re granted access to an area. Once access is granted (individually or via a group), the role determines the actions they can take there.
Workspace Access: Workspace Managers grant access to specific areas or settings. Access in Kivo is:
Cascading: access flows down from a parent area to all sub-areas (e.g., from a folder to subfolders).
Additive: additional permissions can be granted in sub-areas, but permissions cannot be restricted below what’s granted at a higher level.
User Roles
A user’s role determines the actions they can take in an area of the application after they’ve been granted access to that area. Kivo roles and the corresponding permissions are outlined in detail in the Roles & Permissions article.
A user’s role always governs their maximum level of permission. For example, if a group is given access to a folder, editors in that group can be granted the ability to edit documents, while viewers cannot exceed view-only access.
Workspace Access
Kivo users must be granted access to specific areas of the application to see and participate in those areas. Access is typically managed via groups, then refined at lower levels.
Group Access
Groups form the foundation of access control in Kivo. Every user must belong to at least one group, which determines the modules (Regulatory, Clinical, Quality) and functional areas (Documents, Projects, Activities) available to them. See Creating new user groups (V2) for how to create and manage groups.
After a group is granted access to a module, users in that group can navigate to that area. However, to view content or take action within DMS, Activities, or Projects, the user or group must also be granted permissions to the specific items (e.g., cabinets or folders, activity subtypes, or projects).
Granting access by group is recommended to simplify management, however permissions can also be granted at an individual user by suer basis.
This looks slightly different in each functional area as defined below:
DMS Access
Groups or users must be given access to a cabinet or folder before they can see and take action on those documents in the DMS.
First, a group must be added to a folder or cabinet and given specific permissions within that folder. These granular permissions are outlined in Roles and Permissions.
Then, users or groups can be added to specific workflow steps in the folder. This allows users to be selected as participants in that workflow step. Again, this is controlled by role - in the example below, an editor in Regulatory will be eligible to participate in the collaboration step, but a viewer within that same group would not.
Activity Access
After a group is granted access to an Activity area (e.g., Regulatory Activity or Sites), grant access to the subactivities to view and take action.
Access can be granted to all subtypes or limited to specific activity subtypes.
Actions available to users remain governed by role. For example, an Editor in Regulatory Activity can edit; a Reviewer may only view.
As always, the permissions for specific users within that group will be determined by role. In the above example, an editor in Regulatory Activity would have the ability to edit, whereas a reviewer could only view those activities.
Project Access
Groups must be granted access to a specific project before members can see or participate in that project.
Project access is managed at the Category level (e.g., Category: “Asthma”).
Cascading Permissions
Kivo’s permission model is hierarchical - access always cascades from parent areas to their children. This is true across the application: child folders inherit the permissions of parent folders and cabinets, and project types inherit the permissions of categories.
Key points:
If a user has access to a folder, they automatically have access to all of its subfolders.
Permissions set at a parent level (e.g., “View drafts,” “Participate in workflow step”) cascade to all child areas.
A user cannot be restricted at a lower level if they have access at a higher level—access flows down, not up.
Example:
A user group is granted access to a Parent Folder. A Subfolder inherits that access. Settings granted at the parent, such as Edit or Upload Into Placeholder, cannot be removed in the subfolder.
Parent Folder
Subfolder
Additive Permissions in Child Areas
While access cascades downward, you can grant additional permissions at lower levels. Once added, these permissions also cascade to any children of that area.
Examples:
A group has Read permissions at a folder, but is granted Edit permissions in a specific subfolder.
A participant is given Approval rights in a workflow for a specific folder.
This flexibility allows teams to fine-tune who can perform actions like participating in workflow steps, uploading, downloading, or viewing drafts—without violating the role-based maximums.
[Kivo Admin Guide] > [Access Management] > Understanding Permissions in Kivo