Integration reference

Jira Trigger and Action reference

Start from Jira issue, comment, sprint, version, and property events and automate issue operations.

Authentication

Connect a Jira account and site with the scopes and project permissions required by the selected operation.

• Trigger account type: oauth2; reconnect by oauth.
• Action connection type: oauth2; available modes: Connected Jira account.

Create or reuse the account from a Trigger or Action dialog, or manage it under Settings → Connected accounts. See Authentication and permissions for scopes and access diagnostics, or Connected accounts for reuse, reconnect, revocation, and credential rotation.

Scopes and permissions

Base Trigger authorization requests: read:me, read:jira-work, manage:jira-webhook, report:personal-data, offline_access.

Operation-specific requirements appear in the tables below. Custom event selections can add scopes dynamically, so the current Trigger or Action dialog remains authoritative for the exact consent request.

Use Jira as a Trigger

The current provider manifest contains 22 available Trigger definitions. Representative definitions include:

• Issue Created
• Issue Updated
• Comment Created
• Sprint Started
• Version Released
• Custom Webhook Events

Choose the narrowest event definition that fits the Workflow. Configure provider-specific resource and event filters in the Source dialog before adding broader Workflow Filters.

Use Jira Actions

The current Action manifest contains 6 operations. Representative Actions include:

• Create Issue
• Update Issue
• Add Comment
• Transition Issue
• Assign Issue
• Custom API Request

The Action editor reads its required permissions, fields, remote resource pickers, output schema, and rate limit from the provider manifest. Available fields can change with the selected operation and authentication mode.

Build a Workflow

1. Create a Source using a Jira Trigger definition.
2. Create a Workflow with that Source as its Trigger.
3. Add the required Jira Action and select the connected account.
4. Map Trigger or earlier-Step data into the Action fields with the field picker.
5. Add a Filter, Paths, Delay, or Transformation when the route needs it.
6. Activate the Workflow, produce a controlled event, and verify the run in Audit and in Jira.

Troubleshooting Jira

The account is missing or cannot be selected

Confirm the active FastHook team, provider, account status, and authentication mode. A disabled or revoked account cannot execute an Action.

A resource picker is empty

Verify that the connected provider identity can access the resource itself. OAuth consent does not add workspace, repository, channel, drive, project, base, or record permissions.

The editor asks for additional scopes

Reconnect the same account from the affected Trigger or Action so FastHook can request its current manifest scopes. Then reopen the editor and select the resource again.

An active Workflow returns 401, 403, or a permission error

Compare the selected operation’s access requirements below with the account recorded in Audit. Check provider-side membership and object access before repeating the Action.

The provider returns 429 or a temporary 5xx

Inspect the Step attempt and retryability in Audit. FastHook can retry temporary failures, but provider quotas and idempotency rules still apply.

Provider-specific checks

• JQL can narrow supported issue and comment subscriptions.
• Issue types, transitions, and fields depend on the selected Jira site and project.
• Every Trigger exposes an event-specific primary output for cross-provider default mapping; Jira resource identifiers are reused only when the source payload proves them.
• All 22 Trigger and 6 Action operations publish versioned schema.json contracts.

Next

• Explore Jira integrations
• Trigger configuration
• Action configuration
• Data mapping
• Error handling
• Authentication and permissions
• All automation integrations