Fix tasks

Before creating fix tasks

Use this page after a private report has at least one actionable finding with enough evidence for remediation. A fix task turns a report finding into customer- or developer-owned work with status, evidence links, fix-credit state, delivery mode and retest follow-up. Create a task only from findings that still need action. If the evidence is incomplete, scope is unclear or the finding might be a false positive, resolve that review before spending fix credits or sending work to another team.

Create fix tasks from report findings

Follow the path `Reports → Private report → Finding → Create fix task → Fix task`.

1. Open /reports/{report} and review an actionable finding. Result: the finding has severity, category, evidence, suggested remediation and scope context before any task is created.
2. Confirm the finding is not marked false positive and does not need more evidence. Result: fix tasks are created only from findings that still require action.
3. Check plan and fix-credit state before clicking Create fix task. Result: the task can reserve the correct fix credit or show the exact billing block.
4. Choose the supported delivery mode: ticket-only, customer-applied evidence, review-only patch or connected remediation when approved. Result: the task starts with the safest available handoff path.
5. Click Create fix task from the report action or issue detail. Result: the task appears with status, owner next action, evidence links, delivery mode and retest option.
6. Open /fix-tasks/{fixTask} and read the status before assigning work. Result: the developer or customer knows whether to connect access, export a ticket, apply evidence or wait for a retest.

Fix task states

Continue only when the task status explains the next safe action.

• Ready for handoff means the finding, evidence and delivery mode are available for a customer or developer to act on.
• Waiting for fix credit means the account needs [Automated fix credits](/docs/billing/automated-fix-credits) before WebRiskOps can create or continue the task.
• Ticket-only available means connected access is missing, unsupported or unnecessary, so the task should move through [Ticket-only fallback](/docs/remediation/ticket-only-fallback).
• Connected access review means provider access, scope and approval must be checked before any repository, CMS, GTM, CMP or platform action is attempted.
• Customer evidence required means the customer or developer must record what changed before a retest can prove the fix.

Blocked or unsafe states

Do not create or assign a task when a blocked state is visible.

• No eligible finding means return to [Report evidence](/docs/reports/report-evidence) and confirm the finding is actionable.
• Possible false positive means complete [False-positive review](/docs/reports/false-positive-review) before creating work.
• Fix credit exhausted means use [Automated fix credits](/docs/billing/automated-fix-credits) before continuing.
• Unsafe or missing access means use [Ticket-only fallback](/docs/remediation/ticket-only-fallback) instead of requesting broader credentials.
• Secret or private evidence means remove sensitive data before exporting, assigning or sharing the task.

Continue to ticket fallback or evidence

Continue to [Ticket-only fallback](/docs/remediation/ticket-only-fallback) when connected access is unavailable or unsafe. Use [Customer-applied evidence](/docs/remediation/customer-applied-evidence) after the customer or developer applies the change outside WebRiskOps, then continue to [Retests and monitoring conversion](/docs/remediation/retests-and-monitoring-conversion) when the task has evidence ready to verify.