Navigate KayanOS

KayanOS navigation is designed around the work a member is allowed to do. Your sidebar may not match a colleague’s: applications, sections, entities, forms, and dashboards can be shown or hidden according to published configuration and assigned access. Treat the menu as a guided path to available work, not as proof that every action inside a page is allowed. The Citizen Services Directorate scenario in this guide follows a Service Manager from a Home notification to CSR-2026-00042, then to the related inspection, scheduled event, evidence file, and daily task list.

​

Use the header trail

The header names your location through Home, application, section, page, and any deeper record levels. Select an earlier level to return there. Section and page menus offer available neighboring sections or pages, and supported record lists can switch view mode from the trail. Menus reflect the available navigation; they do not grant access to an otherwise restricted record.

​

Goal

Use the right navigation path for the job, recognize the difference between page visibility and action permission, and diagnose a missing or unavailable menu item without granting unnecessary access.

​

Orient yourself by purpose

Begin with the work you have, not with the screen you remember. A notification normally takes you to its target. A task opens the next accountable action. A record relation opens the related inspection or evidence. A dashboard summarizes a queue but should lead you back to the record before you change an individual case.

​

How navigation is assembled

KayanOS combines fixed work tools with organization-specific applications. A published application can contain sections, entities, forms, and dashboards. Dynamic entries are filtered by the actions assigned to the current member:

• an entity normally needs an allowed list or create path to be useful in navigation;
• a form can appear when the member can list, create, or initiate it; and
• a page may still contain finer-grained controls that require a different verb or the record’s own scope.

This means the correct question is not “Why can my colleague see a menu I cannot?” but “Which approved service resource and action does the colleague have that I do not need?” Do not grant a broad Builder or administrator role merely to make a menu item appear. Navigation information is maintained per organization and can refresh after published configuration changes. If a recently authorized item does not appear immediately, verify the assignment and the current organization first, then use the organization’s approved refresh/sign-in process. Do not assume that a stale-looking menu proves the server has granted access, and do not bypass a denied route by sharing a direct link.

​

Use application workspaces and search

Multi-page applications open a workspace home when they have an available section destination. This includes organization-defined applications and permission-filtered areas such as Build and Settings. The workspace groups entity lists, forms, submission queues, dashboards, and settings pages by their assigned application section. Single-purpose applications such as Email, Chat, Calendar, Tasks, and Library open their primary screen directly; they do not add an intermediate home page. An unknown, conflicting, inaccessible, or permission-filtered empty workspace shows a safe placeholder rather than disclosing hidden destinations. Each workspace card shows a visible key hint for quick keyboard opening, and recently opened destinations can appear above the section groups. These recent items are stored for convenience; they do not pin a resource, change its publication state, or grant access. When focus is not in a text field, editor, or selector, pressing the displayed single key opens the matching workspace card. Built-in Home applications and built-in system destinations keep identity-owned keys when cards reorder, permissions hide sibling destinations, or organization-defined cards are added. An organization-defined destination can instead receive an available mnemonic or fallback from the current visible set, so its hint can change as that set changes. Read the card label and its displayed key before using it; a hidden, disabled, or inaccessible destination does not open through its reserved key. Use Cmd+K on macOS or Ctrl+K on other desktop platforms to open launcher search. Search can return available applications, pages, forms, records, recent destinations, utilities, and registered commands. It can match a page title in another configured interface language while keeping the result label in your current language. A specific detail page uses its record label when available, so recent-page and browser titles are more useful than a generic “Details” name. Search and command results remain filtered by current availability; finding an item does not bypass the target page’s permission or state checks. Home is also a full-screen launcher. Open Apps to browse applications without leaving Home, or use the launcher to reach account, support, language, theme, notification, and other available utilities. Star an application, application page, or utility to add it to your personal Home shortcuts; remove the star to remove the shortcut. Favorites follow the member inside the active organization, can include more items than the first visible row, and do not become shared organization navigation. If a saved favorite is retired or no longer available to you, KayanOS omits it rather than using the saved shortcut to bypass current access. Inside an application, launcher cards identify records, forms, and dashboards and can be filtered by those types. A record card offers only the views supported by that entity’s fields, and shows New record only when you have its create verb. A form card can start New submission and open My Submissions when that form is available to you. Selecting the main card still opens its normal page. These shortcuts do not grant record, form-session, dashboard, or underlying data access. If an expected view is absent, check the entity’s field model in Entities; if a direct action is absent or denied, check the narrow resource verb instead of broadening the whole application role. On phones, use the header trail and available search control to navigate. Check unsaved edits before leaving the page.

​

While a page loads

After you select a destination, the current page can remain visible briefly while a thin progress bar appears at the top. Fast transitions may finish without showing the bar. A slower destination can show a loading screen, and a page waiting for its data can show a spinner. Wait for the destination and check its title before taking an action. The bar indicates navigation, not that a record has been saved or a request approved. If loading does not finish, check your connection and follow Troubleshooting, preserving unsaved work before refreshing. Existing destination permissions still apply.

​

Use explicit return controls

Use the header trail to return to the application, section, or record list. Record details can preserve the list view in their return destination; a direct link without a view can return to Table. Returning does not restore unsaved changes or make an unavailable view valid. On an application-owned dashboard, the application level returns to that application’s workspace under your current access. Back controls inside dialogs, form submissions, builders, previews, and mobile panels manage their own local step or surface. Check the page’s save or discard state before leaving an edit.

​

Follow a service request in three paths

​

Path 1: start from a notification

1. Open the notification panel from Home.
2. Select the unread task or request alert for CSR-2026-00042.
3. Confirm the target record, task owner, status, and scope before changing anything.
4. Complete the work on the record or task itself, not in the notification summary.
5. Verify that the notification’s read state and the task/record activity reflect the action you took.

Expected result: the member reaches work that is both relevant and permitted. If the target is unavailable, diagnose scope or role access instead of copying data into a different channel.

​

Path 2: start from an application queue

1. Open the application containing Citizen Service Requests.
2. Use the record-list filters available on that entity—for example, service center, status, owner, date, or category—rather than relying on a global memory of the record title.
3. Open CSR-2026-00042 and verify its serial reference, status, owner, and next action.
4. Use related records to open the inspection; use the task, event, or Library link only when it supports the work you are doing.
5. Return to the request before recording the authoritative operational result.

Expected result: the record remains the service hub even when work passes through tasks, events, messages, and files.

​

Path 3: start from daily work

1. Open Tasks for assigned, owned, contributing, informed, or related work.
2. Open Calendar for a scheduled inspection or review window.
3. Open Chat for internal coordination and Email for an approved mailbox workflow.
4. Open Library for controlled evidence and approved documents.
5. Use Profile for personal language, notification, account, and signature-management settings.

Expected result: the member chooses the tool that matches the job without confusing a task with the underlying request or a file with a public-access link.

​

Desktop and small-screen behavior

On larger screens, KayanOS presents the sidebar with the main content area. On smaller screens, the app uses a mobile header and adapts certain routes for constrained space. For example, the chat entry opens the conversation/contact list path on small screens, and Calendar is presented as an agenda-style view rather than the full desktop scheduler/editor. Before documenting a local operating procedure, test it on the devices staff actually use. Do not write “tap the same sidebar item” if the small-screen route, layout, or available action differs. Use the page’s own mobile section—especially Calendar—for the supported behavior.

​

Availability and permissions

Use this checklist when a member says, “I cannot find it”:

1. Confirm the member is in the correct organization context.
2. Confirm the application, entity, form, or dashboard is published and intended for that member’s service.
3. Confirm the member has the relevant verb, such as list, open, create, update, or initiate.
4. Confirm the related record lies in a scope the member may access.
5. Confirm the feature’s own prerequisites: active mailbox for Email, accessible space for Library, or configured records for the application queue.
6. Test the same target with an authorized role owner before changing a role assignment.

A direct URL is not an access workaround. The service should return a permission denial or empty result when the member is not entitled to the resource.

​

Safe testing

Use a controlled Citizen Service Request and two test members with different roles. Publish one approved application section, give only one member the necessary list/create/update verbs, then compare visible navigation and permitted actions. Record both results. Remove the temporary grant after testing.

​

Troubleshooting

​

Related guides

• Learn how available work appears on Home and notifications.
• Design least-privilege access in Roles and access.
• Follow the end-to-end service path in Explore an example workspace.
• Build published applications in Plan an app before building.
• Diagnose access boundaries in Permissions and availability.