A workspace is Havilo's operating and authorization boundary. It owns a local data model, entities, relationships, notes, lists, artifacts, conversations, members, and product configuration.
Most work in Havilo occurs inside one active workspace. Search, reasoning, and application views use that workspace's data and enforce the access of the person making the request.
Access layers
Several layers answer different access questions.
| Layer | What it controls |
|---|---|
| Membership | Whether a person belongs to the workspace |
| Role | The member's baseline permissions |
| Permission set | Additional permissions granted to selected members |
| Field restriction | Which roles cannot see a particular entity field |
| Object visibility | Who can open a particular list or artifact |
| Workspace feature | Whether a product capability is enabled for the workspace |
These checks compose. Access to an AI feature, for example, can require an active workspace membership, the relevant member permission, and an enabled workspace feature.
Members, roles, and ownership
Every member has one role. New workspaces include four system roles:
| Role | Baseline access |
|---|---|
| Administrator | All workspace permissions |
| Member | Create, read, update, and delete entities; work with Notes; use AI features |
| Viewer | Read entities and Notes |
| Network Sharing | Read entities. Only for sharing your network; it can't be given to a person |
System roles are maintained by Havilo. A workspace cannot rename, delete, or re-permission them; a Havilo system administrator can change which permissions they carry, but not their names. A workspace can define custom roles with a different set of permissions.
Permissions cover entity and Note operations, workspace settings, members and roles, exports, bulk operations, API keys, and feature access. Some permissions imply the access they depend on: entity update includes entity read, and entity delete includes update and read.
The role and permission set editors only list a feature's permissions while the workspace has that feature. Turning a feature off hides its permissions without removing them from any role, so turning it back on restores what each role had.
Situations are their own permission. A member sees the Situations page, the Home note, and the inbox extension's panel only with SITUATION_ACCESS, and Havilo judges attention only for members who hold it. Only the Administrator role includes it by default; Member, Viewer, and custom roles do not, so a workspace can run the harness for a few people through a permission set while everyone else keeps the Havilo they had. Existing workspaces were not backfilled: a member who should see Situations is granted it deliberately.
The workspace owner is marked on the membership separately from the role. The owner uses the Administrator role, cannot be removed or assigned another role, and can transfer ownership to another current member.
Permission sets
A permission set adds permissions to the member's role without changing that role for everyone else. This is useful when one member needs a narrow exception, such as exporting entities or managing API keys.
Permission sets are additive. They do not subtract permissions already granted by a role. An assignment can be revoked or expire without changing either the member's role or the permission set itself.
Fields and shared objects
Access to a workspace does not make every object and field equally visible.
- Entity fields are visible by default but can be hidden from selected roles. The Name field remains visible, and owners and Administrators can read all fields.
- Entity Lists can be shared with selected members or the whole workspace. See Entity Lists.
- Artifacts support owner-only access, selected viewers, and workspace sharing. Situation Work research artifacts and email drafts also inherit visibility for current members with
SITUATION_ACCESSwho can open the associated Situation. See Artifacts. - Notes require Note read access. Owner-private field memos remain outside shared Note, entity, and general AI surfaces even when the owner belongs to the workspace.
Object visibility does not bypass the underlying permission model. A member who can open a list still sees only the entity data their role permits.
Workspace features
Workspace features determine which parts of Havilo are enabled under the workspace's license and configuration. They are separate from member permissions: enabling a capability does not grant every member access to it, and granting a permission does not enable a capability the workspace does not have.
API keys show this distinction. The workspace must have API access enabled, and the person creating a key must have permission to manage API keys. Each workspace key is then scoped to that workspace and to the permissions or API scopes assigned to it. See API authentication.
Connected accounts
A connected Google or Microsoft account belongs to the user, not to a workspace. Its provider credential is stored once and is never copied into a workspace.
The user explicitly shares Mail or Calendar from that account with each workspace that should receive it. Every assignment has its own sync state and materializes workspace-scoped data. Removing one assignment retracts that workspace's access without disconnecting the provider account or disturbing another workspace.
Losing workspace membership removes the connected-account assignments for that workspace. It does not revoke the user's provider account or its assignments elsewhere.
Across workspaces
Switching workspaces changes the active entities, Notes, artifacts, conversations, mail, calendar data, permissions, and features. A conversation remains with the workspace where it began.
When you share your network with another workspace, you pick one of your roles for it, Network Sharing unless you choose another. The other workspace reads your records the way a member with that role would: fields hidden from the role stay hidden, and your team's Notes are shared only if the role can read Notes. Dossiers and enrichment Notes are always shared. If the role can update linked records, a person linked to one of your records can edit that record from their own workspace. Nothing else in the role applies across workspaces. Changing the role, or the role's permissions, changes what every workspace you share with that role can read.
Selected entities can be copied between workspaces a person can access. Copying creates or updates local objects in the destination; it does not make one entity row jointly owned by two workspaces or mutate the source. Compatible types, fields, Notes, identities, and relationships can be carried with the selected graph, while private ownership state, lists, artifacts, mail, and calendar events stay behind.
Where Global Network access is enabled, Havilo can also resolve public identities and reuse public research without exposing another workspace's private records, correspondence, Notes, or artifacts.