Workspace details, branches and organization heads¶
Draft. The backend supports these operations. The guide follows the intended Tenant Admin design; the inspected frontend uses preview data. Connected operation and environment availability still need verification. Reader review and live delivery verification remain pending.
A workspace holds an organization's identity, memberships and product access. Branches group its members by physical location. An organization-head designation records leadership responsibility and can feed the organization's approval authority in WorkOS.
These are different responsibilities. A branch is not a department, reporting line or job position. An organization head need not be a workspace administrator. Making someone a head does not itself grant an administrator role or a product license.
Use the branch and leadership guide for the intended actions and their consequences. Workspace creation explains the initial organization record; profile and workspace access explains personal details and entry into a workspace.
Organization identity and administrative authority¶
The workspace record includes its display name, address label, company name, contact information, website, logo reference and lifecycle status. The current public detail response exposes only a subset of that record. The branch directory provides branch location and contact information. An absent branch display does not by itself establish that the person's workspace membership was deleted.
The current public tenant interface provides a detail read. This feature does not establish a connected screen for editing the entire organization profile. Do not assume that a Settings destination makes every identity field editable. Contact changes, policy, subscriptions and personal profiles have different owners and effects.
Branch administration and organization-head changes require an active account and an active administrator membership with branch access. A head designation alone is insufficient. An administrator assigned to a branch they deactivate can lose their own administrative access. Arrange another eligible administrator before making an access-affecting change; the branch deactivation path does not protect the last accessible administrator.
Branch information and creation¶
Each branch belongs to one workspace. Creation requires a branch name, an available active country and a city. Address and telephone number are optional. The time zone may be supplied; if omitted, the backend uses the country's configured default. A supplied time zone must be recognized by the server. Country selection does not establish hosting location or move stored data.
The stored limits are 255 characters for the branch name, 100 for city, 500 for address, 30 for telephone number and 50 for the time-zone identifier. Current request validation does not provide a dedicated length message for every storage limit. Keep entries within these limits and verify the saved result if a request fails.
A newly created branch is active and initially has no assigned members. Creation neither invites people nor purchases seats. Members can belong to the workspace without a branch. These operations do not themselves change plan prices, purchased capacity or product licenses; ordinary access and commercial rules still apply.
Assignment and access¶
| Change | Effect |
|---|---|
| Assign an active member to an active branch | Replaces that member's previous branch assignment; one member has at most one branch in the workspace |
| Remove an active member from their current branch | Leaves the member in the workspace with no branch; removes the restriction associated with that branch |
| Deactivate a branch | Retains the branch and assignments, but blocks assigned members' branch-dependent workspace access |
| Reactivate a branch | Clears the branch restriction for members still assigned there; other account, membership, product and workspace restrictions continue to apply |
Removing a branch assignment is different from removing a member from the workspace or deactivating their account. It does not revoke their licenses. Likewise, branch deactivation retains assignments and licenses while changing access eligibility.
The directory's assigned-member total includes non-cancelled memberships, including people whose membership is inactive. It is not a count of everyone who can currently use the platform. Compare each person's membership and access state before deciding who needs help.
Branch deactivation also requests notifications to affected active account holders and eligible administrators outside the affected group. Delivery depends on background processing and email availability. Where a person's enterprise role depends on the affected home-workspace membership, that role can be suspended. Branch reactivation does not automatically reverse those enterprise-role suspensions; review that authority separately.
Headquarters and reporting time zone¶
Mark the organization's primary branch as headquarters. The active headquarters time zone supplies a reporting reference for HiveOrbit. That is separate from an individual's preferred time zone.
Current headquarters handling has a limitation: creating a new headquarters clears the existing active headquarters flag, but an inactive former headquarters can retain its flag. Reactivating it can produce multiple active headquarters. HiveOrbit reference publication requires exactly one active headquarters and rejects a missing or ambiguous choice.
Before deactivating or restoring a headquarters, check the current headquarters arrangement and reporting impact. If the directory shows conflicting headquarters, ask the responsible administrator or support team to reconcile the records. The inspected screens do not provide a verified repair action, so this guide does not prescribe a speculative sequence of changes.
Organization heads and governance¶
An administrator can designate an active workspace member as an organization head or remove that designation. More than one head is supported, and removing the last designation is allowed. Neither action changes the person's workspace role, branch or product licenses directly.
The designation is more than a display label. For members synchronized into WorkOS, it feeds the system-managed organization-head approval body. Adding a head can establish voting membership there; the synchronization does not grant signing authority by default. Removing the designation ends that synchronized membership while retaining its history. Approval participation still depends on the relevant workflow and current authority checks.
These updates pass through background synchronization. A saved head list is not proof that every downstream approval view has already refreshed. Before removing the last head, consider work that relies on that body and arrange appropriate approval coverage. The platform does not promise automatic replacement of a removed head.
What is available in the current implementation¶
The backend has branch listing, creation, activation, assignment and organization-head operations. The frontend contains the designed pages, dialogs and sample records. Branch action buttons are not connected to the backend, and head changes only modify the page's local preview state. Reloading or seeing a changed card is not evidence of a saved organization change.
The initial checked-in staging selection excludes Tenant Admin. This draft therefore describes the intended journey and verified backend rules, while keeping live availability unverified. It does not promise branch deletion, a branch-profile edit screen, bulk atomic assignment, or automatic restoration of all downstream access.