CSV Import Creates Duplicate Users and Orphaned Assignees
You are importing 12,000 issues from a legacy tracker into a Jira Cloud project using CSV import. The CSV has columns: Summary, Description, Status, Assignee, Reporter, Created, Resolved, Issue key, and Parent key (for subtasks). Assignee and Reporter contain email addresses; 1,800 rows reference addresses that do not exist as Jira users. Status values include "Done", "In QA", and "Blocked" - only "Done" maps cleanly. After the first import attempt, 12,000 issues exist but 1,800 show as Unassigned, 4,200 have status "To Do" regardless of source, and subtasks are all orphaned at the top level. A re-import created a second copy of 12,000 issues because "Issue key" was mapped as a field rather than used as an external ID.
1. Explain the three failure classes and the correct import configuration for each.
Read the worked answer
Three independent failures, each with a distinct cause:
Unassigned (1,800 rows): Jira Cloud CSV import cannot create users. Assignee/Reporter values must match existing active accounts by email. Unknown addresses are silently dropped to Unassigned (or the import can be set to fail). Fix: pre-create or invite the 1,800 users, or map unknown assignees to a placeholder account, or add a custom field to preserve the original email for later reconciliation. Decide policy before re-import.
Status collapse (4,200 rows): CSV import maps Status by name to existing statuses in the target workflow. "In QA" and "Blocked" don't exist in the workflow, so they fall back to the initial status ("To Do"). Fix: either (a) add those statuses to the workflow and map them, or (b) accept a lossy mapping and record the original status in a custom field, or (c) pre-transform the CSV to use valid status names. Mapping is by exact name; no fuzzy matching.
Orphaned subtasks: subtasks require the Parent key (or Parent summary) to resolve to an existing parent in the same import or already in Jira. If the parent key column is not mapped, or the parent is created in a later row batch, subtasks import as standard issues. Fix: ensure the parent is imported first (sort parents before children), map the Parent column correctly, and confirm the parent's issue type supports subtasks. In Cloud CSV import, subtask support is limited - verify the target supports it, or import parents first then children in a second pass.
2. The duplicate import already happened. Describe a safe remediation plan and how to prevent recurrence.
Read the worked answer
Remediation (order matters - do not delete first):
- Identify the duplicate set precisely. The second import's issues are the newer 12,000 by Created/import timestamp, or distinguishable by a marker. Build a filter that isolates them and export to CSV as a backup before any deletion.
- Reconcile links and attachments. Duplicates may have comments, links, or attachments added since import. Export comments and link data, then re-apply to the surviving set where needed.
- Delete in controlled batches (e.g., 1,000 at a time) using bulk delete, moving to trash first so recovery is possible within the retention window. Never run a single 12,000-issue delete blind.
- Verify counts against the source (should return to 12,000) and spot-check 20 issues for field integrity.
Prevention:
- Use the external issue ID / "Issue key" as an external ID mapping, not as a regular field. When mapped as external ID, re-imports update existing issues instead of creating new ones. This is the specific misconfiguration that caused duplication.
- Always do a pilot import of 50 rows into a staging project and validate statuses, assignees, and subtask parenting before the full run.
- Keep the original CSV and an import log; record the mapping profile so it is reproducible.
- Enable a pre-import checklist: user existence, status name match, parent ordering, external ID mapping.