Roles and Permissions
Blueputto Roles and Permissions lets organizations control access with built-in roles and custom permission matrices for documents, settings, billing, and more.
Grzegorz
Roles and Permissions is Blueputto's lower-level access control workspace. It decides what people can do across the product after they already belong to an organization.
This is where the app moves beyond simple membership labels. Blueputto keeps a small built-in role model for defaults, then adds custom permission design for organizations that need cleaner boundaries across documents, settings, billing, and structure management.
System roles are the default foundation
Blueputto includes three built-in system roles: Owner, Admin, and Member. These appear as the starting access model for organizations and are available directly in invitation and member management flows.
System roles are intentionally fixed. When one is selected in the role details view, the page shows it as read-only and explains that built-in roles cannot be edited. That keeps the default access baseline stable and also matches the protected behavior in Members, where the owner account cannot be downgraded or removed.
In the current implementation, system roles are available above the Free plan, while custom role editing is reserved for Scale.
Custom roles use a resource-action permission matrix
On the Scale plan, Blueputto adds editable custom roles. The Roles workspace is structured as a split view: a role list on one side and the selected role details on the other, with a mobile sheet version of the same details flow on smaller screens.
The permission model is grouped into product sections such as Workspace, Settings, Organization, Features, and Developers. Inside those sections, teams can grant actions such as create, read, update, delete, cancel, sign, or void depending on the resource.
That matrix covers resources such as Home, Documents, Document Signatures, Deleted Items, Activity, Members, Invitations, Teams, Roles, Plan and Billing, Folders, Collections, Data Models, Categories, Statuses, Labels, and API Keys. Blueputto is not asking only whether someone is a member. It is asking exactly what they should be allowed to touch.
Roles work below teams, not instead of them
The useful distinction is this: roles control capability, while teams control scope. A role can decide whether someone may update folders or read billing. A Team decides which folders or collections that person should even see in the first place.
That separation keeps Blueputto's access model more coherent as an organization grows. Members assigns the person to the workspace. Teams narrow their working area. Roles and permissions define what that person can do once they are inside it.
