Sometimes you don’t want a user to see everything — just one project, one report, or the ability to upload responses without touching anything else. Object-level permissions let you grant access per project or per report, without changing anyone’s role.
Why object permissions exist
Real scenarios where they help:
- You hire a freelancer to code one survey — you don’t want them inside the whole workspace
- A colleague is responsible for uploading new files — but shouldn’t edit your topics
- Your manager needs visibility on one project — not all projects
Roles alone can’t handle these cases. Object-level permissions fill that gap.
Project permissions
Use View sensitive columns to hide PII or confidential fields from most collaborators. Auxiliary columns flagged as sensitive in the Data Tab only appear for users with this permission — everyone else keeps Projects View access without seeing the protected fields. Report permissions
Integration permissions
Administrative permissions
Permission inheritance
Caplena’s sharing logic follows a simple hierarchy.
Project access → Report access - If a user can access a project, they automatically gain access to all reports in that project, all views in those reports, and any related exports.
Report access → Report views - If a user can view a report, they automatically see all its views. However, report access does not grant project access or expose raw data — report users cannot inspect answers unless explicitly granted project permissions.
This lets you safely share reports without exposing sensitive underlying data.
Ownership rules
Object owner — the person who created the project or report always has full control and cannot have permissions removed (only ownership transferred).
Root organization user — the master account of your company always sees everything and cannot be restricted or removed. Last modified on June 8, 2026
