Workflows in Yrka lets you define deterministic, template-first automation that runs in the background as your operations produce events. Instead of manually chasing stale Inbox items, checking for underfilled schedule shifts, or reminding employees about overdue training, you configure a workflow rule once — and Yrka handles the routine follow-up. Workflows are admin-controlled and always grounded in explicit templates: you configure what triggers an action, what conditions must be met, and what output the workflow should produce.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.
Workflows are not autonomous hidden operations. Every workflow rule is visible, versioned, and admin-controlled. High-impact actions remain review-first unless you have explicitly authorized a restricted auto-approval path and provided the required safety evidence.
How workflows work
Each workflow rule is built from four components:- Trigger — the event that starts the workflow (for example, a schedule event is saved underfilled, a task becomes overdue, a sync job fails)
- Conditions — the criteria that must be true for the workflow to run (for example, the underfilled event is more than 2 hours away, the task is assigned to a specific team)
- Actions — what the workflow does when triggered (create an Inbox follow-up, create a task, send an in-app notification, dispatch a notification pipe, queue a provider sync retry)
- Safety tier — whether the action requires admin review before executing, or is eligible for guarded auto-execution
Template library
All workflows start from the template gallery. Templates are organized by operating domain:Employee lifecycle and document follow-up
Employee lifecycle and document follow-up
Templates for onboarding task creation, offboarding checklist generation, document request follow-up, and lifecycle event handling. Document and lifecycle actions create review-first task follow-up until the owning workflow domains mature.
Schedule coverage gaps
Schedule coverage gaps
Templates triggered by underfilled schedule events. Produce Inbox work items or notifications so managers can respond before a coverage gap affects operations.
Timecard review
Timecard review
Templates triggered by timecard review-needed events. Create follow-up tasks or notifications for timecard exceptions that need admin attention.
Stale Inbox and overdue tasks
Stale Inbox and overdue tasks
Templates that monitor for stale active Inbox items or overdue tasks and generate reminders or escalation follow-ups when they are not addressed.
Resource acknowledgements and training follow-up
Resource acknowledgements and training follow-up
Templates triggered by overdue acknowledgement or training events. Create task follow-up for employees who have not completed required content by the due date.
Integration triage and provider connection follow-up
Integration triage and provider connection follow-up
Templates triggered by failed sync jobs or provider connection issues. Create Inbox or task follow-up so integration health problems surface to the right admin.
Payroll readiness and handoff review
Payroll readiness and handoff review
Templates triggered by payroll import warnings or readiness events. Create review-first follow-up to keep payroll prep on track.
Account lifecycle and capacity review
Account lifecycle and capacity review
Templates for billing state changes or capacity-related events that require owner attention.
Building a workflow
Open the template gallery
Go to Admin Tools > Workflows and select the Templates tab. Browse by operating domain or search for a template by keyword.
Review the template summary
Before creating from a template, read the trigger, condition, action, chaining, and safety summary. This tells you exactly what the workflow will do — and what it will not do.
Create from the template
Select Create from template. The workflow opens in the builder with the template’s default configuration pre-filled.
Configure the builder sections
Adjust the Trigger, Conditions, Actions, Chaining, and Safety sections as needed. Each section has explicit controls — there are no hidden fields or implicit behaviors.
Run a dry test
Select Run test or Dry run to preview what the workflow would produce without mutating any domain data. Review the evidence output — the test run shows steps, conditions evaluated, actions that would run, and what records would be affected.
Workflow status meanings
| Status | What it means |
|---|---|
Draft | Saved configuration; not subscribed to live events |
Enabled | Matching events can execute this workflow |
Paused | Live events will not execute this workflow until it is resumed |
Dry run | Preview evidence created without domain mutation |
Failed | Review run history — validation, permission, provider, domain, or adapter issue |
Skipped | Event did not require action or was a duplicate/no-op |
Auto-paused | Workflow safety stopped a failing rule — review run history before re-enabling |
Emergency pause | All restricted workflow actions are held organization-wide until an authorized admin resumes |
Monitoring run history
Open Run History
Select the Run History tab. Filter by search term, status, or workflow to find specific run records.
Review run details
Each run record shows sanitized event context, the steps that executed, conditions that were evaluated, any steps that were skipped, failure detail, retry eligibility, and links to the owning surface record where applicable.
Retrying failed runs
Find the eligible failed run
In Run History, locate the most recent failed run for the workflow. Only the latest failed run is eligible for retry.
Confirm the underlying issue is resolved
Before retrying, confirm the issue that caused the failure — permission change, provider outage, domain record conflict — has been addressed. Retrying without resolving the root cause will likely produce another failure.
Review idempotency evidence
If there is any chance the workflow already produced output before failing, check idempotency evidence in the run record before retrying. Workflows carry idempotency evidence so replays should not create duplicate output, but review it when in doubt.
Pausing and emergency pause
Pausing an individual workflow
Select Pause on an enabled workflow when its output should stop. A paused workflow does not process new events until you resume it. Use this when you need to reconfigure a workflow, investigate unexpected output, or temporarily suspend automation during a sensitive operational period.Emergency pause
The Safety tab includes an organization-wide emergency pause control. When emergency pause is active, all restricted workflow actions across the organization are held until an authorized admin resumes them. Use emergency pause only when you need to stop all automation immediately — for example, during an incident where workflow output could make things worse.Safety posture
Workflows operate under two safety postures:- Review-first (default): The workflow creates a task, Inbox item, or notification that surfaces the situation for a human to act on. No domain records are directly mutated by the workflow.
- Restricted auto-approve / guarded auto-execute: A narrow set of eligible actions can be auto-executed when you have explicitly authorized the path, the saved rule version is confirmed, and the safety evidence passes. This requires additional authorization and is not available by default.
Most workflow actions in Yrka are review-first. Document request, lifecycle, onboarding, schedule coverage, and payroll readiness workflow actions create review-first task follow-up until the owning domains expose more mature direct actions. Do not configure auto-execution for sensitive actions unless you understand what the workflow will produce and have reviewed the safety evidence.
Troubleshooting
The template gallery loads with a warning
The template gallery loads with a warning
If workflow storage is temporarily unavailable, the workspace serves the app-owned template catalog in read-only mode with a warning. You can still review template behavior — wait for storage to return before creating new workflows.
Retry is disabled on a failed run
Retry is disabled on a failed run
The failure may be permission-related, configuration-related, or the workflow may be currently paused. Resolve the underlying issue first, then check whether the retry control becomes available.
Run History is empty for an enabled workflow
Run History is empty for an enabled workflow
Confirm the workflow is enabled (not paused or in draft) and that matching live events have occurred since it was enabled. Workflows only process events that happen after enablement.
A workflow appears to have produced duplicate output
A workflow appears to have produced duplicate output
Check the run history for idempotency evidence on the affected runs. Workflow-generated work items and tasks carry idempotency evidence — if duplicates appeared, compare source evidence across runs before retrying.
An adapter fails with no clear error
An adapter fails with no clear error
Restricted action adapters fail closed when the saved rule version is not in restricted auto-approved safety mode or when permission checks, idempotency scope, or provider readiness fail. Check the run detail for the adapter-level failure reason and review the workflow’s safety tier configuration.