> ## 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. # Troubleshoot common Yrka issues > Step-by-step checks for common admin and employee issues in Yrka, including degraded states, blocked workflows, and when and how to escalate to support. Most blocked workflows in Yrka follow a pattern: the record moved to a different status, an upstream review step is incomplete, or a permission or configuration setting does not match what the action requires. Working through the checks below before escalating will resolve most issues and help you collect the right context if you do need support. ## Before you start Collect the route or tab you were on, the organization name, the affected employee or record (using a name or ID, not sensitive data), the visible status label, the time it happened, and what you expected to happen. If the app showed a safe error code, batch ID, sync ID, or audit ID — collect that too. ## General first steps If your account has access to more than one organization, verify the correct one is selected. The current organization name is visible in the admin header. Many admin surfaces and action controls check permission at the route and button level. If an action is missing, a tab is hidden, or a button is grayed out, your role may not include the matching permission. See [Roles and permissions in Yrka](/security/roles-permissions) for the permission matrix. Records in review-first workflows (imports, payroll export, provider sync, schedule intake, resource sources) move through multiple statuses. Refresh the specific surface and check whether the record moved to another tab, filter, or queue — it may not be missing, just in a different state. Before retrying, confirm that the current status actually calls for a retry. Statuses like `needs review`, `staged`, or `pending commit` mean a different action is needed, not a retry. ## Issue-by-issue checks **Check first:** Confirm the pay period, lock state, organization attendance defaults, any job or site overrides, location policy, and whether the employee used kiosk, offline sync, or self-service. **Common causes:** * The pay period is locked, which prevents editing time entries directly — use a correction request instead. * The attendance status badge reflects an exception that needs review, not a blocking error. * Location status shows `denied`, `unavailable`, or `low accuracy` because the device or browser cannot meet the location policy requirement. **What to collect if escalating:** Employee name, entry date, matched shift if visible, attendance or review status, location status, safe error code, and whether the entry came from kiosk, offline sync, or self-service. **Check first:** Confirm the import lane, file type, field mapping, required fields, duplicate warnings, and commit status. Imports stage records for review — a warning does not always mean failure. **Common causes:** * Required fields are missing or mapped to the wrong column. * Duplicate detection flagged rows that match existing records; review each flagged row before committing. * The import is in a `staged` or `review required` state, not yet committed. Committing is a separate deliberate step. **What to collect if escalating:** Batch ID or import name, lane, current status, validation message text, and the target workflow (employees, timecards, schedules, etc.). **Check first:** Confirm provider readiness, connection status, sync history, and whether the connection is in a `setup required` or `degraded` state. **Common causes:** * The provider connection needs reauthorization — look for a `reconnect` or `setup required` prompt in Integrations. * The sync history shows a `failed` or `skipped` status with a safe error message that identifies the cause. * The provider is experiencing its own outage, which Yrka cannot resolve on its end. **What to collect if escalating:** Provider name, connection or sync row label, safe error message, last activity time, and the action you were trying to complete. **Check first:** Confirm the pay period is in the correct review state, employee and pay-code mappings are complete, the vendor profile is configured, and there are no unresolved warnings. **Common causes:** * Timecards have exceptions that need review before the period can be marked ready for export. * An employee is missing a pay-code mapping required by the export profile. * The export path is file handoff (generates a file for you to upload to your provider) rather than a direct provider push — confirm which your configuration uses. **What to collect if escalating:** Pay period, export pack or profile name, warning text, and whether your provider path is file handoff or provider-gated. Payroll export readiness in Yrka means a handoff file is prepared for your review. It does not mean payroll has been processed, submitted to a provider, or accepted by your payroll system. **Check first:** Confirm the admin's role label, the actual permission configuration for that role, and whether the action requires a permission the role does not include. **Common causes:** * The role label (for example, "Manager") does not match the underlying permission set in your organization's configuration. Review the actual permissions, not just the label. * The user is looking at the right surface but the specific action requires an additional permission they do not have. * Employee app access and admin role permissions are separate — an admin role does not automatically grant employee self-service access. **What to collect if escalating:** User email, role label, the action they expected to complete, their current organization, and the visible blocked state. **Check first:** Confirm billing and account state, check for pending access requests, review invitation status, and confirm the sign-in route (email/password vs. external identity). **Common causes:** * The invitation email was not received — a manual invite link may be available as a fallback without requiring a provider connection. * An external identity flow created a pending access request that still needs admin review before the person can sign in. * The account is in a billing state (past due, suspended, or downgraded) that restricts new sign-ins or access grants. **What to collect if escalating:** User email, organization, auth route (direct vs. external identity), invitation status label, and safe error text. **Check first:** Confirm the selected surface, the question asked, and whether the Zavi answer says context is missing or cites an article that covers the topic. **Common causes:** * Zavi's answer is limited to the Manual and permission-scoped context for the current surface. If context for a specific workflow is not in the Manual, Zavi will say so rather than inventing an answer. * The user is on the employee surface, which has narrower Manual context than the admin surface. **What to collect if escalating:** The question text, the cited article title and path, the surface (admin or employee), and whether the answer says context is missing. ## Before you start Stay in the same browser session or installed PWA if a queued item exists — switching sessions or clearing site data may affect what is visible. Collect the tab you were on, the action you tried, the visible status or error text, and whether you were online, offline, or recently reconnected. ## General first steps If your account has access to more than one organization, verify the correct one is selected before checking any records. Reopen the specific tab where the work belongs: Today, Time, Schedule, Messages, Resources, Tasks, Profile, or Clock Kiosk. Some records only appear in their owning tab and will not be visible from other areas. Many employee-initiated actions — schedule requests, coverage requests, profile changes, correction requests — move into a `pending review` state and wait for a manager or admin to act. A pending item is not a blocked item; it is waiting for someone else's step. If an offline or sync banner is visible, reconnect to a stable network and look for a Retry option on the queued item. Do not sign out while a queued item is pending — signing out may remove read caches. ## Issue-by-issue checks **Check first:** Confirm the entry mode (self-service vs. kiosk), job selection, break or drive-time fields, pay-period lock state, queue state, and whether a location prompt appeared. **Common causes:** * The time entry cannot be edited because the pay period is locked. Submit a correction request instead. * A location prompt appeared and was denied or unavailable — if your organization requires location for time entries, you may not be able to complete the entry without it. * The entry went into the offline queue. It will sync automatically when you reconnect; look for it in the queue status surface. **What to send your manager or admin:** Date, action attempted, job selected, visible error or status, and whether location was denied, unavailable, low accuracy, or not required. **Check first:** Confirm your network connection, the queue status, whether Retry or Cancel is available on the item, and whether the item says `needs review`. **Common causes:** * The item is `queued` and waiting for a stable connection to sync automatically. * The item shows `failed` and offers a Retry button — tap or click Retry once you are back online. * The item shows `needs review`, which means the server accepted it for manager or admin review. Open the owning workflow to confirm. * The item shows an account-state or entitlement block — contact your admin; do not delete the item. **What to send your manager or admin:** Queue item type, current status, last retry time, safe error text if shown, and your device or app context. **Check first:** Confirm the selected date, the shift status, the marketplace or open-shift status, the request status, and whether manager approval is still pending. **Common causes:** * The shift is in `pending approval` state — a manager needs to approve the coverage or swap request before it takes effect. * The open-shift was already claimed by someone else. * The marketplace feature may not be enabled for your organization. **What to send your manager or admin:** Shift date, request type, visible status, and whether the shift shows open, pending approval, offered, approved, denied, or canceled. **Check first:** Confirm whether you are looking in Inbox vs. Board, check the thread and acknowledgement state, and check whether a reply is allowed for that message type. **Common causes:** * An acknowledgement is required and has not been submitted yet — the message will remain in your queue until you acknowledge it. * The message went through an offline queue and may show as `queued` until it syncs. * The notification appeared in the in-app bell but not in an external channel (email, Slack, SMS) — check your notification preferences or ask your admin. **What to send your manager or admin:** Message or board title, visible status, what you tried to do, and whether the in-app notification bell showed the message. **Check first:** Confirm the resource is published and assigned to your audience or team, the due date status, and whether a result or completion state is already recorded. **Common causes:** * The resource is not published or not assigned to you — ask your admin to confirm the audience configuration. * A training module shows as already completed; you may not be able to retake it unless your admin resets the assignment. * The resource uses a source that is still being indexed — check back after a short time. **What to send your manager or admin:** Resource or training title, visible status, and whether you can see the item in search results. **Check first:** Confirm which section you are trying to access, whether that section requires admin review of a change request, and whether the document is marked confidential. **Common causes:** * A profile change request (address, contact info, availability) is waiting for admin review, not blocked. * A document is marked confidential and is not visible to employees, even in their own record. * A section is not visible because employee app access for that section is not enabled by your organization. **What to send your manager or admin:** Section name, request type, visible status, document title if applicable, and safe error text. **Check first:** Confirm the kiosk is authenticated, your clock code is current, your location policy allows kiosk use, and the action is not locked. **Common causes:** * The kiosk session expired — it needs to be re-authenticated by an admin before employees can use it. * The clock code shown in the app is not matching what the kiosk accepts — check whether the code has refreshed. * The kiosk has a location policy that your current location does not satisfy. **What to send your manager or admin:** The kiosk route, what happened when you entered the code, the action you tried, and the visible error. ## Degraded states When part of Yrka — or a connected provider — is temporarily unavailable, you will see a degraded or impacted status indicator. Here is what to expect in each area: | Affected area | What still works | What may not work | | ---------------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------- | | App data | Existing local read context remains visible | New writes may fail until service recovers | | Storage | Existing records are visible | Uploads and private file links may be temporarily unavailable | | Billing | Existing workspace access is unchanged | Plan changes, portal actions, and payment recovery may need to wait | | Zavi / AI | Resources and search still work | Zavi answers and recaps may be unavailable | | Queue / sync / notifications | In-app notifications and owning workflow records are the source of truth | Delivery may be delayed until retry or review completes | | Provider | Manual workflow or reviewed file handoff is available | Live provider automation may not be available | A provider-gated feature may remain visible in the app for planning purposes even when live activation is unavailable. Visibility does not mean the live provider connection is active. ## How to escalate to support If the issue is still unresolved after working through the checks above, contact support through the channel configured for your plan. **What to include in your support request:** * Organization name and your name or email * Your role (owner, admin, manager, employee) * The affected workflow and route or tab * The visible status label, safe error text, and any record IDs or audit IDs shown in the UI * Whether the issue is a question, a blocked workflow, a billing issue, or a production-impacting problem * For provider issues: the provider name and the connection or sync status shown in the app Do not include provider tokens, OAuth codes, raw import or payroll files, private employee documents, message bodies, precise location coordinates, or screenshots that reveal other employees' private data in support notes.