Overview
Every workflow has a metadata panel that controls execution behavior and communication preferences. This page explains each setting and when to adjust it.Accessing workflow metadata
The metadata panel appears on the right side of Workflow Builder when no step is selected. To open it:- Open a workflow in Workflow Builder
- Click anywhere on the canvas background (not on a step or trigger)
- The properties panel displays the workflow metadata form
Use Case Name
The workflow name appears in lists, logs, execution history, and status comments. Choose a descriptive name that helps teammates understand what the workflow does at a glance. Examples:- “PR Code Review”
- “Bug Triage - Backend”
- “Spec Draft for New Features”
Workflow Timeout
The maximum time a workflow can run before Overcut terminates it automatically. This acts as a safety limit to stop execution if something goes wrong. Default: 60 minutes Range: 1 minute or moreHow timeouts work
Each step in a workflow has its own timeout, and the workflow timeout covers the entire execution from start to finish. When setting the workflow timeout:- Estimate total runtime — add up the expected duration of all steps in your workflow
- Add buffer time — include extra time for network delays, retries, and variable workloads
- Set a reasonable limit — the workflow timeout catches runaway executions when individual step timeouts fail to trigger
The workflow timeout is a backstop, not a target. Most workflows should complete well before the timeout. If executions regularly approach the limit, consider breaking the workflow into smaller pieces or optimizing slow steps.
Execution Priority
Controls the order in which queued workflows execute when multiple workflows target the same resource (issue, PR, or repository). Default: 5 Range: 1–100 (lower numbers execute first)Think of priority as “position in line”—priority 1 is first in line, priority 100 is last.
Priority guidelines
| Priority range | Use for |
|---|---|
| 1–10 | Critical security scans, urgent incident response |
| 11–30 | Code reviews, bug fixes, time-sensitive automation |
| 31–50 | Standard workflows, normal automation |
| 51–70 | Documentation updates, metrics collection |
| 71–100 | Background analytics, cleanup tasks |
How priority interacts with queuing
When multiple workflows queue for the same resource:- Workflows are ordered by priority (lowest number first)
- Within the same priority level, workflows execute in FIFO order
- Only one workflow runs per resource at a time
For a deep dive into queuing, locking, and deduplication, see Workflow Execution Control.
Default LLM Model
Override the workspace-level model setting for this specific workflow. When set, all agents in the workflow use this model unless they have their own model override. Default: Inherits from workspace settingsModel selection cascade
Agents inherit their model from this priority order:- Agent model — the agent’s own
modelKeyif configured - Workflow default — the value set here in workflow metadata
- Workspace default — configured in Workspace Settings
- System default — Overcut’s managed default model
For an end-to-end walkthrough, see the Default Model Configuration quick start.
Status Update Method
Controls how Overcut posts progress comments to pull requests and tickets during workflow execution.Options
Comment Per Execution
Creates a new comment for each workflow run. Each execution gets its own acknowledgement, progress updates, and final status.
Reuse Existing Comment
Keeps status updates inside a single comment thread. Overcut edits the most recent reusable comment instead of creating new ones.
Choosing a method
| Workflow pattern | Recommended method | Why |
|---|---|---|
| High-frequency automation (multiple runs per hour) | Reuse Existing Comment | Prevents notification overload |
| Audit trail needed for each run | Comment Per Execution | Each execution has its own linkable comment |
| Low-volume workflows | Comment Per Execution | Discrete updates are clearer |
When in doubt, start with Comment Per Execution during testing. Switch to Reuse Existing Comment once the workflow stabilizes.
Provider compatibility
| Provider | Reuse support |
|---|---|
| GitHub | ✅ Full support |
| Bitbucket | ✅ Full support |
| GitLab | ✅ Full support |
| Azure DevOps | ⚠️ Reuse Existing Comment is not supported. Falls back to Comment Per Execution |
| Jira | ✅ Full support |
Related documentation
- Workflow Execution Control — priority queuing, resource locking, and deduplication
- Triggers — when workflows start
- Scheduled Workflows — time-based automation
- Default Model Configuration — model selection walkthrough
- Workspace Settings — workspace-level defaults
- Integrations — connect to GitHub, GitLab, Jira, and more
- Building Blocks — core workflow components