Most access in Blue Butterfly is managed through project-level roles — Owner, Editor, Viewer, assigned per-project. That covers the day-to-day.
For administrators of restricted deployments, an additional system-level access control layer exists. It runs above project roles and decides whether a user can sign in at all.
What system-level access does
System-level controls are managed by Blue Butterfly administrators (your organisation’s IT or the platform operator) and answer two questions independently of any project:
- Who can sign in to the platform at all? — the allowlist
- Who is blocked from signing in? — the block list
These rules apply before project access is checked. A user blocked at the system level cannot sign in, regardless of being an Owner of a project.
Block list
Adding a user to the block list prevents them from signing in. Use cases:
- An employee leaves the organisation and you want to revoke access immediately
- A compromised account needs to be locked out
- Compliance requires access removal pending review
Blocking is reversible — removing the block restores access (assuming the user still has project assignments).
Allowlist
In some deployments — typically internal corporate or government — Blue Butterfly is configured to restrict access to a specific list of users. In allowlist mode, only users on the allowlist can sign in, regardless of having a Blue Butterfly account.
This is most often used to enforce email-domain restrictions or pre-approved user lists.
How to manage it
System-level access is managed through the underlying user_access_control table in the Supabase database. There is no standard UI for it — most users won’t see anything related to system-level access.
To request changes:
- Inside an organisation that runs its own deployment — contact your IT or platform administrator
- On the hosted Blue Butterfly service — contact Blue Butterfly support
You’ll need to provide the user’s email and the action requested (block, unblock, allowlist).
How this relates to project roles
| Layer | What it controls | Managed by |
|---|---|---|
| System-level | Whether the user can sign in at all | Administrators (database / support) |
| Project-level | Whether the user can view, edit, or own a specific project | Project Owners (in-app, see Collaborators & Roles) |
A user must pass system-level checks and be assigned to a project to use it. Removing a user from a project doesn’t sign them out of the platform — they keep their account, just lose access to that project.
When to use which layer
- Day-to-day — project roles. Add/remove people from individual projects via Project Settings.
- Onboarding/offboarding employees — system-level allowlist or block list. Stops the user from signing in entirely.
- Compromised account — system-level block list. Immediate, regardless of project assignments.
- External collaborators — project roles only, usually as Viewer or Editor on the specific project they’re working on.