Skip to main content

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

Monitoring & administration

Track workflow instances, read the history timeline, handle failures with error nodes and replay, and manage environment variables and secrets.