Organizations and workspaces

An organization is a customer or company; a workspace is its operational isolation boundary. A workspace is production or sandbox. Sandbox marks a training workspace with separate data and gc_test_ API keys, and connects to Channex staging; a production workspace connects to Channex production (environments, ADR 0050). The connection screen shows the environment before key entry. Neither organization ownership nor instance administration grants access to an unrelated customer’s data.

Provisioning

The first-run setup creates the first operator, organization and workspace atomically. That operator is also an instance administrator. Instance administrators create further organizations from the Organizations screen, including a first workspace and its environment. The creator receives the owner membership. Organization owners and administrators create further workspaces in their own organization. Workspace-only managers cannot do so.

Installation operators manage instance administrators with the protected recovery CLI: list, grant and revoke use owner database credentials and a private setup code supplied on standard input. Grants and revocations are idempotent, and serialized checks prevent removing the last administrator. Grant a replacement, verify the list, then revoke the departing operator.

Every provisioning write checks current authority and saves membership, audit and events atomically. The interface reports invalid names beside the field. A failed or cancelled write may already have committed: inspect the refreshed list before submitting it again.

Settings and archival

Workspace settings save the name with an ETag precondition. A stale edit is refused; reload and review the current value before saving again. Workspace locale and measurement defaults do not exist yet. Staff regional formatting follows the existing reader context, while each property retains its explicit time zone and currency.

Organization owners/admins archive or restore workspaces. Archiving is explicit and reversible. It retains properties, reservations, guests, folios, audit and memberships. Operational API requests from sessions, device tokens, API keys, organization tokens and client sessions cannot enter an archived workspace. An integration using a workspace API key receives 401 auth.unauthenticated; its refusal is audited with reason workspace_archived. An organization token or a client session is refused as its creator’s lost access to that workspace: 401 (audited creator_access) when it reaches no other active workspace, otherwise 403 for the archived one (audited workspace). Restrictive database policies also pause queued business work while it is archived. Administrators keep access to its recovery settings and can restore it. Unlink all Channex properties and finish webhook cleanup before archiving; the archive request is refused while a linked or cleanup-pending mapping remains. Saved credentials are retained, so a restored workspace can be linked again explicitly. No archive operation deletes data.

Restoring leaves night-audit automation paused for every property. Review each property’s business date and settings, then explicitly re-enable automation when ready; restoration does not automatically close missed business dates. At restore time, pending webhook deliveries strictly older than 246,960 seconds (68 hours 36 minutes, about 69 hours), the normal retry window, become expired instead of being sent. A delivery exactly at that boundary remains pending. Expired deliveries remain visible in the delivery log; an operator can manually replay their events within 30 days of the event. Stale queued events that have not yet produced delivery rows are also withheld: restore removes their old outbox routing markers, preserving the domain events for the same 30-day manual replay window. Review endpoint state and re-enable a disabled endpoint before replaying.

Restore history

Organization Activity retains the restore’s safe structured effects: the property IDs whose night-audit automation was paused, expired-delivery totals and counts by endpoint, and the number of old event routing markers withheld. Workspace Activity also records each affected property’s night_audit.settings_updated with enabled:false and reason:workspace_restored. These records survive reload and are committed with the restore; they contain identifiers and counts, never endpoint URLs, secrets or delivery bodies.

Activity and workspace selection

Organization owners and administrators can open organization Activity to read ownership, organization-role and workspace lifecycle entries. The filters match exact action, actor and subject identifiers and an instant range. Entries contain identifiers and safe change facts, not guest content. Organization Activity uses stable keyset paging on occurrence time and identifier, with limit from 1 to 100 (API default 20; the screen requests 50). Its opaque cursor is bound to the organization and exact filters; reuse with another organization or filter returns cursor.invalid. The response is { data, next_cursor, has_more }. Workspace Activity (Settings → Activity log, audit.view) pages the same way, 50 entries at a time, with a cursor bound to the workspace and its filters: keyset_cursor in, next_keyset_cursor and has_more out. Its numeric cursor offset and next_cursor remain for 6.6.0 clients, deprecated.

Both screens export the filtered entries as CSV or JSON. An export needs a from and until range of at most 366 days and holds at most 10,000 entries and 20 MiB: a larger selection is refused with activity.export_too_large, so narrow the range rather than receive a partial file. The export contains the stored identifiers and safe change facts the list shows, and nothing else. Each export is recorded as audit.exported with its format, count and filters, in the workspace Activity for a workspace export and in organization Activity for an organization export.

The switcher lists every workspace the browser member reaches, with its organization, and remembers recent choices for the signed-in user on that browser. Another user signing in on a shared front-desk computer gets their own recent list; the old shared cookie is ignored. The landing choice, workspace recents, and each workspace’s property recents use an opaque SHA-256 actor hash in their cookie names, so browser storage never exposes the raw usr_… identifier. Legacy browser-wide names are never read. Archived workspaces appear only for members who may configure or restore them, and the landing page prefers an active workspace. Preferences are never credentials. Each request resolves the chosen workspace and live membership again. Revocation therefore takes effect without signing in again. Device sessions retain their issuing organization and workspace API keys retain their workspace scope.

See ADR 0049, team management, and roles and property access. The running instance’s API reference and OpenAPI document define the exact resource schemas and problems.