Explore an example workspace

This guided scenario shows how KayanOS objects connect in one public-service workflow. It is not a template to copy word for word. Treat it as a practical map: replace the sample roles, statuses, field keys, and policy thresholds with your organization’s approved service design. The scenario uses a controlled request reference, CSR-2026-00042. A Registry Officer receives the request, a Service Manager assigns the work, a Field Inspector records evidence, a Records Officer prepares the document packet, and an Authorized Reviewer records the final outcome. Every step keeps one durable service record at the center.

​

Goal

Understand how a staff member moves between Home, tasks, records, calendar, chat, email, Library, and personal settings without losing the source of truth or expanding access unnecessarily.

​

Before you begin

Use a safe training or non-production context approved by your organization. Create only synthetic service details and use policy-approved internal recipients for any communication test. Confirm that the people participating in the walkthrough have deliberately different roles: If any member sees more than needed, stop and correct Roles and access before continuing.

​

The request at a glance

Create or open a Citizen Service Request record with a human-readable serial ID such as CSR-2026-00042. The record should contain the service category, location, requester path, description, current status, accountable owner, and the fields required by your policy. Where applicable, a calculated value such as estimated_fee should be derived from approved source fields, not typed manually. The request record is the operational hub. It should answer these questions without asking staff to reconstruct the case from separate messages:

• What service was requested, by whom, and where?
• What is the current approved status and who owns the next action?
• What evidence is required, received, missing, or under review?
• Which inspection, task, event, file, or decision relates to the request?
• What is the final outcome, and what communication or follow-up remains?

​

Walk through the service

​

1. Intake and completeness

1. The Registry Officer opens the intake form or internal request-entry path.
2. The officer records the controlled service information and attaches only permitted training files.
3. KayanOS assigns the request reference according to the configured Serial ID rule.
4. The request begins in the approved initial status, such as Received.
5. A completeness task is created or assigned according to the service design.
6. The officer opens the resulting record and verifies the serial reference, requester path, category, location, status, and task relationship.

Expected result: there is one request record with an accountable next action. The serial reference can be used in internal discussion and approved documents, while the stable field keys remain available to configuration and expressions. If it does not work: check form publication, create permission, field validation, serial configuration, and whether the record belongs to the officer’s approved scope. Do not create a second request merely because the first submission needs correction.

​

2. Triage and ownership

1. The Service Manager opens Home and reviews the task or notification for the new request.
2. The manager opens CSR-2026-00042, reviews the completeness outcome, and becomes or assigns the accountable owner according to policy.
3. The manager sets the appropriate priority and next status.
4. If a field visit is necessary, the manager creates a related Inspection record rather than placing all future findings into a long-text request field.
5. The manager assigns the inspection task to the Field Inspector, adds a contributor only when another person must actively work, and adds an informed member only when they need awareness.

Expected result: responsibility is unambiguous. The request owner is accountable for the service outcome; the task assignee is accountable for a particular action. These roles may be the same person, but they should not be confused. Access check: sign in as the Field Inspector. The inspector should be able to open the intended request/inspection path and update the authorized finding fields, but should not gain access to unrelated service-center requests or role settings.

​

3. Plan the inspection

1. On a desktop-sized device, open Calendar and create the inspection event.
2. Set the title, start/end time, approved timezone, internal attendees, location or meeting room, agenda, and expected next steps.
3. Check attendee and location conflicts before saving.
4. If the visit repeats, configure the approved recurrence pattern and test how future occurrences appear.
5. Link the event context back to the request in the operational notes or related task according to your organization’s design.

Expected result: the team has a coordinated time window without treating the event as the inspection outcome. On small screens, staff should expect an agenda-style calendar view rather than the full desktop scheduler/editor. Boundary to remember: listing an attendee does not, by itself, prove that an external invitation email or external calendar synchronization was sent. Use the organization’s approved communication process when that is required.

​

4. Coordinate without losing the record

1. The Field Inspector opens the internal request conversation from Chat.
2. The inspector asks a concise operational question, mentions the responsible colleague where appropriate, and shares only information allowed in that conversation.
3. The team confirms the next action.
4. If the confirmed instruction needs ownership and a due date, create a task from the nonempty text message or create a related task directly.
5. The inspector returns to the inspection or request record and saves the authoritative finding there.

Expected result: Chat speeds coordination, but the request and inspection records remain the audit trail for facts and decisions. A message can be reacted to, replied to, or forwarded where available; editing/deleting a persisted text message is restricted to its sender.

​

5. Record inspection evidence

1. The Field Inspector opens the related inspection record.
2. The inspector records the visit date, observed condition, result, and any required structured fields.
3. Upload the report, photographs, or supporting documents to the approved record file field or restricted Library folder.
4. The Records Officer opens the evidence packet and checks file names, completeness, and permitted sharing scope.
5. Where the policy requires it, the Records Officer adds the approved document metadata or relates the file back to the request.

Expected result: evidence is stored in a controlled location with an understandable relationship to the service request. A copied Library link remains subject to access rules; it is not a public-access grant.

​

6. Prepare citizen communication

1. The authorized mailbox user opens Email and confirms an active accessible account.
2. The user selects the correct mailbox and permitted sender identity, especially when more than one account or sender is available.
3. The user verifies the recipient, request serial reference, language, subject, body, and attachments.
4. The user saves a draft when review is required; a draft is not a delivered message.
5. After the required review, the user sends under the organization’s policy and checks the send result for success, failure, or partial delivery.
6. The user records the relevant communication outcome on the request when the service policy requires it.

Expected result: the organization can explain who sent which approved communication about CSR-2026-00042, from which mailbox, with what evidence. The workflow never assumes that an email became deliverable merely because a draft was saved or a recipient was typed.

​

7. Decide, sign when required, and close

1. The Authorized Reviewer opens the request and its required evidence.
2. The reviewer checks the current status, inspection result, related tasks, documents, and policy prerequisites.
3. If a formal signature or controlled decision is required, use the published Form actions, logic, and signatures workflow.
4. The reviewer records the final status and outcome on the request.
5. The Service Manager checks that no active task, scheduled follow-up, or required communication remains, then closes the operational work.
6. Home, notifications, and dashboards should now reflect the new workload state, while the record preserves the full case history.

Expected result: the final decision is on the request through the approved workflow. Completing a task can confirm work was done; it is not automatically a substitute for a formal decision or signature.

​

8. Verify Arabic and English handoff

1. A staff member changes language from the profile menu and reloads the relevant work areas as the client does after a language change.
2. Review right-to-left direction, labels, record titles, statuses, task text, dates, numbers, notifications, and the service communication draft.
3. Confirm that custom field titles and statuses have approved Arabic and English text. A language switch does not translate unlocalized custom content automatically.
4. Record any terminology decision before publishing the service more widely.

Expected result: staff can operate the same service in the language and direction appropriate to their work without confusing a translated title with a stable technical key.

​

Safe test checklist

Before considering the walkthrough complete, capture the result of each check:

• one controlled request and serial reference were created;
• the Registry Officer, Manager, Inspector, Records Officer, and Reviewer saw only intended data and actions;
• one task, one event, one related inspection, and one evidence file linked back to the request;
• a calendar conflict and an access denial were tested safely;
• a Chat message created accountable follow-up without replacing the record decision;
• an email remained a draft until the policy-approved send step, with no real citizen recipient used in testing;
• file sharing/recycle behavior was tested with controlled evidence only; and
• Arabic and English labels were reviewed by someone who understands the service terminology.

​

Troubleshooting the walkthrough

​

Related guides

• Return to the operating model in Welcome to KayanOS.
• Learn the data model in Core concepts.
• Test least privilege in Roles and access.
• Navigate each handoff in Navigate KayanOS.
• Continue with Home and notifications, Tasks and approvals, Calendar, Chat and contacts, Email, and Library.