User Access in Caplena: Roles vs. Project Access
Learn how Caplena’s role-based and project-specific permissions work, and how to manage access effectively across your team.
Getting team access just right is essential, especially when your projects involve multiple collaborators, analysts, and stakeholders. In Caplena, user permissions help you control who can see what, and what actions they can take.
Let’s walk through how it works, with examples to bring it to life.
Two Types of Permissions:
1. Role-Based Permissions
These apply across all projects within your organization. When you assign someone a role (like “Project Manager” or “Internal Analyst”), you're defining their baseline capabilities.
Example:
Anna is given the “Internal Analyst” role. She can access and edit all projects, but she can’t upload new ones or download data.
2. Object-Specific Permissions
These apply to individual projects or reports. This lets you fine-tune who can view, edit, or inherit a specific project, even if their general role doesn’t allow it.
Example:
Tom has the “External Topic Assignment” role (no access to others’ projects), but you manually grant him view access to one specific survey project. Now he can see just that one, nothing else.
Additive Permission Logic
Permissions in Caplena are additive:
-
You can grant extra access to a specific project.
-
But you cannot revoke access that comes from a user’s role.
Example:
Sarah has the “Full Data Access” role, allowing her to edit all projects. You want her to stop editing one particular project, but that’s not possible unless her role is changed.
Special Cases: Ownership & Admin Access
Some permissions are hardwired to specific users:
-
Object Owners: Whoever uploads a project or creates a report will always have full control, unless ownership is explicitly transferred.
-
Company Administrators: The root admin account in your organization automatically has full access to everything, no exceptions.