bublliodocs
Product guides

Roles and access: who can do what?

This is the short, practical guide. For API behavior and implementation details, read Authentication, Organizations, and Roles.

This is the short, practical guide. For API behavior and implementation details, read Authentication, Organizations, and Roles.

The two levels

Think of an installation as the entire Bubllio deployment and a workspace (Organization in the API/database) as a separate place for a team's CRM data. A Company is a customer or prospect inside a workspace; it is not another workspace.

LevelRole or grantWho assigns it?What it means
InstallationInstallation administratorThe first-run setup creates the first one; an existing installation admin may invite more.Manages installation policy and fallback SMTP, invites IT admins, and creates workspaces. This is a Django superuser.
WorkspaceOwnerFirst-run setup, self-nomination at creation, or acceptance of an initial owner invitation; later owners receive a transfer from the current owner.Normally one owner per workspace, responsible for its administrators and lifecycle. The database prevents two owners.
WorkspaceAdminInvited or promoted by the owner.Manages daily workspace operations but cannot appoint admins, transfer ownership, or delete the workspace.
WorkspaceMemberInvited by an owner or admin.Contributes CRM records; cannot manage workspace settings or members.
WorkspaceViewerInvited by an owner or admin.Reads workspace data without creating records.

The installation role and a workspace role are independent. For example, Maria can be an owner in Workspace A, a viewer in Workspace B, and have no access to Workspace C.

Workspace permission matrix

These are permissions in the current application, not proposed features. “Read CRM” includes companies, contacts, automation rules, and run history. “Create CRM” means creating companies and contacts; edit/delete endpoints for those records do not exist yet.

Action inside this workspaceOwnerAdminMemberViewer
Read CRM and automation history✓✓✓✓
Create companies and contacts✓✓✓—
Create and manually test automations✓✓——
View workspace settings and SMTP account metadata✓✓✓✓
Change workspace settings or SMTP; send SMTP test email✓✓——
See members and pending invitations✓✓——
Invite, change, or remove members/viewers✓✓——
Invite, promote, change, or remove admins✓———
Transfer ownership✓———
Delete the shared workspace✓———

An admin cannot change or remove another admin. The current owner cannot be removed or demoted directly: ownership must be transferred first. A personal workspace cannot be deleted or shared through the current API.

Example: a new team workspace

  1. The IT installer completes first-run setup. This person becomes an installation administrator and owner of the initial workspace.
  2. Only an installation administrator creates a new workspace and nominates its business owner.
  3. The creator enters a workspace name, slug, and the business owner's email. If the email belongs to somebody else, Bubllio sends a seven-day owner invitation using installation fallback SMTP.
  4. Until that person accepts, the new workspace is pending and hidden from normal CRM screens and API access, even for its creator. The creator or an installation admin can resend the invitation or cancel the pending workspace.
  5. On acceptance, the invited person becomes owner and the creator's temporary membership is removed. The owner can now invite admins, members, and viewers.

If the creator deliberately enters their own email as initial owner, the workspace is available immediately and no owner invitation is needed. Creating a workspace does not itself give ordinary users access; access starts only after invitation acceptance creates a membership.

Visibility and security limits

  • A normal user sees only workspaces where they have an accepted membership. Within such a workspace, all four roles can read all CRM records. There are no record-by-record, team, or field visibility rules yet.
  • An installation administrator has no automatic membership in unrelated workspaces through the REST API. However, this role is a Django superuser and can access data through /admin/; reserve it for trusted IT operators.
  • Ordinary users cannot create shared or personal workspaces.
  • Workspace creation, invitations, role changes, member removals, email-connection changes, installation settings, and data-export downloads have a read-only operational audit log for installation administrators. Passwords, invitation links, and other secret values are excluded.

The backend checks permissions on every request. Hiding a button in React is only a convenience; it is not the security boundary.