Skip to main content
Library is the controlled home for working files, approved material, and service evidence. It gives teams a place to organize folders and files without turning email attachments or chat uploads into the only copy of an important document. It is not an unrestricted public file store: what a member can see, open, change, share, or remove depends on the space and the member’s assigned scope. In the Citizen Services Directorate scenario, the inspection report and approved response template for CSR-2026-00042 are stored in the designated service space. The request record contains the service facts and links to the required evidence; Library retains the files in a location that the correct team can govern.

Respect the owning record’s access and lock

Files in a record’s collection follow that record’s current scope and require access to open the owning record. A saved file link or an old scope stamp does not preserve access after the record’s scope changes. Library permissions and the collection’s placement permissions still apply. When the owning record is locked, member uploads and edits to its collection are refused, including document coediting, smart-document writes, moving items to the bin, restoring into the collection, and permanent deletion. Read the record’s lock message and use its permitted workflow transition or contact the owner. Moving evidence or a containing folder is not a way to bypass its access boundary; spaces containing record collections also restrict bin, restore, and purge operations. Reopen the record and its collection after an authorized scope or status change before retrying.

Review file details and comments

Open a file’s details drawer to review its information and available controls. Uploaded files support comments and mentions. Reading comments and adding them require the corresponding file-comment permissions in the file’s scope; a mention does not grant access to its recipient. Check the selected file before posting and use the permitted edit or delete action to correct a comment. The Observer role on file spaces, folders, and files is list-only. Seeing an item does not grant opening, downloading, commenting, or changing access. Changing sharing requires share permission on the actual record; being able to update a record is not sufficient. If a file is visible but cannot be opened, ask its owner to review the intended role instead of making the space public. Library uploads go directly to storage, including files of 64 MiB and above that previously failed through the server. The per-file limit is 5,000,000,000 bytes. Wait for upload completion and verify the file opens before deleting your local copy. If an upload fails, check connectivity and applicable limits before retrying.

Work with smart document pages

Open a smart document from Library to edit collaboratively. Use the page tree to open subpages, create a subpage with the slash menu, and drag pages to reorder or nest them where you have permission. Subpages belong to their parent page rather than appearing as separate root files. Breadcrumbs help you return to the parent. Type [[ to find and link an accessible page. The slash menu also offers a table of contents. Add an icon, cover, or full-width layout when it helps readers. Backlinks show accessible pages that link here. Rich editors can also mention records and preview supported pasted record links; a mention or link never grants access to its target. Opening a document and editing it are separate permissions. A read-only collaborator can read permitted content but cannot change it; creating a subpage also checks create access at the file destination. If a link or child is missing, check access and whether the page was moved or recycled. Do not recreate a restricted page in a wider space. After editing, reopen the page and check its content and links before sharing its existing authorized link.

Goal

Choose the right Library space, create a clear evidence path, use only the file actions your scope allows, and understand the difference between moving a file to the recycle bin and permanently deleting it.

Choose the right space before upload

Library supports personal and shared spaces. A personal space is appropriate for a member’s working material that does not need a team-maintained location. A shared space is appropriate for material the approved team must locate, review, and manage together. Do not use a personal space to hide evidence that the service team must retain or review. Do not place unrelated citizens’ records in a broad shared folder simply because it is convenient. Follow the organization’s retention, classification, and file-naming rules in addition to the KayanOS access model.

Build a controlled evidence path

For the Citizen Services Directorate scenario, use a predictable structure that matches the service model:
  1. Open Library and select the approved shared service space.
  2. Create a folder only when the organization’s structure calls for it. Use a meaningful name, such as Citizen Service Requests / 2026 / CSR-2026-00042.
  3. Upload the approved evidence or move it from an authorized location. Confirm the file name, type, content, and relationship to the request before completing the upload.
  4. Open or preview the uploaded file to confirm it is the intended version and readable.
  5. Link or reference the evidence from the request or inspection record through the approved field/workflow. The record should tell reviewers why the file matters; the file name alone is not a service decision.
  6. Assign or verify the appropriate shared-space access. Do not use a copied link as a way to bypass a scope that should limit viewing.
  7. When a file is superseded, follow the retention policy and use a clear replacement/move process. Do not assume that every file has version-history, public-link, or universal online-editing behavior.
Expected result: the authorized team can find the correct evidence from the relevant request, while members outside the approved space do not gain access through convenience copies.

File and folder actions

Depending on the selected item and your permissions, Library can provide actions such as open, preview, download, copy link, share, rename, move, replace, send to recycle bin, restore, or permanently delete. The presence of an item in a folder does not guarantee every action is available. Use these boundaries:
  • Open/preview/download to inspect a file you are allowed to access. Check that the file is the right version before relying on it in a decision.
  • Rename/move/replace to maintain the approved organization. Preserve a meaningful relationship to the request and do not move evidence into a broader space merely to make it easier to find.
  • Share/copy link only when the recipient already has a legitimate need and the organization’s sharing rule permits the action. A link should not substitute for a scoped access decision.
  • Edit only when the file type and your files:update scope support editing. Do not promise that every file can be edited in place.
  • Recycle when the item may need to be restored or is awaiting the organization’s retention decision.
  • Permanently delete/purge only when deletion is authorized and irreversible removal is intended. Treat this as a distinct, higher-risk action.

Recycle bin versus permanent deletion

Sending an item to the recycle bin is a non-destructive step: it removes the item from the active location but allows a permitted recovery workflow. Restoring returns the item to active use according to the product’s available restore behavior. Purging or permanently deleting is destructive and should be used only after the organization confirms that retention, legal hold, service audit, and access implications are satisfied. Before permanent deletion, ask:
  1. Is the file evidence for an open request, inspection, decision, or complaint?
  2. Does the organization require a retention period, review, or legal hold?
  3. Is there an approved replacement linked from the record?
  4. Does the person performing the action have the scoped permanent-delete authority?
  5. Would moving to the recycle bin meet the immediate need more safely?

Availability and permissions

Library operations are scope-aware. A member may be able to see a shared space but not upload to it, open a file but not share it, move a file but not permanently delete it, or edit a supported document only when files:update applies in the relevant scope. Check the requested action at the file/folder and service-record levels rather than granting broad access because a team needs one document. A new upload is authorized against its destination: files:create must intersect the selected folder’s scope, or the selected space’s scope when uploading at its root. The pending upload can be completed only by the member who created it. Existing-file actions use the file’s own scope instead: opening/previewing requires the applicable files:open access, while replacement or editing requires files:update. Seeing a folder or opening another file there is therefore not proof that a member may upload to that destination. If a file action is missing, verify:
  1. the current organization and selected personal/shared space;
  2. access to the file/folder itself and its parent location;
  3. files:create on the upload destination, or the required file verb for open, update, share, recycle, restore, or permanent delete;
  4. the member’s assigned scope; and
  5. whether the file type supports the intended action.

Safe testing

Use synthetic material that contains no citizen data. In an approved non-production space, create a folder, upload a harmless file, preview it, rename or move it within the allowed space, and confirm that a member without files:create on that exact destination cannot upload there or complete another member’s pending upload. Also confirm that a non-authorized member cannot open the finished file. Send the file to the recycle bin and restore it. Do not test permanent deletion unless the organization explicitly authorizes the test and the item is disposable.

Troubleshooting

KayanOS Library with controlled material for a representative service team.