Event Context Reference

Event context provides access to all information about the event that triggered your workflow. You can use this data throughout your workflow using template variables like {{trigger.issue.title}} or {{trigger.repository.fullName}}.

All event properties are platform-agnostic: they work consistently whether your event comes from GitHub, GitLab, Jira, Bitbucket, Azure DevOps, or ClickUp. Overcut automatically normalizes platform-specific data into this standardized format.

Template Variable Syntax

Access event context properties using double curly braces:

{{trigger.issue.title}}
{{trigger.repository.fullName}}
{{trigger.pullRequest.headBranch}}
{{trigger.actor.login}}

You can use these template variables in:

Agent instructions
Action parameters
Conditional logic
Step outputs

Inspect context for a run

This page describes the context shape available to workflow templates. To inspect the actual values for one workflow run, open the run details and select Context to open the Run Context panel. The panel shows read-only JSON with the run’s trigger data and outputs from completed steps. Use it to confirm the values behind template expressions such as {{trigger.issue.title}} and {{outputs.<stepId>.<field>}}. Step outputs update while the run executes.

Base Event Properties

These properties are available for all event types:

Event Metadata

string

The standardized event type that triggered the workflow (e.g., issue_opened, pull_request_merged, mention).Example: {{trigger.eventType}}

string

Human-readable name of the object that triggered the event.Example: {{trigger.triggerObjectName}}

string

Number or identifier of the triggering object (issue number, PR number, etc.).Example: {{trigger.triggerObjectNumber}}

string

Direct URL to the triggering object in the source platform.Example: {{trigger.triggerObjectUrl}}

Repository Context

string

Repository name (e.g., "blog-server").Example: {{trigger.repository.name}}

string

Full repository name including owner (e.g., "acme/blog-server").Example: {{trigger.repository.fullName}}

string

Repository owner username or organization name.Example: {{trigger.repository.owner}}

string

Clone URL for the repository.Example: {{trigger.repository.url}}

string

Default branch name (e.g., "main", "master").Example: {{trigger.repository.defaultBranch}}

string

Git provider name (e.g., "github", "gitlab", "bitbucket").Example: {{trigger.repository.provider}}

Actor Context

The user or bot that triggered the event.

Username or login of the actor.Example: {{trigger.actor.login}}

string

Display name of the actor.Example: {{trigger.actor.name}}

string

Email address of the actor (if available).Example: {{trigger.actor.email}}

string

Type of actor: "User", "Bot", or "Organization".Example: {{trigger.actor.type}}

Organization Context

Available when the repository belongs to an organization.

Organization username or login.Example: {{trigger.organization.login}}

string

Organization display name.Example: {{trigger.organization.name}}

Issue Event Properties

Available for issue-related events: issue_opened, issue_closed, issue_edited, issue_assigned, issue_unassigned, issue_labeled, issue_unlabeled, issue_commented.

Core Issue Properties

number

Issue number (unique within the repository).Example: {{trigger.issue.number}}

string

Issue title.Example: {{trigger.issue.title}}

ClickUp: For non-creation events, the task title may not be included in the webhook payload. trigger.issue.title may be empty in these cases.

string

Current state of the issue: "open" or "closed".Example: {{trigger.issue.state}}

string

Issue description or body content.Example: {{trigger.issue.body}}

string

Username of the issue author.Example: {{trigger.issue.author}}

Issue Metadata

array<string>

Array of label names attached to the issue.Example: {{trigger.issue.labels}} or {{trigger.issue.labels.[0]}} for first label

array<string>

Array of usernames assigned to the issue.Example: {{trigger.issue.assignees}} or {{trigger.issue.assignees.[0]}}

string

Milestone title if the issue is assigned to a milestone.Example: {{trigger.issue.milestone}}

string

Normalized issue type coming from the source tracker (e.g., "Bug", "Task", "Story"). Use this to branch workflows by work item type without writing provider-specific logic.Example: {{trigger.issue.workItemType}}

GitHub issues may return an empty string because the platform does not classify issues, while Jira, GitLab, and Azure DevOps provide their native issue types.

boolean

Whether the issue is confidential.Example: {{trigger.issue.confidential}}

GitLab only - This property is only available for GitLab issues. Returns undefined for other providers.

Status Transition Fields

string

Previous status name for a status transition. Use this value to target a specific change, such as moving from “Backlog” to “In Progress”.Example: {{trigger.statusFrom}}

Provider availability: Jira, Azure DevOps, and ClickUp include the previous status for state change events. Linear does not include the prior status, so trigger.statusFrom is undefined for Linear transitions.

string

New status name after the transition. The value matches the label shown in your tracker.Example: {{trigger.statusTo}}

Provider availability: Jira, Azure DevOps, Linear, and ClickUp supply the destination status for state change events. These fields are empty for issue events that only provide open or closed state without transition details.

Issue Timestamps

string

ISO timestamp when the issue was created.Example: {{trigger.issue.createdAt}}

string

ISO timestamp when the issue was last updated.Example: {{trigger.issue.updatedAt}}

string

ISO timestamp when the issue was closed (if applicable).Example: {{trigger.issue.closedAt}}

Pull Request Event Properties

Available for PR-related events: pull_request_opened, pull_request_closed, pull_request_merged, pull_request_edited, pull_request_reviewed, pull_request_assigned, pull_request_unassigned, pull_request_labeled, pull_request_unlabeled, pull_request_commented, pull_request_review_commented.

boolean

Always true for pull_request_opened events (initial commit set).
true for pull_request_edited only when the edit originates from new commits.
false for metadata-only changes such as title/body edits, label updates, or reviewer requests.

Use this flag in trigger conditions to run workflows exclusively on code-changing updates.

GitLab and GitHub only - This property is only available for GitLab and GitHub pull requests. Returns false for other providers.

string

Normalized action describing the latest change detected on the pull request. Use it to filter workflows based on the specific action that occurred.Available values:

opened — the pull request was created.
closed — the pull request was closed without merging.
merged — the pull request was merged.
reopened — a previously closed pull request was reopened.
ready_for_review — the author (or maintainer) marked a draft pull request ready for review.
converted_to_draft — the pull request was converted to a draft.

Provider support: opened, closed, and merged are available across all providers. reopened is supported on GitHub, GitLab, and Azure DevOps. Draft transitions (ready_for_review, converted_to_draft) are available on GitHub, GitLab, and Azure DevOps only. Bitbucket does not support draft pull requests.

string

Normalized state of the pull request at the time of the event. Values are opened, closed, or merged, regardless of the underlying provider terminology.

Use this field to distinguish lifecycle changes (closed vs. merged) while trigger.prAction captures the precise activity that fired the webhook.

Provider Differences: While all core properties (number, title, state, branches, labels, assignees) are available across all providers, some advanced properties like change statistics, merge status, and reviewer information are provider-specific. Check the individual property notes below for availability.

Core Pull Request Properties

number

Pull request number.Example: {{trigger.pullRequest.number}}

string

Pull request title.Example: {{trigger.pullRequest.title}}

string

Current state: "open", "closed", or "merged".Example: {{trigger.pullRequest.state}}

string

Pull request description or body content.Example: {{trigger.pullRequest.body}}

string

Username of the pull request author.Example: {{trigger.pullRequest.author}}

Branch Information

string

Target branch name (where the PR will be merged into).Example: {{trigger.pullRequest.baseBranch}}

string

Source branch name (the branch with changes).Example: {{trigger.pullRequest.headBranch}}

string

Base commit SHA.Example: {{trigger.pullRequest.baseSha}}

Not available on GitLab - GitLab webhooks don’t include the base SHA (would require an additional API call).

string

Head commit SHA.Example: {{trigger.pullRequest.headSha}}

string

Merge commit SHA (available after merge).Example: {{trigger.pullRequest.mergeCommitSha}}

Pull Request Metadata

array<string>

Array of label names attached to the pull request.Example: {{trigger.pullRequest.labels}}

array<string>

Array of assignee usernames.Example: {{trigger.pullRequest.assignees}}

array<string>

Array of requested reviewer usernames.Example: {{trigger.pullRequest.requestedReviewers}}

GitHub only - GitLab returns an empty array (no explicit reviewer request concept). Not available on Bitbucket or Azure DevOps.

string

Milestone title if assigned.Example: {{trigger.pullRequest.milestone}}

boolean

Whether the pull request is a draft.Example: {{trigger.pullRequest.draft}}

Change Statistics

GitHub only - Change statistics (additions, deletions, changedFiles) are only available for GitHub pull requests. Other providers don’t include these metrics in their webhook payloads.

number

Number of lines added.Example: {{trigger.pullRequest.additions}}

number

Number of lines deleted.Example: {{trigger.pullRequest.deletions}}

number

Number of files changed.Example: {{trigger.pullRequest.changedFiles}}

Merge Status

boolean | null

Whether the pull request can be merged (null if unknown).Example: {{trigger.pullRequest.mergeable}}

GitHub and GitLab only - Not available on Bitbucket or Azure DevOps.

boolean | null

Whether the pull request can be rebased (null if unknown).Example: {{trigger.pullRequest.rebaseable}}

GitHub only - Not available on other providers.

boolean

Whether auto-merge is enabled.Example: {{trigger.pullRequest.autoMerge}}

GitHub only - Not available on other providers.

Pull Request Timestamps

string

ISO timestamp when the pull request was created.Example: {{trigger.pullRequest.createdAt}}

string

ISO timestamp when the pull request was last updated.Example: {{trigger.pullRequest.updatedAt}}

string

ISO timestamp when the pull request was closed (if applicable).Example: {{trigger.pullRequest.closedAt}}

string

ISO timestamp when the pull request was merged (if applicable).Example: {{trigger.pullRequest.mergedAt}}

CI Workflow Event Properties

Available for CI workflow events: ci_workflow_queued, ci_workflow_started, ci_workflow_completed, ci_workflow_failed, ci_workflow_cancelled, ci_workflow_timed_out.

Pull request context (trigger.pullRequest.*) is only populated when trigger.ciWorkflow.isPullRequest is true. The fields available vary by provider. See Pull Request Context in CI Events for details.

Run Identity

string

Unique identifier for the CI run, as assigned by the provider.Example: {{trigger.ciWorkflow.runId}}

string

Name of the pipeline or workflow that executed.Example: {{trigger.ciWorkflow.workflowName}}

string

URL to view the run in the CI provider’s UI.Example: {{trigger.ciWorkflow.workflowUrl}}

Optional: not every provider includes a direct link in its webhook payload.

Status and Outcome

string

Normalized run status. One of: Queued, InProgress, Succeeded, Failed, Cancelled, TimedOut.Example: {{trigger.ciWorkflow.status}}

string

Raw, provider-specific conclusion value (e.g., GitHub’s action_required or GitLab’s manual). Use status for cross-provider logic and conclusion when you need provider-level detail.Example: {{trigger.ciWorkflow.conclusion}}

Optional: only present on terminal-state events (ci_workflow_completed, ci_workflow_failed, ci_workflow_cancelled, ci_workflow_timed_out).

Source Context

string

The branch that triggered the CI run.Example: {{trigger.ciWorkflow.branch}}

string

The commit SHA that the CI run executed against.Example: {{trigger.ciWorkflow.commitSha}}

boolean

Whether the CI run is associated with a pull request. When true, trigger.pullRequest.* fields are available.Example: {{trigger.ciWorkflow.isPullRequest}}

number

Pull request number when the run is PR-associated.Example: {{trigger.ciWorkflow.pullRequestId}}

Optional: only present when trigger.ciWorkflow.isPullRequest is true.

Pull Request Context in CI Events

When a CI run is associated with a pull request, trigger.pullRequest.* fields are populated, but what is available depends on the provider:

GitHub Actions: PR number and branch names are available; title is not included in the webhook payload.
GitLab CI: Full merge request data is only available on MR-triggered pipelines. Add a merge_request_event rule to your .gitlab-ci.yml to ensure MR context is sent.
Azure DevOps: PR ID and branch names are available; title is not included.
Bitbucket Pipelines: Full PR context including title is available.

When available, these fields follow the same schema as Pull Request Event Properties above.

Timing

string

ISO timestamp when the run was queued.Example: {{trigger.ciWorkflow.queuedAt}}

Optional: not available on Azure DevOps.

string

ISO timestamp when the run started executing.Example: {{trigger.ciWorkflow.startedAt}}

Optional: not present for ci_workflow_queued events.

string

ISO timestamp when the run finished.Example: {{trigger.ciWorkflow.completedAt}}

Optional: only present on terminal-state events.

number

Run duration in milliseconds.Example: {{trigger.ciWorkflow.duration}}

Optional: only present on terminal-state events when both start and end times are known.

Additional Fields

number

Total number of jobs in the pipeline.Example: {{trigger.ciWorkflow.jobCount}}

GitLab only: other providers do not include job count in their webhook payloads.

Action-Specific Context

These properties provide additional context about the specific action that triggered the event.

Label Operations

Available for issue_labeled, issue_unlabeled, pull_request_labeled, pull_request_unlabeled events. The labelsAdded / labelsRemoved arrays are also populated on issue_edited for providers without a discrete label event (see the Azure DevOps note below).

string

The label that was added or removed. When several labels change at once this is the first added label only - use trigger.labelsAdded to see all of them.Not supported on Azure DevOps or GitLab - these providers deliver label changes as issue_edited; use trigger.labelsAdded / trigger.labelsRemoved instead.Example: {{trigger.label}}

string

The action performed: "added" or "removed".Not supported on Azure DevOps or GitLab - these providers deliver label changes as issue_edited (a single event can both add and remove labels), so this field is not set; use trigger.labelsAdded / trigger.labelsRemoved instead.Example: {{trigger.labelAction}}

array<string>

All labels added in this change. Match a specific one with the contains operator (e.g. context.trigger.labelsAdded contains "ready-for-development").Example: {{trigger.labelsAdded}}

array<string>

All labels removed in this change. Counterpart to trigger.labelsAdded.Not supported on Linear - Linear’s webhook does not include the names of removed labels, so this field is omitted for Linear label removals.Example: {{trigger.labelsRemoved}}

Provider support: trigger.label and trigger.labelAction are populated only by providers that emit a discrete label event - GitHub, Jira, Linear, and ClickUp.Azure DevOps and GitLab deliver label changes as issue_edited (and a single ADO/GitLab event can add and remove labels at the same time), so trigger.label/trigger.labelAction are not set. Use trigger.labelsAdded / trigger.labelsRemoved instead - for example, trigger on Issue edited with a condition context.trigger.labelsAdded contains "<label>". On Azure DevOps the label is the work-item tag.

Assignee Operations

Available for issue_assigned, issue_unassigned, pull_request_assigned, pull_request_unassigned events.

string

Username of the assignee that was added or removed.Example: {{trigger.assignee}}

string

The action performed: "assigned" or "unassigned".Example: {{trigger.assigneeAction}}

Milestone Operations

string

The milestone that was added or removed.Example: {{trigger.milestone}}

string

The action performed: "added" or "removed".Example: {{trigger.milestoneAction}}

Comment Operations

Available for issue_commented, pull_request_commented, pull_request_review_commented events.

string

Comment ID from the git provider.Example: {{trigger.commentId}}

string

Username of the comment author.Example: {{trigger.commentAuthor}}

string

Full content of the comment.Example: {{trigger.commentBody}}

string

Where the comment was made: "issue" or "pull_request".Example: {{trigger.commentLocation}}

string

ISO timestamp when the comment was created.Example: {{trigger.commentCreatedAt}}

Review Operations

Available for pull_request_reviewed events.

string

Username of the reviewer.Example: {{trigger.reviewer}}

string

Review state: "approved", "changes_requested", "commented", or "dismissed".Example: {{trigger.reviewState}}

string

Review action: "submitted", "edited", or "dismissed".Example: {{trigger.reviewAction}}

Mention Operations

Available for mention events.

string

Username of the user who mentioned the bot.Example: {{trigger.mentionedBy}}

string

Where the mention occurred (e.g., "issue", "pull_request", "comment").Example: {{trigger.mentionLocation}}

string

The full message or content containing the mention.Example: {{trigger.mentionContent}}

Slash Command Operations

Available for slash_command events.

string

The slash command that was used (e.g., "/review").Example: {{trigger.slashCommand}}

boolean

Whether the slash command was used with an @mention.Example: {{trigger.slashCommandWithMention}}

Practical Examples

Example 1: Accessing Issue Properties

Use issue properties in an agent instruction:

- id: "analyze-issue"
  action: "agent.run"
  params:
    agentId: "triage-bot"
    instruction: |
      Review issue #{{trigger.issue.number}}: "{{trigger.issue.title}}"
      
      Issue details:
      - Author: @{{trigger.issue.author}}
      - State: {{trigger.issue.state}}
      - Labels: {{trigger.issue.labels}}
      - Created: {{trigger.issue.createdAt}}
      
      {{trigger.issue.body}}

Example 2: Clone PR Branch

Use pull request branch information in git operations:

- id: "clone-pr-branch"
  action: "git.clone"
  params:
    repoFullName: "{{trigger.repository.fullName}}"
    branch: "{{trigger.pullRequest.headBranch}}"

Example 3: Conditional Logic Based on Event State

Use Handlebars helpers for conditional logic:

- id: "context-aware-agent"
  action: "agent.run"
  params:
    instruction: |
      {{#if (eq trigger.issue.state "closed")}}
        This issue is already closed. Provide a summary of the resolution.
      {{else}}
        This issue is open. Analyze and provide recommendations.
      {{/if}}
      
      {{#if trigger.issue.labels}}
        Labels present: {{trigger.issue.labels}}
      {{else}}
        No labels assigned yet.
      {{/if}}

Example 4: Working with Arrays

Access array elements and iterate:

- id: "check-assignees"
  action: "agent.run"
  params:
    instruction: |
      Issue assignees:
      {{#if trigger.issue.assignees}}
        {{#each trigger.issue.assignees}}
          - @{{this}}
        {{/each}}
      {{else}}
        No assignees yet.
      {{/if}}
      
      First label: {{trigger.issue.labels.[0]}}

Example 5: Mention the Original Author

Reference the event author in responses:

- id: "respond-to-user"
  action: "agent.run"
  params:
    instruction: |
      @{{trigger.issue.author}}, I've analyzed your issue and here are my findings...

Example 6: Use Comment Context

Access comment-specific properties:

- id: "process-comment"
  action: "agent.run"
  params:
    instruction: |
      Process comment by @{{trigger.commentAuthor}}:
      
      {{trigger.commentBody}}
      
      Respond in the {{trigger.commentLocation}} thread.

Example 7: Conditional Repository Selection

Combine with conditional logic for dynamic behavior:

- id: "clone-code"
  action: "git.clone"
  params:
    repoFullName: |
      {{#if outputs.identify-repos.[0]}}
        {{outputs.identify-repos.[0].repoFullName}}
      {{else}}
        {{trigger.repository.fullName}}
      {{/if}}
    branch: "{{trigger.repository.defaultBranch}}"

Example 8: Filter by Actor Type

Exclude bot-triggered events:

# In trigger conditions
trigger:
  eventType: "issue_commented"
  conditions:
    - field: "context.actor.type"
      operator: "not_equals"
      value: "Bot"

Example 9: Run Workflow Only When Commits Are Added to a PR

Use the trigger.commitAdded flag to avoid running expensive jobs on metadata-only changes:

trigger:
  eventType: "pull_request_edited"
  conditions:
    - field: "context.trigger.commitAdded"
      operator: "equals"
      value: true

In this setup, the workflow will execute when a pull request is opened or when new commits are pushed, but it will not run if the PR author only updates the title, description, labels, or other metadata.

Custom Event Properties

Workflows triggered by a Custom Event receive the inbound webhook body and any query-string parameters under trigger.payload.*. The four well-known meta fields are also lifted into the standard trigger.* slots so they look like any other trigger in the runs list.

Event Metadata

string

Always "custom_event" for Custom Event triggers.

string

Populated from the caller’s objectName payload field. Falls back to the event’s slug (for example, deployment_completed) when absent.Example: {{trigger.triggerObjectName}} → "Deploy #1234 to production"

string

Populated from the caller’s objectNumber payload field. Empty when absent.Example: {{trigger.triggerObjectNumber}} → "1234"

string

Populated from the caller’s objectUrl payload field. Used as the run’s click-through link when present.Example: {{trigger.triggerObjectUrl}} → "https://github.com/acme/api/actions/runs/1234"

Populated from the caller’s actor payload field. trigger.actor.type is always "Bot" for Custom Events.Example: {{trigger.actor.login}} → "deploy-bot"

Payload

object

The full request body. Query-string parameters (other than the reserved projectId and lockKey) are merged in as top-level string fields. Body values win on conflict.Example: {{trigger.payload.environment}} → "production"

Use dot notation for nested keys: {{trigger.payload.service.region}}. Missing intermediate keys evaluate to undefined without throwing.

Custom Event Identifiers

string

Internal ID of the Custom Event definition.

string

The event’s slug, e.g. "deployment_completed". This is what trigger conditions match against.

string | undefined

Set when the caller targeted a specific project via ?projectId=. Undefined on workspace-wide fan-out.

string | undefined

Set when the caller passed ?lockKey=. Undefined otherwise.

Template Helpers

Overcut supports Handlebars helpers for advanced logic:

Comparison Helpers

{{#if (eq value1 value2)}} - Equals
{{#if (ne value1 value2)}} - Not equals
{{#if (gt value1 value2)}} - Greater than
{{#if (lt value1 value2)}} - Less than
{{#if (gte value1 value2)}} - Greater than or equal
{{#if (lte value1 value2)}} - Less than or equal

Logical Helpers

{{#if (and condition1 condition2)}} - Logical AND
{{#if (or condition1 condition2)}} - Logical OR
{{#if (not condition)}} - Logical NOT

Iteration

{{#each array}}...{{/each}} - Iterate over arrays
{{@index}} - Current iteration index
{{@first}} / {{@last}} - First/last iteration flags

Notes and Best Practices

Platform Normalization

All properties are automatically normalized from platform-specific formats. For example, GitHub’s pull_request becomes pullRequest, and Jira’s key becomes number.

Property Availability

Not all properties are available for all events. For example, trigger.pullRequest is only available for pull request events, and trigger.issue only for issue events. Optional properties may be null or undefined if not provided by the platform.

Provider-Specific Properties

While Overcut normalizes events across all platforms, some properties are only available from specific providers due to webhook payload limitations: Issue Properties:

confidential - GitLab only

Pull Request Properties:

additions, deletions, changedFiles - GitHub only
autoMerge, rebaseable - GitHub only
mergeable - GitHub and GitLab only
requestedReviewers - GitHub only (GitLab returns empty array)
baseSha - Not available on GitLab

CI Workflow Properties:

jobCount - GitLab only
queuedAt - Not available on Azure DevOps
trigger.pullRequest.title in CI events - Bitbucket only

Array Access

When accessing array elements, always check if the array exists first using {{#if trigger.issue.labels}} to avoid template rendering errors.

Dynamic Workflows

Combine event context with step outputs ({{outputs.step-id.property}}) for powerful dynamic workflows that adapt based on runtime data.

Triggers

Learn about trigger types and event normalization

Workflows

Understand workflow structure and template variables

Agent Run

Use event context in agent instructions

Git Clone

Clone repositories using trigger context

​Template Variable Syntax

​Inspect context for a run

​Base Event Properties

​Event Metadata

​Repository Context

​Actor Context

​Organization Context

​Issue Event Properties

​Core Issue Properties

​Issue Metadata

​Status Transition Fields

​Issue Timestamps

​Pull Request Event Properties

​Core Pull Request Properties

​Branch Information

​Pull Request Metadata

​Change Statistics

​Merge Status

​Pull Request Timestamps

​CI Workflow Event Properties

​Run Identity

​Status and Outcome

​Source Context

​Pull Request Context in CI Events

​Timing

​Additional Fields

​Action-Specific Context

​Label Operations

​Assignee Operations

​Milestone Operations

​Comment Operations

​Review Operations

​Mention Operations

​Slash Command Operations

​Practical Examples

​Example 1: Accessing Issue Properties

​Example 2: Clone PR Branch

​Example 3: Conditional Logic Based on Event State

​Example 4: Working with Arrays

​Example 5: Mention the Original Author

​Example 6: Use Comment Context

​Example 7: Conditional Repository Selection

​Example 8: Filter by Actor Type

​Example 9: Run Workflow Only When Commits Are Added to a PR

​Custom Event Properties

​Event Metadata

​Payload

​Custom Event Identifiers

​Template Helpers

​Comparison Helpers

​Logical Helpers

​Iteration

​Notes and Best Practices

​Platform Normalization

​Property Availability

​Provider-Specific Properties

​Array Access

​Dynamic Workflows

​Related Documentation

Triggers

Workflows

Agent Run

Git Clone

Template Variable Syntax

Inspect context for a run

Base Event Properties

Event Metadata

Repository Context

Actor Context

Organization Context

Issue Event Properties

Core Issue Properties

Issue Metadata

Status Transition Fields

Issue Timestamps

Pull Request Event Properties

Core Pull Request Properties

Branch Information

Pull Request Metadata

Change Statistics

Merge Status

Pull Request Timestamps

CI Workflow Event Properties

Run Identity

Status and Outcome

Source Context

Pull Request Context in CI Events

Timing

Additional Fields

Action-Specific Context

Label Operations

Assignee Operations

Milestone Operations

Comment Operations

Review Operations

Mention Operations

Slash Command Operations

Practical Examples

Example 1: Accessing Issue Properties

Example 2: Clone PR Branch

Example 3: Conditional Logic Based on Event State

Example 4: Working with Arrays

Example 5: Mention the Original Author

Example 6: Use Comment Context

Example 7: Conditional Repository Selection

Example 8: Filter by Actor Type

Example 9: Run Workflow Only When Commits Are Added to a PR

Custom Event Properties

Event Metadata

Payload

Custom Event Identifiers

Template Helpers

Comparison Helpers

Logical Helpers

Iteration

Notes and Best Practices

Platform Normalization

Property Availability

Provider-Specific Properties

Array Access

Dynamic Workflows

Related Documentation