Status sync and duplicate handling

Before re-exporting a source

Use this page when a report finding or generated fix task might already have downstream work in Jira, GitHub Issues, GitLab Issues, Bitbucket, a work management tool or a webhook-created ticket. Status sync and duplicate handling keep one WebRiskOps source tied to one external work item. Start from `/reports/{report}/ticket-exports`. Do not approve another export until the source identifiers, provider reference and latest sync state are clear.

Review duplicate and sync state

Follow the path `Ticket export source → Existing provider reference → Status sync check → Duplicate decision → Retry, open existing ticket or portable fallback`.

1. Open /reports/{report}/ticket-exports and expand the source row that may already have provider work. Result: provider key, source type, source ID and provider ticket ID are visible through source_type, source_id, provider_key and existing export records before another ticket is approved.
2. Check provider_ticket_id and external_issue_id on existing exports. Result: you know whether the provider already has a Jira issue, GitHub Issue, GitLab Issue, Bitbucket issue, work item, task or webhook-created reference.
3. Review export_status and last_synced_at before deciding what to do next. Result: stale, failed, retry scheduled or disconnected sync is visible instead of hidden behind a duplicate approval.
4. If TICKET_EXPORT_DUPLICATE appears, open the existing provider link instead of creating a new ticket. Result: one source remains tied to one downstream work item.
5. If TICKET_STATUS_SYNC_FAILED appears, retry sync or reconnect the provider target before approving another export. Result: WebRiskOps keeps duplicate prevention based on current provider state.
6. Use portable fallback only when provider sync or native export cannot be restored safely. Result: the customer can continue handoff without breaking source identifiers.
7. After the external team applies the change, continue to customer-applied evidence or retest flow. Result: WebRiskOps verifies remediation through evidence or retest, not provider ticket closure alone.

Read provider status sync

Provider status sync explains the tracker state without changing report truth. It is useful when a provider ticket exists, but the customer needs to know whether WebRiskOps can still read the external reference.

• Store `provider_ticket_id`, provider status, external key, provider URL, `export_status` and `last_synced_at`.
• Map provider states to WebRiskOps states such as open, in progress, done, retry scheduled, partial failed, failed, blocked or disconnected.
• Keep portable fallback separate from provider-native status sync, because CSV, Markdown and JSON handoff files do not have live provider status.
• Do not mark a finding fixed just because a provider ticket was closed. Use customer-applied evidence or retest before changing remediation state.

Ready status sync states

Continue only when the duplicate state and provider status are understandable.

• Provider reference visible means `provider_ticket_id`, provider URL or `external_issue_id` is available for the existing export.
• Source identifiers visible means `source_type` and `source_id` tie the external work item to one WebRiskOps finding or generated fix task.
• Sync fresh means `last_synced_at` is recent enough for the customer to trust the provider status before another export is approved.
• Duplicate guard ready means WebRiskOps can block or update repeated exports for the same source instead of creating another provider ticket.
• Fallback boundary clear means portable export is only used when provider sync or provider-native export cannot be restored safely.

Blocked or unsafe sync states

Do not approve another export while the source state is unclear.

• `TICKET_EXPORT_DUPLICATE` means the source already has a provider reference. Open the existing provider link before creating new downstream work.
• `TICKET_STATUS_SYNC_FAILED` means WebRiskOps could not read or map the latest provider state. Retry sync or reconnect the provider target.
• Revoked credentials mean reconnect the integration before relying on provider status.
• Rate limits mean wait for the retry window while WebRiskOps keeps the last known status visible.
• Missing or deleted provider references mean the export record cannot sync until a valid provider link exists.
• Disconnected provider state does not delete WebRiskOps source records or prove that remediation is complete.

Continue after duplicate review

Continue to Ticket export provider overview when the customer needs to choose a provider target again. Use Portable export fallbacks when provider sync cannot be restored safely. Use Jira export or Webhook export for provider-specific setup, and use Customer-applied evidence after the external team applies the fix.