Skip to main content
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.

​
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. 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. 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.

​
Use the global Back button without losing context

When you reached the current page from another KayanOS page, the global header Back button returns through the real in-app history. It preserves the page you actually came from, including its search parameters, filters, tabs, and other route state. For example, opening a record from a filtered queue and selecting Back should return to that filtered queue rather than reconstructing a generic parent URL. If you opened a deep link directly and there is no earlier KayanOS history entry, Back uses the nearest canonical section list. A directly opened form workspace returns to Forms, a record detail returns to its entity list, and a top-level section list returns to Home. This fallback is navigation only: it does not reveal a section or record that the current member cannot access. Back controls inside dialogs, builders, previews, and mobile panels manage their own local step or surface. Do not use the global button to abandon an unsaved edit without checking the page’s save or discard state first.

​
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

KayanOS navigation available to a public-service organization member.