RefractSurvey Permissions and Roles
RefractSurvey's permission system controls exactly what each user can see and do, down to a fairly fine level of detail. This page explains how the pieces fit together.
Permissions
Every permission is a noun (what it applies to) and a verb (what it lets you do), like surveys:publish or codes:generate. The full set of nouns:
- Projects — view, create, edit, and activate/deactivate projects
- Surveys — view, create, edit, preview, publish, and delete surveys
- Templates — view the shared template library, save/edit templates, and delete (or restore) them
- Codes — view, generate, print, and delete access codes
- Responses — view and delete submitted responses
- Backups — export and import survey data
- Media — view, upload, and delete images in a project's media library
- Themes — change the application's color theme, or its name/branding
- Users — view, create, and edit users (their basic info, their permissions, or the projects they can access, each controlled separately), plus activate/deactivate them
- Roles — view, create, edit, and delete role presets
Most permissions are scoped per project — having surveys:edit doesn't mean you can edit surveys in every project, only the ones you've specifically been given access to. Templates are the exception: since the template library is shared across the whole install rather than belonging to any one project, template permissions apply everywhere at once, the same way user- and role-management permissions do.
Roles
A role is just a preset — a quick way to fill in a new user's permission checkboxes rather than ticking each one by hand. Editing a role later doesn't retroactively change anyone it was already applied to; it only affects new assignments going forward.
Every install starts with:
- Admin — a built-in, unremovable role. See below — being an admin isn't actually driven by these checkboxes at all.
- Surveyor — a ready-made, editable preset covering the everyday work of building and running surveys (creating and editing surveys, generating and printing codes, viewing responses, exporting backups, and using the media library and templates) without full user-management or administrative access.
You can create as many additional custom roles as you like.
Admin accounts
Being an "admin" is a separate flag on a user's account, not a permission or a role. An admin bypasses every permission check entirely, in every project, full stop — which also means a newly added permission automatically covers every admin the moment it exists, with nothing to update. Reserve this for the people who should genuinely be able to do anything.
Granting access
You can only grant someone a permission or a project you already hold yourself. A team lead who can manage users but only has access to their own project can add teammates to that project, but can't reach across into a project they don't have access to — even indirectly, through the user-management screen.