Workspaces, publications, and roles
Understand Prosewire's tenant boundary and the permissions carried by each workspace role.
Workspace versus publication
A workspace owns the team. A publication owns content, public reader URLs, API keys, analytics, authors, categories, redirects, and exports. One workspace can contain multiple publications.
Self-hosted Prosewire creates one implicit workspace for the installation. The dashboard presents it as the team, while owners switch between publications such as separate product blogs. Cloud exposes workspaces because one account can create or join multiple independent teams.
The dashboard stores the active workspace in the authenticated session and the active publication in an HTTP-only cookie. Cloud users and upgraded self-hosted installations with legacy workspaces can switch workspaces. Every switch revalidates membership before accepting the selection.
Role matrix
| Role | Capabilities |
|---|---|
| Owner | Ownership transfer, workspace settings, members, publications, content, integrations, analytics, and audit history |
| Admin | Workspace settings, members, publications, content, integrations, analytics, and audit history |
| Editor | Create, edit, schedule, publish, and archive all content; read analytics and integration details |
| Author | Create drafts and edit only posts they created; read analytics and integration details |
| Viewer | Read dashboard content, analytics, and integration details without mutations |
Invitations are sent by email, expire after 48 hours, and can be canceled before acceptance. Owners cannot be demoted or removed through routine role editing.
Transfer ownership
An owner can use Authors & team → Transfer ownership to hand ownership to an existing member who is not already an owner. Select the member and confirm the role change: that member becomes an owner and you become an admin. Other existing owners keep their roles. Invite a new person and wait for them to accept before transferring to them.
The role changes and audit entry commit together. Concurrent transfers, role changes, and removals recheck membership after acquiring the workspace lock. Publication API keys and the SDK, CLI, and MCP built on them cannot manage workspace membership. The dashboard does not expose workspace deletion.
Public author profiles are separate from workspace memberships. A member can have an author profile for one publication without that profile automatically applying to every publication in the workspace.
Integration isolation
Private API keys belong to one publication. A key may have content:read, content:write, or both scopes. Selecting a different publication in the dashboard does not broaden an existing key.
Read-only public JSON, rendered HTML, RSS, sitemap, and reader routes do not require an API key and only expose content that has reached its publication time.