> ## 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.

# Automate operations with Yrka workflows

> Build template-first automation rules for employee lifecycle, schedule coverage, payroll readiness, and more. Test, enable, pause, and monitor workflow runs.

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.

<Note>
  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.
</Note>

***

## 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

Workflow configuration is saved as an immutable versioned rule. If you edit a workflow's configuration, the edit creates a new version — previous run history stays tied to the rule version that produced it.

***

## Template library

All workflows start from the template gallery. Templates are organized by operating domain:

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="Timecard review">
    Templates triggered by timecard review-needed events. Create follow-up tasks or notifications for timecard exceptions that need admin attention.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="Account lifecycle and capacity review">
    Templates for billing state changes or capacity-related events that require owner attention.
  </Accordion>
</AccordionGroup>

***

## Building a workflow

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Create from the template">
    Select **Create from template**. The workflow opens in the builder with the template's default configuration pre-filled.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Enable the workflow">
    When configuration and test results look correct, enable the workflow. It will begin processing matching live events from that point forward. Draft workflows do not subscribe to live events.
  </Step>
</Steps>

<Tip>
  Dry-run executions use separate idempotency from live executions. Running a test will not create duplicate output if you later enable the same workflow and a matching event occurs.
</Tip>

***

## 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

<Steps>
  <Step title="Open Run History">
    Select the **Run History** tab. Filter by search term, status, or workflow to find specific run records.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Use source links">
    Follow owning-surface links from run records to open the task, Inbox item, notification, or sync retry that the workflow produced.
  </Step>
</Steps>

***

## Retrying failed runs

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Retry">
    Select **Retry** on the eligible run.
  </Step>
</Steps>

***

## 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.

<Warning>
  Re-enabling a restricted auto-approval path after editing a workflow requires explicit re-confirmation from an authorized admin. Editing any workflow configuration resets its safety posture to review-first until re-confirmed.
</Warning>

***

## 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.

<Note>
  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.
</Note>

***

## Troubleshooting

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>