> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oasm.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Workflows

> Automate recurring security operations with versioned workflow definitions in OASM

Workflows automate recurring security operations — discovery, scanning, and reporting — by turning an operating procedure into a repeatable definition. A workflow orchestrates a sequence of steps; when it runs, OASM starts scan tasks that connected workers carry out, and the resulting runs are tracked in the [Job Registry](/jobs).

Workflows are built for automation. They are defined as configuration files — usually by your technical team — rather than through a visual builder, and you control when they run: manually, on a schedule, or when another workflow finishes.

## Key concepts

<Table>
  | Concept     | Description                                                                                        |
  | ----------- | -------------------------------------------------------------------------------------------------- |
  | Workflow    | A repeatable, versioned definition of a security operation — the steps to run and when to run them |
  | Template    | A ready-made automation recipe you can start from and customize                                    |
  | Trigger     | What starts a run: a manual run, a schedule, or another workflow finishing                         |
  | Run         | A single execution of a workflow; it starts the scan tasks that workers carry out                  |
  | Job         | One scan task executed by a connected worker — see [Job Registry](/jobs)                           |
  | Asset group | Workspace-scoped set of assets that defines what a workflow run covers — see [Groups](/group)      |
</Table>

<Info>
  Workflows belong to an asset group: an asset group holds the workflows that operate on its assets. Running a workflow targets the assets of the group it belongs to.
</Info>

## Workflow definitions

A workflow definition declares what triggers it and which steps it runs. Triggering is either manual (you start the run) or scheduled (a schedule starts it for you), and each step is a scan task that a connected worker carries out.

You can schedule a workflow to run on a fixed rhythm:

<Table>
  | Schedule      | Meaning               |
  | ------------- | --------------------- |
  | Daily         | Runs once per day     |
  | Every 3 days  | Runs every three days |
  | Weekly        | Runs once per week    |
  | Every 14 days | Runs every two weeks  |
  | Monthly       | Runs once per month   |
</Table>

Scheduled runs are the foundation for fully automated security programs: set them up once and the platform keeps scanning on its own.

## Workflow templates

Templates are ready-made automation recipes that ship with the platform. They give you a verified starting point instead of building a workflow from scratch.

| Template                 | Purpose                                                 |
| ------------------------ | ------------------------------------------------------- |
| Domain discovery         | Discovers the subdomains of your targets                |
| IP address discovery     | Discovers the IP addresses associated with your targets |
| Basic vulnerability scan | Runs a baseline vulnerability scan against your assets  |

## Create a workflow

Workflows are usually defined by your technical team as configuration files, starting from a ready-made template when one matches your operation.

<Steps>
  <Step title="Start from a template">
    Pick the template that matches the operation you want to automate.
  </Step>

  <Step title="Customize the definition">
    Adjust the steps, the schedule, and the assets the workflow should cover.
  </Step>

  <Step title="Verify the workflow is listed">
    Confirm the workflow appears in your workspace with the name you expect.
  </Step>
</Steps>

<Info>
  Everything available in the console is also available through the API — see the API Reference tab.
</Info>

## Run a workflow against an asset group

Workflows belong to an asset group, and running one executes its steps against that group's assets.

<Steps>
  <Step title="Identify the workflow">
    Open the asset group and find the workflow you want to run.
  </Step>

  <Step title="Trigger the run">
    Start the workflow now — either on demand or through its schedule.
  </Step>

  <Step title="Track the run">
    Watch the scan tasks it started in the [Job Registry](/jobs) — the run produces one or more jobs that connected workers carry out.
  </Step>
</Steps>

## Triggers and chaining

Beyond schedules, a workflow can be started when another workflow finishes, which lets you chain operations into an automated pipeline.

<Accordion title="How does chaining work in practice?">
  A discovery workflow can be followed by a scan workflow: the scan workflow starts automatically once discovery finishes — without a human in the loop. Combined with scheduled runs, this builds a self-driving pipeline: schedule discovery, chain scanning on its completion, and review results in the Job Registry.
</Accordion>

## Best practices

* **Start from templates.** Use the built-in recipes as a basis, then customize instead of building workflows from scratch.
* **Scope runs to asset groups.** Keep workflows attached to the smallest group that covers the assets you care about — targeting groups instead of the whole workspace reduces noise and scanning cost. See [Groups](/group).
* **Combine schedules with chaining.** Let scheduled discovery feed chained scans so the pipeline runs without manual intervention.
* **Review changes before updating production workflows.** Treat workflow definitions with the same care as any other production configuration.
* **Monitor runs in the Job Registry.** After triggering a run, verify its scan tasks finish and re-run or cancel them as needed — see [Job Registry](/jobs).
* **Connect enough workers.** Scan tasks only progress when a connected worker picks them up. Check [Worker](/worker) for how to scale the execution layer.

## Related

<Card icon="users" title="Groups" horizontal href="/group">
  Organize assets into groups that define the scope of workflow runs
</Card>

<Card icon="list-checks" title="Job Registry" horizontal href="/jobs">
  Track the scan tasks that workflow runs start and re-run or cancel them
</Card>

<Card icon="cpu" title="Worker" horizontal href="/worker">
  Connect the execution layer that picks up and processes workflow tasks
</Card>

<Card icon="layout-dashboard" title="Dashboard" horizontal href="/dashboard">
  See the effect of discovery and scanning workflows on your attack surface
</Card>