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.
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
Issue Events
- 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.
- 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.
Manual, Mention & Slash Command
- manual : Manually triggered from UI or API.
- 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.1
Event Received
A webhook from GitHub/GitLab/Jira or a manual call is received by Overcut.
2
Event Normalization
Platform-specific events are converted to standardized formats (e.g., Jira issue events become
issue_opened, issue_commented).3
Match Trigger Type
The normalized event is compared to the trigger identifier defined in your Use Case.
4
Check Conditions
Optional filters like repository name, project key, or label value are evaluated.
5
Queue for Execution
Matching workflows are queued for the specific resource (issue/PR/repo) with priority ordering and event deduplication.
6
Controlled Execution
Workflows execute in priority order with resource locking to prevent conflicts.
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.1
Create a new Use Case
Go to the
Use Cases tab and click Create Use Case.2
Edit the Trigger block
Click the default Trigger node to configure the event type and any conditions.
3
Connect actions and agents
Drag and connect additional steps that should run after the trigger.
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.
Event Context Reference
View the complete reference of all available event properties, organized by event type with practical examples.