Workflows

Workflows let Dawn react to workspace events without someone manually starting a chat. They connect a trigger, an agent, and one or more ordered instructions so recurring review, triage, and monitoring work can run in the background.

What Workflows Are

A workflow is a saved workspace automation. It listens for one or more events, runs the selected agent with the workflow instructions, records what happened, and gives the team a way to open the result when the run is done.

Use workflows when the trigger is external or recurring: a pull request opens, a pull request is updated, a work item changes, or another supported event arrives from a connected source. Use normal chat or a Prompt Command when a person is explicitly asking for work in the moment.

What You Can Automate Today

The current workflow surface is focused on connected-source events.

Supported provider event families include:

• GitHub: pull request events (created, updated, commented, review thread updated), issue events (created, updated, commented), and GitHub Actions workflow run and workflow job events.
• Azure DevOps: pull request events (created, updated, commented), work item events (created, updated, commented), build completed events, and Azure Pipelines run and job state changes.
• Dawn system events: the workflow engine has a system event foundation for scheduled triggers, but existing scheduled tasks remain the user-facing scheduling feature today.

Pull request review is the most common starting point: trigger a workflow on the pull request created and updated events for a GitHub or Azure DevOps source, point it at an agent that has access to that source, and write a review prompt as the workflow step. The same pattern works for issue triage, work item triage, and CI inspection — only the trigger events and the prompt change.

Required Setup

Before creating an integration workflow, confirm these pieces exist:

1. The integration connection is working.
2. The relevant source is linked and enabled, such as a GitHub repository or Azure DevOps repository.
3. The agent that will run the workflow is assigned to that source.
4. The provider event is supported by Dawn.
5. The workflow is enabled after it is saved.

Source assignment matters. A workflow does not bypass agent permissions. If the selected agent cannot read the repository, pull request, issue, or work item source, the workflow run will not have that context either.

Create A Workflow

1. Open Dawn Web.
2. Go to Workflows.
3. Create a new workflow.
4. Pick the agent and the connected source the workflow should listen to.
5. Choose the supported event types from that source that should trigger it.
6. Write the workflow step instructions.
7. Pick a concurrency policy.
8. Decide whether the workflow should be enabled immediately, then create it.

A workflow definition contains:

• Name and description: the readable identity shown in the workflow browser.
• Workflow agent: the agent profile that runs the workflow steps.
• Workflow source: the connected source whose events can trigger the workflow.
• Events: the provider events that should start the workflow.
• Steps: ordered agent-run instructions.
• Enabled state: whether the workflow is active.
• Concurrency policy: how Dawn handles repeat events while a previous run is still active.

If you are creating workflows through an agent or API client, use the Workflow Authoring Reference. It includes exact request fields, event IDs, node settings, validation behavior, and run statuses.

V1 workflow steps are agent runs. The step prompt should be written like durable operational guidance: what to inspect, what risks to prioritize, what output format to use, and when to say there are no findings.

Recipes

Recipes are starting points for common automations. They pre-fill the source type, events, agent step, and prompt shape so you do not have to build a workflow from a blank canvas.

Use recipes when:

• the work follows a known pattern, such as pull request review or issue triage;
• the connected integration exposes the right event family;
• you want Dawn to suggest a sensible default prompt and event set;
• you still want to review and customize the workflow before enabling it.

Some recipes are integration-specific. For example, a pull request review recipe only appears when a compatible code source is connected. Generic recipes can be used with Dawn system events when the trigger is not tied to one provider.

Visual Canvas

The workflow canvas is the editable map of the workflow. It shows the trigger, steps, branches, and ordering rules in one place so the definition is easier to inspect than a long form.

Use the canvas to:

• add and arrange workflow steps;
• see which steps run first;
• connect steps into a sequence;
• add condition pass/fail branches when later work depends on earlier output;
• add loops for repeated work over a bounded set of items;
• auto-arrange the graph when the layout becomes hard to read;
• validate the definition before saving or enabling it.

Validation checks the shape of the workflow before you rely on it. It can catch missing names, missing agents, unsupported trigger/source combinations, disconnected nodes, incomplete branch configuration, and step prompts that are not ready to run.

Agent-Run Steps

An agent-run step sends a prompt to the selected Dawn agent. The prompt can be plain instructions or can include a Prompt Command invocation such as /pr-review when the workflow should use the same command a person would run manually.

Command-backed steps still follow normal Dawn permission rules:

• the selected agent controls available sources, skills, memory, and tools;
• the command expands into its stored instructions at runtime;
• the event context gives the agent the pull request, issue, work item, or other subject that triggered the workflow;
• the workflow records the step output for run history and delivery.

Use Prompt Commands for repeated step patterns. Use plain prompts when the workflow behavior is specific to this one automation.

Concurrency Options

Workflow events can arrive in bursts. Dawn gives each workflow a concurrency policy so repeated events do not create confusing duplicate work.

• Queue: keep every matching event and process them in order.
• Skip if running: ignore a new event while a previous run is still active.
• Debounce by subject: combine rapid updates for the same subject, such as repeated commits on the same pull request, and run after the debounce window.

For PR review, debounce by subject is usually the right default so a fast sequence of commits on the same PR does not create several nearly identical reviews.

For queue-based workflows, you can also set a queue dedupe window. During that window, Dawn treats duplicate queued events for the same workflow subject as the same pending work instead of adding another run. Use this when every event should eventually be processed, but repeated delivery of the same event should not create duplicate queued runs.

Run History And Results

The workflow screen has two views: configured workflows and run history.

Run history shows the workflow, source event, subject, status, timing, and output. Open a run to inspect the workflow state, step output, validation context, and any failure details.

When a workflow finishes with output, use Start discussion to bring that output into a Dawn thread. This keeps automated work visible without forcing every workflow result into a conversation automatically.

Workspace notifications are the default delivery surface for workflow results. Additional delivery targets can be added later without changing the core workflow definition model.

Good Workflow Prompts

Write workflow steps like repeatable team process, not one-off chat prompts.

Good workflow instructions usually include:

• the event subject Dawn should inspect first;
• the connected-source details to check;
• the review or triage priorities;
• how to order findings;
• when to say there are no findings;
• what residual risks or testing gaps to call out.

For example, a PR review workflow should tell Dawn to inspect the PR details, changed files, comments, linked issues or work items, and CI state when available, then return findings first and include file references where possible.

Troubleshooting

• You cannot pick a source or event: connect and enable a supported GitHub or Azure DevOps source, then assign that source to the agent you want to use.
• The workflow does not run: confirm the workflow is enabled and the selected event type matches the provider event being sent.
• The run has no useful context: check that the workflow agent is assigned to the source and that the source still has valid credentials.
• Too many runs are created: switch to debounce by subject or increase the debounce window.
• Queued runs repeat the same subject: use a queue dedupe window so duplicate queued events collapse before they run.
• Results are not in a chat thread: open the completed run and choose Start discussion. Workflow output is not injected into arbitrary threads automatically.
• You need a scheduled digest: use Scheduled Tasks for now. Scheduled tasks and workflows are separate user-facing surfaces today.

List workflow-ready sources in this workspace and suggest useful workflow recipes.

Review recent workflow runs and summarize failures, duplicate events, or noisy triggers.

Validate this workflow canvas and explain any disconnected steps, missing branches, or unsafe loops.