Overview
Every workflow has a metadata panel that controls execution behavior and communication preferences. This page explains each setting and when to adjust it.Deleting steps and triggers
Steps and triggers include a delete action in their headers so you can remove them without leaving the canvas. Use this when you need to retire a step, replace a trigger, or simplify a workflow draft.Confirmation prompts
Deleting a step, trigger, or connection always shows a confirmation dialog. This prevents accidental removal and gives you a final chance to review the change before it applies.Deleting connections
Connections (edges) can be removed directly from the canvas. This is useful when rerouting workflow logic or cleaning up unused paths.Selected connection styling
When you select a connection, it changes appearance so you can see exactly which path you are editing. The highlight includes the line and arrowhead, making it easy to distinguish the active connection from the rest of the graph.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 acknowledgment, progress updates, and final status.
Reuse Existing Comment
Keeps status updates in a single thread. Overcut edits the most recent reusable comment instead of creating new ones.
Static Comment
Posts one opening acknowledgment and later edits the same comment with the final summary — no incremental progress updates in between.
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 |
| Workflows where mid-run progress is not valuable | Static Comment | Keeps threads tidy while confirming start and completion |
When in doubt, start with Comment Per Execution during testing. Switch to Reuse Existing Comment or Static Comment once the workflow stabilizes and you want to reduce notification traffic.
Provider compatibility
| Provider | Reuse support | Static Comment support |
|---|---|---|
| GitHub | ✅ Full support | ✅ Full support |
| Bitbucket | ✅ Full support | ✅ Full support |
| GitLab | ✅ Full support | ✅ Full support |
| Azure DevOps | ⚠️ PRs supported; tickets fall back to Comment Per Execution | ✅ Full support |
| Jira | ✅ Full support | ✅ Full support |
Reducing notification noise
Some providers (GitHub, Jira, etc.) send an email or in-app notification every time a comment is posted or edited on a PR or issue. In workflows that produce several progress updates per run, this can flood inboxes and Slack channels. Static Comment is the most effective way to limit notifications — the provider only fires two: one when the opening comment is created and one when the final summary edit lands. Reuse Existing Comment also helps because edits typically generate fewer notifications than new comments, but behavior varies by provider. If notification volume is a concern, start with Static Comment for any workflow where you don’t need mid-run visibility.Draft Indicators
When a workflow has unpublished changes, two visual cues help you stay aware:- Workspace header chip — appears beside the workspace name when any workflow has a draft. Shows the count of affected workflows and links to the Unpublished Changes review page. See Workflow Versioning — Finding unpublished changes for details.
- Builder banner — inside Workflow Builder, a banner reminds you that you are editing a draft. It includes Publish and Discard actions so you can commit or revert without leaving the editor.
Related documentation
- Workflow Versioning — draft lifecycle, finding unpublished changes, and publish/discard flow
- Workflow Version History — compare versions side-by-side and restore earlier definitions
- 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