Triggers are the starting point for every automation in Overcut. Each trigger maps to a standardized event from an external provider—such as GitHub, GitLab, Jira, or Overcut’s own API. When that event fires, Overcut evaluates your Use Case and starts the flow if all conditions are met.

​
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.

​
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.
When to use delays:
  • 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
Delay behavior:
  • 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

​
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 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.
⸻

​
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 (e.g., repo, user, label).
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

Start Execution

If all checks pass, Overcut begins executing the defined flow.

​
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.