Skip to main content
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.
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
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:
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.
Templates triggered by underfilled schedule events. Produce Inbox work items or notifications so managers can respond before a coverage gap affects operations.
Templates triggered by timecard review-needed events. Create follow-up tasks or notifications for timecard exceptions that need admin attention.
Templates that monitor for stale active Inbox items or overdue tasks and generate reminders or escalation follow-ups when they are not addressed.
Templates triggered by overdue acknowledgement or training events. Create task follow-up for employees who have not completed required content by the due date.
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.
Templates triggered by payroll import warnings or readiness events. Create review-first follow-up to keep payroll prep on track.
Templates for billing state changes or capacity-related events that require owner attention.

​
Building a workflow

1

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

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

Create from the template

Select Create from template. The workflow opens in the builder with the template’s default configuration pre-filled.
4

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

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

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

​
Workflow status meanings

​
Monitoring run history

1

Open Run History

Select the Run History tab. Filter by search term, status, or workflow to find specific run records.
2

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

Use source links

Follow owning-surface links from run records to open the task, Inbox item, notification, or sync retry that the workflow produced.

​
Retrying failed runs

1

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

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

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

Retry

Select Retry on the eligible run.

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

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