Export findings to external ticket trackers

Before exporting a finding

Use this page when a report finding or generated fix task needs to become work in another tracker. The provider overview helps the customer choose the right destination before WebRiskOps sends title, affected URL, severity, acceptance criteria or evidence-safe links outside the product. Start from `/reports/{report}/ticket-exports`. Do not export a ticket until the source, destination provider, preview and duplicate state are clear.

Choose the provider path

Follow the path `Report finding → Ticket export source → Provider target → Preview and duplicate check → External ticket or portable export`. Provider-native export creates or updates a ticket in the selected tracker. Use the dedicated provider page that matches the active target:

1. Open /reports/{report}/ticket-exports from the report that contains the finding or generated fix task. Result: report issue and fix task sources are visible before a tracker receives work.
2. Select one source row and confirm whether it is a report_issue or fix_task. Result: source_type and source_id tie the external work item to one WebRiskOps evidence record.
3. Review each available target for provider_key, active state, deployment_mode and base_url when the tracker is self-hosted. Result: the destination is known before fields or evidence leave WebRiskOps.
4. Choose an active ticket export target that matches the external team: Jira, GitHub Issues, GitLab Issues, Bitbucket, work management tool or webhook. Result: the preview uses the right provider mapping instead of a generic payload.
5. Use portable_export, csv_export, markdown_export or json_export when no provider target is active or safe. Result: the customer still receives an evidence-safe handoff without requesting unrelated credentials.
6. Review title, affected URL, severity, acceptance criteria, safe evidence links and duplicate state. Result: unsafe raw artifacts, secrets and repeated provider tickets are caught before approval.
7. Approve only after source, provider target and preview match the customer's tracker. Result: WebRiskOps queues the export, stores external_issue_id when available and keeps duplicate handling tied to the same source.

• `jira_cloud`, `jira_data_center` or `jira_server` for Jira Cloud and Jira Data Center/Server.
• `github_issues` or `github_enterprise_issues` for GitHub Issues without granting remediation access.
• `gitlab_issues` or `gitlab_self_managed_issues` for GitLab Issues.
• `bitbucket_cloud_issues` for Bitbucket Cloud repositories with issue tracking enabled.
• `trello_cloud`, `linear_cloud`, `azure_devops_services`, `azure_devops_server`, `youtrack_cloud`, `youtrack_server`, `asana_cloud` or `clickup_cloud` for work management tools.
• `generic_webhook`, `zapier_webhook`, `make_webhook` or `n8n_webhook` for customer-owned automation endpoints.
• `portable_export`, `csv_export`, `markdown_export` or `json_export` when provider-native export is unavailable.

Confirm the provider-neutral preview

The preview is the customer-safe source of truth for what leaves WebRiskOps.

• Check `provider_key`, `source_type`, `source_id` and the selected provider target before approval.
• Confirm that evidence links are expiring WebRiskOps links, not raw private artifact paths.
• Confirm that `webhook_url` belongs to the customer-owned automation endpoint before using a webhook target.
• Use existing exports on the source row to see whether the provider already has an external ticket reference or `external_issue_id`.
• If the preview shows `TICKET_EXPORT_DUPLICATE`, open the existing provider link instead of creating another ticket.

Ready export states

Continue only when the export target and preview are safe.

• Provider target active means the selected tracker connection can receive a ticket for this report project.
• Preview ready means title, affected URL, severity, acceptance criteria and evidence-safe links are visible before approval.
• Duplicate reference visible means WebRiskOps can update or block repeat exports instead of creating another downstream ticket.
• Portable fallback ready means a CSV, Markdown or JSON handoff is available when provider-native export is not available.
• Status sync ready means provider references can be reviewed later without treating provider closure as proof of remediation.

Blocked states and safe fallbacks

Do not work around a blocked provider state.

• Target inactive or revoked means reconnect the provider from the integration setup path before retrying.
• Provider unavailable means choose another active target or use Portable export fallbacks.
• Self-hosted unsafe URL means use the cloud provider, approved tunnel policy, owner allowlist or portable fallback before export.
• Rate limited means wait for the retry window; WebRiskOps keeps the source queued or retry scheduled.
• Mapping required means complete provider-specific fields such as project, repository, board, list, issue type, label, priority or assignee.
• `TICKET_EXPORT_DUPLICATE` means use Status sync and duplicate handling before approving another export.
• Secret or private artifact in preview means stop and redact the evidence before sending anything to an external tracker.

Continue to provider-specific export

Continue to the provider-specific page after the source and target are clear: Jira export, GitHub Issues export, GitLab Issues export, Work management export or Webhook export. Use Portable export fallbacks when no provider target is ready, and Status sync and duplicate handling when the source already has an external reference.