Move your Linear issues into Fareeqy

That is normal in Linear and does not make the row invalid. The importer uses Team to name the Fareeqy project when Project is blank, then falls back to the worksheet or file name if neither field is available. If you choose Project itself for task-list grouping, that column is excluded from project naming and Team supplies the level above it. The Issue stays present instead of producing an untitled project because one cell was empty.

This decision preserves two common ways to organize Linear. A group that puts work into real Projects sees each Project become an independent Fareeqy project. A group using Team as its durable container, with many Issues carrying no Project, sees Team at the top level. You then choose the middle level: Status, Project, Cycle, Assignee, or Priority. A missing value in that grouping column enters a named fallback list instead of creating a blank title that would fail during writing.

When a row carries Parent issue, that child work arrives as an ordinary task inside the resulting list rather than a fourth level beneath its parent. Each row keeps its title, assignee, deadline, and state, which would be lost if it became one line inside Description. The preview names this flattening so the product team knows Parent no longer forms a tree. The behavior is the same whether an Issue had Project or received its project name from Team because flattening happens after the top level is chosen.

The Issue keeps ID or Identifier when the export supplies it, helping the re-import ledger recognize a task that already arrived. Completed, Canceled, and Archived are read as explicit timestamps, so completion does not have to be guessed from a custom Status name. Canceled and archived work stays out by default unless you request its inclusion, and the preview reports its presence. A live Issue without a Project remains part of the migration either way.

When Cycle is the grouping, the importer looks for Cycle Name. If it is blank but Cycle Number exists, it builds a descriptive title such as Cycle 12 rather than creating a list called only 12. The number keeps its meaning and is less likely to collide with an unrelated title. When both name and number are absent, the Issue remains in a clearly named no-cycle list instead of being dropped from the import.

That resulting title is a task list, not a Cycle entity. Issues from the Cycle sit beneath it in CSV appearance order, while Project or Team continues to name the Fareeqy project. The importer does not transfer the Cycle's start and end or recreate Linear's planning cadence. If you group by Status or Assignee instead, no hidden Cycle record appears elsewhere. Your grouping choice explicitly controls which column creates the middle level.

Other useful information stays with the task when the export carries readable text for it. Labels become a named line, Estimate becomes another, and Completed keeps its timestamp when present. Linear's export contains no comments at all, so Cycle names cannot substitute for the discussion on an Issue. Download the CSV and review any Issues that depend on comment context before leaving, then compare the Cycle lists in the preview with the shape your product team recognizes.