Admin workspaces and navigation

The BitzOrcas admin application does not expose every module as a top-level menu. After sign-in, the primary navigation rail contains only the business workspaces available to the current account. The secondary panel contains the real tasks within the selected workspace.

The seven workspaces

The current menu seed enables three tenant workspaces and four Host workspaces. Host workspaces are visible only in Host scope to platform operators with the corresponding permissions.

Legacy codes such as workspace.operations, workspace.workflow, workspace.ai, workspace.insights, workspace.commercial, and the former split Host roots remain in the seed for upgrading stored menu data. They are marked IsMenu=false and Enabled=false, so they are not active workspaces.

Files, Notifications, and Sandbox remain distinct capability owners, but that does not give each one a root workbench. The human /notifications leaf belongs under Organization & Access Control, while the header also exposes personal notifications. File capability is embedded in attachment flows such as chat, and Sandbox has no business menu.

Navigate between tasks

1. Select a workspace on the primary rail. Hovering an icon reveals its full name.
2. Select a task in the secondary panel. Workspace and page selection have distinct active states.
3. The page breadcrumb shows “workspace / current page”. Open the workspace breadcrumb to switch to another authorized task without reopening the secondary panel.
4. Use local task navigation for ticket projects, boards and sprints, billing plan lists, and similar tasks that belong inside one module.
5. Refresh, direct links, browser Back, and browser Forward preserve the active route.

On desktop, the secondary panel can be resized from its trailing divider. Arrow keys, Home, and End are supported, and a double click restores the default width. The resizer is removed on narrow screens to prioritize content.

Sticky page context

The full page title, description, and actions appear at the top of the content area. Once that header scrolls out of view, a compact title, breadcrumb, and primary actions move into the global toolbar. Returning to the top restores the expanded header.

The breadcrumb task switcher remains available when the secondary panel is collapsed. It is generated from the same server navigation tree and only lists real routes available to the current account.

Pin a page and its filters

Use Pin current page beside the page title to save the current route. Non-sensitive search, status, pagination, and other URL-based filter values are stored with it. The bookmark entry in the global toolbar opens pinned views across workspaces.

1. Configure the page and filters you want to preserve.
2. Select Pin current page and enter a name from 1 to 80 characters.
3. Open the saved entry from Pinned views to restore the route and filters.
4. Open the pin action again to rename or remove the saved view.

A pinned view belongs to the current user in the current tenant, with a maximum of 30 views. Password, token, and secret query keys are rejected. API paths and external URLs cannot be pinned. A pinned view does not grant authorization; the latest route, permission, and feature checks still apply when it is opened.

The page saves the path and query string through the unified SDK rather than constructing a full external URL:

// These fields match CreatePinnedViewRequest exactly.
const result = await api.createPinnedView({
  name: pageTitle.trim(),
  path: location.pathname,
  queryString: location.search,
});

When opening a server-returned view, the client validates the in-app target again so damaged or legacy data never reaches the router directly:

// safePinnedTarget rejects double slashes, backslashes, fragments, and control characters.
const target = safePinnedTarget(view);
if (target !== null) {
  navigate(target);
}

AI conversations and team chat

AI chat has searchable conversation history that can be collapsed or resized on desktop and opened on demand on mobile. The message timeline owns its scrolling, while the composer remains at the bottom of the workbench throughout long responses.

• responses stream progressively and can expose a separate reasoning view;
• supported models can run web search and show search activity and cited sources;
• completed image and file uploads can be attached, with count, media-type, and size limits checked before sending;
• generated content can include images, files, sources, and token usage;
• Stop closes the current generation, while completed replies are restored from conversation history;
• idempotent request handling prevents one send action from creating duplicate persisted messages.

Team chat follows the same collapsible, resizable rail and bottom composer pattern. Channel members, message history, mentions, attachments, edits, deletion, read position, and real-time state are persisted by the server. After a temporary disconnect, the page refreshes the authoritative HTTP state instead of depending on missed real-time events.

Tickets and project tracking

The ticket workspace combines projects, boards, sprints, lists, and ticket details. A board is a real Kanban surface rather than a list with a board label:

• cards are grouped into board columns and open the full ticket details;
• authorized users can drag cards between columns; WIP or server rejection restores the original position and explains the failure;
• ticket creation includes subject, description, project, type, priority, severity, labels, and due date;
• dynamic project and assignee controls support search, keyboard selection, loading, empty, and failure states;
• details support edit, assignment, comments, attachments, and resolution with a stable return path;
• list and board views share project, status, priority, assignee, and keyword filters.

Search and data lists

List pages follow a shared interaction model:

• enter the name, code, or other documented keyword in the search field;
• use structured filters to reduce the result set;
• review and remove individual values in the applied-filter summary;
• refresh data without clearing the current query;
• use the footer for result range, total count, page size, and page navigation;
• use sortable headers that expose the active sort direction;
• horizontally scroll only the table container on narrow screens.

An empty business collection is different from a filtered query with no matches. A failed request provides an explicit retry without requiring a full browser refresh.

Create, edit, and confirm operations

Create and edit tasks normally open in a right-side operation sheet so the underlying list context is preserved. Short operations such as rename, approval, and ticket resolution use a consistent dialog.

• required fields display a marker;
• field descriptions explain formats and business boundaries;
• users, roles, organization units, projects, products, plans, and AI resources use searchable, keyboard-accessible selectors with loading, no-result, and failure states;
• small fixed enumerations, such as status or protocol version, use a regular selector;
• when a dynamic catalog is temporarily unavailable and the server accepts a stable identifier, the form may provide a validated ID fallback; copy that ID from a trusted detail page or an administrator;
• inactive historical values stay visible and are labelled instead of being silently removed;
• field errors remain next to their controls and are announced to assistive technology;
• a rejected submission moves focus to the first invalid control; searchable selectors provide keyboard search, arrow-key selection, and explicit loading, empty, and failure states;
• submission disables repeated saves while preserving the entered values;
• server rejection stays on the current surface with an actionable explanation;
• success closes the surface, refreshes affected data, and shows confirmation;
• delete, revoke, archive, suspend, secret rotation, and similar dangerous operations require confirmation.

API keys, HMAC secrets, and webhook secrets are shown only once after creation or rotation. Store them in an approved credential manager before dismissing the result.

Identity entry points

Sign-in, forgot password, reset password, invitation acceptance, account activation, email or phone verification, session expiry, and external sign-in completion share one branded Identity experience. The C4D scene provides product character while the form remains readable and keyboard accessible. Narrow screens and reduced-motion preferences receive a restrained presentation.

Forgot-password submission returns the same outcome whether an account exists, which prevents account disclosure. Open invitation, activation, and reset links only from trusted messages and never forward their tokens.

Password requirements come from the Identity API and are shared by sign-in recovery, reset, and change-password flows. The UI explains both character-category and UTF-8 byte limits, so accented letters, CJK text, and emoji are evaluated consistently before submission.

When an administrator requires a password change after first sign-in or a risk event, the application opens a dedicated security page. Navigation and other business APIs remain unavailable until the password is changed; the server enforces this boundary, so a refresh or manually entered URL cannot bypass it. After success, the current session is revoked; a successful sign-in then returns to the original trusted in-app route. Changing or recovering a password also revokes renewal credentials on the account’s other devices, so an old session cannot continue to renew indefinitely.

Common states

Mobile browsers

The admin application remains usable at phone widths, although dense tables and batch operations are more efficient on desktop:

• primary and secondary navigation collapse into the narrow-screen layout;
• title, description, filters, and actions wrap to the available width;
• the whole page does not require horizontal dragging;
• tables retain their own horizontal scroll container;
• operation sheets use the available viewport width;
• primary actions keep keyboard focus behavior and accessible names.

Troubleshoot authorization

If a menu is visible but the page returns 403, or a server rejects an operation:

1. sign in again to refresh roles and permissions;
2. confirm that the current tenant has the required feature enabled;
3. ask an administrator to verify both page-view and operation-specific permissions;
4. provide the route, operation name, and trace ID to the operations team.

Do not construct /api/... URLs to bypass navigation. APIs are not operator workbenches and always remain behind server authorization.