Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.yrka.io/llms.txt

Use this file to discover all available pages before exploring further.

Yrka is designed primarily as an online application, but the employee app supports a limited offline mode so that time-sensitive employee actions — like clocking in or submitting a time entry — are not lost if your connection drops. When you take an offline-supported action, Yrka stores it locally in a queue and syncs it automatically when your device reconnects. Admin surfaces, search, and most reads require a live connection and are not available offline.

​
What works offline

The following employee-initiated actions are supported in the offline queue. When you take one of these actions while offline, it is saved locally and synced when you reconnect:
  • Time entries and clock actions — clock-in, clock-out, and manual time entry drafts
  • Resource acknowledgements — marking a resource or announcement as acknowledged
  • Profile change requests — submitting a profile update for admin review
  • Schedule availability — updating your availability preferences
  • Coverage requests and time-off requests — submitting a coverage or time-off request
  • Explicit message sends — sending a message that was deliberately submitted (not unsaved drafts)
Queuing an action offline does not guarantee it will be accepted by the server. The server still validates the action when it syncs — for example, a time entry that conflicts with a locked pay period will fail on sync even if it was queued offline.

​
What requires a live connection

The following actions and features require an active internet connection and are not available in offline mode:
  • All admin surfaces — Dashboard, Timekeeping, Personnel, Reports, Settings, Integrations, Payroll, Imports, and Admin Tools
  • Search — all search functions require a live connection to query the server
  • Reads of new data — loading records, profiles, schedules, or messages that are not already cached
  • Attachments and private document uploads — file uploads and downloads require a live connection
  • Payroll exports — generating export files is online-only
  • Provider connections and sync — all integration and provider sync actions require a live connection
  • Zavi / AI answers and recaps — AI features require a live connection
  • Admin approvals — approving or rejecting requests, timecards, and work items is online-only
  • Training attempts — completing or recording training results requires a live connection
  • Unsaved message drafts — text you have typed but not explicitly sent is not queued

​
The offline queue

When you take a supported action while offline, it enters the offline queue. The queue holds the action locally until your device reconnects and Yrka can send it to the server.

​
Viewing queue status

When items are in the queue, a banner or status indicator appears in the employee app. You can open the queue surface from this indicator to see:
  • The type of each queued action
  • Its current status (queued, syncing, synced, failed, needs review, canceled)
  • The last attempted sync time
  • Whether Retry or Cancel is available

​
Connection banner

When Yrka detects that your device is offline or has a degraded connection, a connection banner appears at the top of the employee app. The banner clears when your connection is restored and the queue resumes syncing automatically. You do not need to take any action for automatic sync — just wait for the connection to stabilize.

​
What happens when you reconnect

When your device reconnects, Yrka begins syncing queued items automatically. Each item moves through the following statuses:
StatusWhat it means
queuedThe action is saved locally and waiting for a connection
pendingThe action is local or waiting on an explicit next step
syncing or processingThe action has started sending to the server — do not cancel
syncedThe server accepted the action; the owning workflow may still require review
needs reviewA manager or admin now owns the next decision in the owning workflow
failedThe action did not complete; Retry may be available
canceledThe action was stopped before completion
entitlement blockedYour account state paused new writes; do not delete the item — resolve the account state first
A synced status means the server accepted the action. It does not mean the action is final. Time entries may still need manager review. Requests may still need approval. Always check the owning workflow to confirm the final state.

​
Retrying, canceling, and escalating queued actions

​
Retrying a failed item

If an item shows failed, look for a Retry button. Tap or click it once you are on a stable connection. Do not retry repeatedly in a short window — if the same safe error repeats after two or three attempts, escalate rather than continuing to retry.

​
Canceling a queued item

You can cancel a queued item only when:
  • It was submitted by mistake, and
  • It has not yet started syncing (the status is queued or pending, not syncing or processing)
Canceling a local item does not cancel a server-side record that has already synced. If an item shows synced, the action reached the server — to reverse it, you need to take the appropriate correction action in the owning workflow (for example, a correction request for a time entry).

​
When account state is blocking sync

If an item shows entitlement blocked, suspended, canceled, or past due, your organization’s account state is preventing new writes. Do not delete the queued item — it preserves the evidence of the action you took. Ask your admin or owner to resolve the account state. Once account access is restored, the item can be retried.

​
When to escalate

Escalate to your manager, admin, or support when:
  • The same safe error repeats after retrying
  • The Retry button disappears without the item completing
  • The item shows synced but cannot be found from the owning workflow
  • You see duplicate-looking records after reconnecting (compare timestamps and action type before deleting anything)
What to include when escalating:
  • The queue item type and status
  • The last attempt time
  • The safe error code if shown
  • Your device type and app context (browser, PWA, or desktop companion)

​
Signing out while items are queued

Signing out clears read caches (recently loaded records, search results, and cached profile data) but preserved queued write items. If you explicitly confirm local data deletion during sign-out, queued items will be removed. Avoid signing out or switching accounts while a queued item is pending unless you are certain the action no longer needs to sync.
If you are using a shared device or kiosk, confirm with your manager before signing out when a queue item is pending.