Ticket export failures

Before retrying an export

Use this page when ticket creation, issue sync, duplicate handling, status sync or portable fallback generation fails. Start from the export attempt because it records provider response, mapping state, idempotency and fallback eligibility.

• Open the ticket export attempt
• Check `ticket_export_id`, `export_status`, `provider_key`, `duplicate_fingerprint` and `portable_export_path`.
• Keep retries idempotent so the same finding does not create duplicate downstream work.

Triage the ticket export attempt

Follow the path `Report → Ticket export attempt → Provider response → Retry, fallback or stop`.

1. Open `/reports/{report}/ticket-exports` and choose the failed export attempt. Result: `ticket_export_id`, `report_id`, `provider_key` and `export_status` are visible before retry.
2. Read `provider_error_code`, `provider_response_code`, `mapping_status`, `duplicate_fingerprint`, `idempotency_key` and `retry_after`. Result: the page separates provider delivery failure, field mapping, duplicate block, status sync and portable fallback states.
3. If `TICKET_EXPORT_DELIVERY_FAILED` appears, open Provider connection errors before retrying. Result: auth, base URL, scope or rate-limit fixes happen in `/settings`.
4. If `TICKET_EXPORT_MAPPING_REQUIRED` appears, review required provider fields and default mappings. Result: export payload is complete before another provider request.
5. If `TICKET_EXPORT_DUPLICATE_BLOCKED` appears, compare `duplicate_fingerprint`, `idempotency_key` and any `external_ticket_url`. Result: WebRiskOps updates or opens the existing ticket instead of creating a duplicate.
6. If `TICKET_STATUS_SYNC_FAILED` appears, keep the ticket link and retry sync after provider recovery. Result: status changes do not detach from the original ticket.
7. If provider-native delivery remains unavailable, generate the portable fallback and verify `portable_export_path`. Result: the customer can import CSV, Markdown or JSON without provider credentials in the file.
8. Retry from `/reports/{report}/ticket-exports` only after provider, mapping, duplicate or `retry_after` state is clear. Result: retries are idempotent and do not create duplicate downstream work.
9. Stop when the provider workspace, project, board, repository or webhook target is not customer-owned or cannot receive evidence safely. Result: private credentials and unrelated destinations stay excluded.
10. Continue to Ticket export provider overview, Work management export, Portable export fallbacks or Status sync and duplicate handling based on the remaining owner. Result: the customer lands on the setup or fallback guide that can clear the export.

Ticket export failure reasons

Use the code to choose provider recovery, mapping, fallback or stop.

• `TICKET_EXPORT_DELIVERY_FAILED` means the provider request failed after WebRiskOps built the export payload.
• `TICKET_EXPORT_MAPPING_REQUIRED` means required provider fields, project, board, issue type, labels or assignees are missing.
• `TICKET_EXPORT_DUPLICATE_BLOCKED` means duplicate detection found an existing downstream ticket for the same finding or export fingerprint.
• `TICKET_STATUS_SYNC_FAILED` means `status_sync_status` could not be read or written after ticket creation.
• `TICKET_EXPORT_PROVIDER_UNAVAILABLE`, `PROVIDER_AUTH_FAILED` and `PORTABLE_EXPORT_FAILED` determine whether provider recovery, safe fallback generation or stop is next.

Retry fallback or stop rules

Retry only when the owning reason has changed.

• Use the same `idempotency_key` for retries of the same finding or export attempt.
• Wait for `retry_after` when the provider or webhook target has a cooldown.
• Generate portable CSV, Markdown or JSON when provider-native export is blocked and `portable_export_path` can be created safely.
• Stop when the provider target is unrelated, private, missing ownership, missing required mapping or unsafe for evidence delivery.

Ready and blocked ticket export states

The export is ready when delivery, duplicate handling and fallback state are clear.

• Ready: provider is connected, mapping is complete, duplicate state is known, status sync is healthy or portable export exists.
• Still blocked: provider auth failed, base URL is unsafe, mapping is incomplete, duplicate is unresolved, retry cooldown is active, portable path failed or destination ownership is unclear.
• Stop: a duplicate provider ticket already exists and should be opened or updated instead of creating another one.

Continue after export triage

Use the linked guide for the owner that remains after the export attempt is understood.

• Ticket export provider overview explains provider choice, target readiness and export method selection.
• Work management export explains mapping to Trello, Linear, Azure DevOps, YouTrack, Asana and ClickUp.
• Portable export fallbacks explains CSV, Markdown and JSON generation when provider-native export is unavailable.
• Status sync and duplicate handling explains duplicate fingerprints, status sync and existing-ticket behavior.
• Provider connection errors and Webhook retries explain provider auth, base URL and webhook delivery failures.