> ## Documentation Index
> Fetch the complete documentation index at: https://docs.insight.nobly.dk/llms.txt
> Use this file to discover all available pages before exploring further.
# Schedules and batch workflows
> Schedule system workflows, start a child workflow per selected item, and monitor starts, completion, and failures.
## Prerequisites
The workflow feature must be available. You need `workflow-engine.manage` to author definitions, pause or resume schedules, and run them manually. `workflow-engine.view` allows inspection of schedules and run history; `workflow-engine.admin` includes these capabilities.
## Create a scheduled system workflow
In **Admin settings → Workflow → Workflow Designer**, choose the **System** anchor. It represents work without one document or Caseflow object as its anchor, such as a daily scan that starts a process for each matching document.
Add a schedule on the definition's **Triggers** tab. Choose a preset or use **Advanced** to enter a five-field cron expression, then choose the time zone. The fields are minute, hour, day of month, month, and day of week. The time zone is part of the schedule, not just a display preference.
Validate, save, and publish the definition. A schedule is created from the published definition. Document and Caseflow workflows use their event triggers; scheduled triggers belong to System workflows.
## Operate the schedule
Open **Admin settings → Workflow → Workflow Schedules** to inspect the published version, schedule, time zone, enabled state, next run, and last run. Expand run history to inspect an occurrence and open its root instance when one was created.
* **Pause** stops future automatic firings. It does not cancel an instance already running.
* **Resume** calculates the next future occurrence; it does not replay every occurrence during the pause.
* **Run now** requests an immediate manual occurrence, including for a paused schedule. It still applies the overlap rules and can perform real business operations.
If a prior root instance of the definition is still running, another occurrence is skipped. After an interruption, missed occurrences are coalesced into one run rather than replayed individually. Check the history's reason for a skipped or failed occurrence instead of repeatedly choosing Run now.
A completed schedule occurrence means its start operation completed. Inspect the root and child instances to determine whether the business process has finished.
## Start a workflow for each item
Use **Workflow\.StartForEach** to create a child instance for each selected document or Caseflow object. Configure:
| Setting | Decision |
| ----------------- | ----------------------------------------------------------------------------------------------------- |
| Selector | A small explicit item list, a paged search, or a `workflow_selector` script |
| Child definition | The published workflow each selected item should run |
| Version | Pin a published child version, or omit it to resolve the latest published version when the job starts |
| Anchor mapping | The document/object ID from each item; explicit mappings can override the defaults |
| Initial variables | Values from the parent and the selected item that each child needs |
| Duplicate policy | Skip an item already running that child workflow, or record it as failed |
| Result variable | The variable receiving the batch job information, used by a waiting transition |
A search selector can use a saved system document search, an inline document search, or a Caseflow application/class search. Start with a small, known set and verify the selected records and service-account access before expanding it.
The engine supports `workflow_selector` scripts, but the current client's Scripts type selector does not expose authoring that type. Use the explicit-list or search selector when configuring through the existing UI, or arrange supported script provisioning.
## Wait deliberately with a Join transition
A **Join** transition waits for the job created by StartForEach. Point it at the variable holding that job and select the waiting condition:
* **Started**: selection and start attempts are finished. Child workflows may still be running.
* **Completed**: wait until the children are no longer running as well.
Completion of the wait is not proof every item succeeded. Review skipped items, failed starts, and failed children before treating the batch as successful. Design the next step to handle those outcomes.
## Investigate a batch
The parent instance's batch details show enqueued, started, skipped, and failed counts, child states, the latest error, and join progress. Open a child instance to diagnose its own actions and history.
If the parent is waiting, first determine whether item selection is still paging, starts are pending, or children are still running. If processing partially succeeded, avoid rerunning the entire batch without checking for duplicate side effects. Use the recorded parent, job, and child identifiers when escalating.
## Where to read next
Track workflow instances, read the history timeline, handle failures with error nodes and replay, and manage environment variables and secrets.