Supported Platforms
Overcut supports triggers from multiple platforms, with events normalized to a consistent format:- GitHub: Pull requests, issues, and review activity
- GitLab: Merge requests, issues, and comments
- Jira: Issue lifecycle, comments, and status changes
- Bitbucket: Pull requests, issues, and comments
- Azure DevOps: Work items, pull requests, and comments
All platforms use the same trigger types and conditions. Overcut automatically normalizes platform-specific events into standardized formats, so your workflows work consistently regardless of the source platform.
Trigger Categories
Issue Events
Kick off flows when issues are opened, labeled, edited, or commented on.
Pull Request Events
Start workflows for PR creation, merging, review activity, and more.
CI Workflow Events
Trigger workflows when CI runs are queued, started, completed, failed, cancelled, or timed out.
Manual, Mentions & Slash Commands
Run workflows with a button click, by @mentioning Overcut, or via custom slash commands.
Scheduled
Run workflows on a cron-based schedule.
Scheduled Triggers
Scheduled Workflows let you run automations on a cron-based schedule—hourly, daily, weekly, or any custom interval. They are ideal for maintenance, reporting, and other recurring tasks that aren’t tied to an external event.Trigger Delays
You can configure an optional delay before workflow execution to allow related updates to complete. This is particularly useful for:- Issue creation: Wait for fields to be filled out and labels to be added
- PR updates: Allow time for description edits and initial comments
- Field changes: Let users complete their input before processing begins
Interactive triggers (slash commands and mentions) always ignore delay settings and execute immediately for responsive user experience.
- 1-2 minutes: For issue/PR creation to allow the user to complete the initial setup
- No delay: For immediate response needs or when context is already complete
- Delays are applied when the trigger is first detected
- If additional related events occur during the delay window, the timer resets
- This ensures the workflow waits for activity to settle before executing
- During delays, events automatically merge through event deduplication
Multi-trigger orchestration (OR logic)
You can configure multiple triggers for a single workflow. When an event occurs, all triggers are evaluated in random order. If any trigger matches the event, the workflow is triggered using that matching trigger’s configuration—its delay, filters, and execution mode remain intact. Evaluation stops as soon as one trigger matches.Single trigger setup
Use one trigger when the workflow should start from exactly one event source (for example,
issue_opened). The trigger simply relays that event to the first downstream step.Multi-trigger setup
Add multiple triggers (for example,
issue_labeled or pull_request_merged) when the workflow should start if any of those events occur. The dispatcher evaluates triggers in random order and starts the workflow as soon as one trigger matches—all other triggers are skipped for that event.You can mix scheduled, event, and manual triggers in a single workflow, but there are some limitations:
- Only one scheduled trigger is allowed per workflow; use cron expressions within that trigger if you need multiple execution times.
- Each type of trigger requires a different configuration:
- Scheduled triggers require a cron expression.
- Event triggers require a set of filters.
- Manual triggers require a slash command.
Editing triggers in the Properties panel
Selecting any trigger highlights it inside the Properties panel on the right. The form reconfigures itself to show only the fields that apply to the selected trigger, so you are never editing irrelevant inputs. Live previews for manual slash commands update as you type, and any schema validation issues are surfaced inline before you can publish.- Event triggers
- Scheduled triggers
- Manual triggers
- Use the conditions builder to stack repository, project, label, or author filters. Each row maps directly to the trigger schema, so what you configure visually is what the dispatcher enforces.
- Event-specific fields (such as issue metadata versus pull-request metadata) appear automatically, keeping the available filters in sync with the selected event.
- CI workflow triggers surface filters for run status, conclusion, branch, commit SHA, run ID, workflow name or URL, pull request association or ID, and job count.
- Inline warnings appear beside any incomplete filter rows—for example, if you add a label condition but leave the value empty, the panel flags it before allowing you to save.
- The delay setting is available for all event triggers. It allows you to delay the workflow execution by a certain number of seconds.
Issue Events
Issue triggers include lifecycle actions (opened and closed), content updates, and status transitions. Use State Change when an issue moves between workflow states without being created or closed.- issue_opened : Issue was created.
- issue_closed : Issue was closed.
- issue_edited : Title or body changed.
- issue_assigned : Assignee added.
- issue_unassigned : Assignee removed.
- issue_labeled : Label was added.
- issue_unlabeled : Label was removed.
- issue_commented : New comment was posted on an issue.
State Change is an Issue Action option in the trigger filters. It applies to status transitions that do not create or close the issue (for example, Backlog → In Progress). Use opened and closed when you want to react to creation or closure events, even if the status also changes at the same time.
Pull Request Events
- pull_request_opened : Pull request was opened.
- pull_request_closed : Pull request was closed without merge.
- pull_request_merged : Pull request was merged into base.
- pull_request_edited : Title or description of PR was changed.
- pull_request_reviewed : A review was submitted (approve/request changes).
- pull_request_assigned : An assignee was added to the pull request.
- pull_request_unassigned : An assignee was removed from the pull request.
- pull_request_labeled : Label was added to the pull request.
- pull_request_unlabeled : Label was removed from the pull request.
- pull_request_commented : A general comment was posted on the pull request.
- pull_request_review_commented : An inline code comment was posted during review.
CI Workflow Events
CI workflow events fire when a pipeline run changes state in a connected CI provider (GitHub Actions, GitLab CI, Azure DevOps Pipelines, or Bitbucket Pipelines). When the run is associated with a pull request,trigger.pullRequest.* fields are also available—gated on trigger.ciWorkflow.isPullRequest.
- ci_workflow_queued : A CI run entered the queue. Use this to track pipeline wait times or alert on queuing delays.
- ci_workflow_started : A CI run started executing. Useful for notifying the team that a build is in progress.
- ci_workflow_completed : A CI run finished regardless of outcome. Check
trigger.ciWorkflow.statusfor the result. - ci_workflow_failed : A CI run ended with a failure. Trigger notifications, create follow-up issues, or post PR comments.
- ci_workflow_cancelled : A CI run was cancelled before completion.
- ci_workflow_timed_out : A CI run stopped after exceeding its time limit.
Manual, Mention & Slash Command
- manual : Manually triggered using a slash command on an issue, PR, or comment.
- mention : Overcut is @mentioned in an issue, PR, or comment.
- slash_command : A comment contains a configured slash command (e.g.
/review).
A
slash_command trigger fires when Overcut detects a comment that begins with the configured command string (for example, /review). This works across all platforms—GitHub pull requests, Jira issues, GitLab merge requests, and more. If requireMention is enabled in the trigger settings, the command must follow an @overcut mention.For detailed setup instructions, see the Slash Command Guide.How Triggers Are Evaluated
Overcut matches incoming webhook payloads against the configured trigger type and optional filters, then manages execution through resource locking and priority queuing.Event Normalization
Platform-specific events are converted to standardized formats (e.g., Jira issue events become
issue_opened, issue_commented).Match Trigger Type
The normalized event is compared to the trigger identifier defined in your Use Case.
Queue for Execution
Matching workflows are queued for the specific resource (issue/PR/repo) with priority ordering and event deduplication.
Overcut uses resource locking and priority queuing to ensure predictable execution order and prevent race conditions when multiple workflows target the same resource.
Using Triggers in a Workflow
When you create a new Use Case, Overcut inserts a Trigger block by default. You can customize its settings directly in the canvas UI.Manage trigger cards inside the container
Select the Trigger Container to open the Properties panel for the highlighted card. Use the canvas-level
Add trigger button to insert new cards, drag the handle on each card to reorder them, and remove any unused cards from the inline menu.For workflows that need to work with multiple repositories or automatically identify the most relevant repository for a ticket, consider adding a
repo.identify step after your trigger. This step uses AI-powered analysis to determine which code repositories are most relevant to the ticket context. Learn more in our Repository Mapping guide.Accessing Trigger Data
Once a trigger fires, all event data is available throughout your workflow via template variables. You can access properties like{{trigger.issue.title}}, {{trigger.repository.fullName}}, {{trigger.pullRequest.headBranch}}, and many more.