> ## Documentation Index
> Fetch the complete documentation index at: https://docs.overcut.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Workflow Metadata
> Configure workflow settings including name, timeout, priority, default model, and status update behavior.
## Overview
Every workflow has a metadata panel that controls execution behavior and communication preferences. This page explains each setting and when to adjust it.
Workflow self-improvement settings (retrospective cadence and sample size) are configured from the workflow dashboard, not here. See [Workflow Self-Improvement](/docs/how-to/workflows/workflow-self-improvement) for the full guide.
For action-specific setup, use the matching action reference. For example, see [Run Script Action](/docs/workflows/run-script) for **Run Script** fields, environment variables, and output handling.
## 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.
Select the step on the canvas, then use the delete action in the step header.
Select the trigger card, then choose the delete action in the trigger header.
Deletes are only available when the step or trigger is selected, so click the card first if you do not see the action.
## 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.
If you confirm a delete, the change is immediate and saved with the rest of your draft edits.
## Deleting connections
Connections (edges) can be removed directly from the canvas. This is useful when rerouting workflow logic or cleaning up unused paths.
Click the connection line to highlight it.
Use the delete control that appears on the connection and confirm the prompt.
## 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.
## Starting from a playbook
Use **Add from Playbook** when you want to start with a ready-made workflow template instead of building from scratch. Workflow Builder opens the full Playbook Catalog so you can browse a larger set of templates before adding one to your workspace.
In Workflow Builder, choose **Add from Playbook** to open the Playbook Catalog.
Use search to narrow results by name or description, and use workflow-type filters to focus on playbooks for the kind of automation you want to build.
Select a playbook to open its preview. The detail modal shows the playbook title, description, a preview of its instructions, and whether it is already installed in your workspace.
Install the playbook to add it to your workspace and continue in Workflow Builder, where you can customize the workflow before publishing it. If Overcut finds a matching workflow that is already installed, the preview offers an option to open that existing workflow instead of creating another copy.
Use the catalog preview to compare templates before importing one. This helps you confirm the playbook matches your workflow type and setup needs.
## Accessing workflow metadata
The metadata panel appears on the right side of Workflow Builder when no step is selected. To open it:
1. Open a workflow in Workflow Builder
2. Click anywhere on the canvas background (not on a step or trigger)
3. The properties panel displays the workflow metadata form
Changes auto-save after a brief delay.
***
## Workflow 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 more
### How 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.
When a workflow times out, any in-progress agent sessions are terminated and the execution is marked as failed. Set timeouts generously for complex workflows that involve multiple agent interactions.
***
## 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:
1. Workflows are ordered by priority (lowest number first)
2. Within the same priority level, workflows execute in FIFO order
3. Only one workflow runs per resource at a time
For a deep dive into queuing, locking, and deduplication, see [Workflow Execution Control](/docs/workflows/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 settings
### Model selection cascade
Agents inherit their model from this priority order:
1. **Agent model**: the agent's own `modelKey` if configured
2. **Workflow default**: the value set here in workflow metadata
3. **Workspace default**: configured in [Workspace Settings](/docs/reference/workspace-settings)
4. **System default**: Overcut's managed default model
Use this setting to test workflows with different models without changing workspace defaults. For example, set a faster model for high-volume automation or a more capable model for complex analysis.
For an end-to-end walkthrough, see the [Default Model Configuration quick start](/docs/quick-starts/default-model-configuration).
***
## Status Update Method
Controls how Overcut posts progress comments to pull requests and tickets during workflow execution.
### Options
Creates a new comment for each workflow run. Each execution gets its own acknowledgment, progress updates, and final status.
Keeps status updates in a single thread. Overcut edits the most recent reusable comment instead of creating new ones.
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](/docs/integrations/github) | ✅ Full support | ✅ Full support |
| [Bitbucket](/docs/integrations/bitbucket) | ✅ Full support | ✅ Full support |
| [GitLab](/docs/integrations/gitlab) | ✅ Full support | ✅ Full support |
| [Azure DevOps](/docs/integrations/azure-devops) | ⚠️ PRs supported; tickets fall back to Comment Per Execution | ✅ Full support |
| [Jira](/docs/integrations/jira) | ✅ Full support | ✅ Full support |
Deleting the managed comment removes the marker. The next run creates a new reusable thread.
### 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](/docs/workflows/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.
Automated executions (triggers and schedules) always use the latest published version. Manual runs can optionally target the working draft. See Manual executions and drafts.
***
## Related documentation
* [Workflow Versioning](/docs/workflows/workflow-versioning): draft lifecycle, finding unpublished changes, and publish/discard flow
* [Workflow Version History](/docs/reference/workflow-history): compare versions side-by-side and restore earlier definitions
* [Workflow Execution Control](/docs/workflows/workflow-execution-control): priority queuing, resource locking, and deduplication
* [Triggers](/docs/workflows/triggers): when workflows start
* [Scheduled Workflows](/docs/workflows/scheduled-workflows): time-based automation
* [Default Model Configuration](/docs/quick-starts/default-model-configuration): model selection walkthrough
* [Workspace Settings](/docs/reference/workspace-settings): workspace-level defaults
* [Workflow Self-Improvement](/docs/how-to/workflows/workflow-self-improvement): configure retrospective cadence and sample size from the workflow dashboard
* [Integrations](/docs/integrations/overview): connect to GitHub, GitLab, Jira, and more
* [Building Blocks](/docs/building-blocks): core workflow components