Import

Quevell imports CSV, not "data from one particular tracker": any tool that exports a table can be a source. An import goes into one project and is open to anybody who can create issues there.

Two phases#

Every import goes through two phases of the same mechanism:

1. Preview: the file is parsed and validated in full, and nothing is written. You see how the columns were recognized, how many rows are ready to import, and what is wrong with the rest.
2. Apply: the file is validated again and written in one transaction. Either the whole file lands, or nothing is written and an error report comes back.

In practice that means there is no such thing as a half-imported file. An error can be fixed in the source file as many times as you like, with nothing to clean up after the earlier attempts.

Every issue created this way goes through the same checks as one created by hand: permissions, field validation, hierarchy rules. An import cannot put data into a state a user could not put it in. Automation rules do not fire on imported rows: a thousand rules set off by one file is of use to nobody.

The file format#

• Encoding: UTF-8, BOM included. A file that does not read as strict UTF-8 is read as windows-1251, the encoding exports from older tools carry. The encoding that was recognized is named in the preview report.
• Delimiter: semicolon, comma or tab. Detected from the header line: the candidate that yields the most columns wins.
• Quoting: RFC 4180. A cell in double quotes may hold the delimiter, line breaks and doubled quotes.
• The first line: the column names. Mandatory.
• Limits: up to 5000 rows in one file, and up to the size the company sets (5 MB by default, from 1 to 10 MB in whole megabytes).

Columns#

Columns are recognized by name, in English and in Russian. The one mandatory column is the summary (Summary, Название, Тема). A description column is needed in practice too: a description is mandatory in Quevell, and a row without one is not imported and goes into the report.

A column whose header matches the name of a project's custom field writes into that field. An unrecognized column is ignored and marked so in the report. When two headers claim one target, the first column wins and the second is marked as ignored.

When automatic recognition is not the right answer, the mapping is set explicitly in the import dialog: which column goes where, "nowhere" included. The format of those instructions is stable and versioned (version: 1), so they can be kept in a migration playbook and sent through the API; in the import dialog the mapping is set afresh for each file.

Values#

Statuses, types and select options are recognized by any of their spellings: the key, the default name, and every translation. A value written the way the interface shows it resolves whatever the language.

• Priority: Highest, High, Medium, Low, Lowest, their Russian equivalents (критический, высокий, средний, низкий, минимальный), and also Blocker and Trivial.
• Users: by name or by email address. The address is the dependable spelling: when two users in the company share a name, the row that gives the name is rejected and the report asks for the address.
• Created dates: 2026-08-24, 24.08.2026, ISO timestamps, and 24.08.2026 18:30.
• Estimates: in the time-tracking form, such as 1w 2d 4h 30m, where 1w = 5 days and 1d = 8 hours. A remaining estimate with no explicit value equals the original: nothing is spent yet.
• Select fields: the value must be one of the field's options. Several values for a multi-select go on separate lines inside one cell.

Unknown values#

A row with an unknown status, type, priority or option is not imported: silently creating an issue with "roughly that" value is worse than naming the row and the value. The report gathers such values into a summary: not three hundred errors saying "there is no status Wait", but one line saying Wait, 300 rows, with a list of what the project does have. In the import dialog such a value can be mapped onto an existing one without editing the file.

Hierarchy#

Hierarchy travels in two columns: key in the file and parent. A parent may point at the key of a row in the same file, or at an issue that already exists in Quevell.

• Keys inside the file come first: if a key repeats an existing issue, the parent is taken to be the row in the file. That is what lets an export with its old keys be imported again.
• A parent must sit exactly one level above its child in the type hierarchy, as it does when issues are created by hand.
• Rows are written parents before children, whatever their order in the file.
• When a parent row is rejected, its children are rejected with a message pointing at it, not with a puzzling "parent not found".

Once every row is written, issue references in custom fields of the "issue" kind that point at keys from the same file are rewritten to the new keys: numbering belongs to the receiving project and is known only after the write happens. The report returns the old key to new key mapping, for rewriting the references in the old tool.

The report#

Both phases return the same report: the encoding, the delimiter, how each column was recognized, the number of rows, the number ready to import, per-row errors with their numbers and reasons, and the summary of unknown values. After the write, the report also lists the issues created, with their new keys.

An example file#

The file below can be copied, saved as import.csv and uploaded without changes. The delimiter is a semicolon.

Key;Summary;Description;Type;Status;Priority;Assignee;Parent;Estimate
EPIC-1;Office move;Everything about moving the team to the new office;Epic;In progress;High;;;
T-1;Collect requirements;Ask the teams what they need: desks, meeting rooms, a server room;Task;Done;High;anna@example.com;EPIC-1;2d
T-2;Choose the space;Visit the three shortlisted addresses and compare against the checklist;Task;In progress;Medium;anna@example.com;EPIC-1;1w
T-3;Arrange moving the hardware;Packing, insurance, the mover, acceptance on site;Task;To do;Medium;;EPIC-1;3d 4h

The type and status names in the example must exist in your project; if yours are named differently, rename them in the file or map them in the import dialog.

A ZIP archive with the attachments#

Issues can come with their files: a ZIP archive holding an issues.csv file and the attachments. The issues.csv file is read by the same rules as a plain CSV. The archive may weigh up to 512 MB, each file in it up to 10 MB. The archive is checked and imported in the background, and the result arrives in the inbox.

How a file finds its issue#

An issue's old key comes from the Key (or Ключ) column of issues.csv. A file finds its issue in any of three ways, and the product works out which one the archive uses.

A folder per issue, named by the old key:

issues.csv
attachments/OLD-123/screenshot.png
attachments/OLD-124/spec.pdf

A flat pile of files with the old key at the start of the name:

issues.csv
OLD-123 screenshot.png
OLD-124_spec.pdf

An Attachments (or Вложения) column in issues.csv with paths inside the archive, one per line of the cell or separated by semicolons:

Key;Summary;Description;Attachments
OLD-123;Save button;Does nothing;docs/screenshot.png

The key at the start of a file name comes off when the file is attached: OLD-123 screenshot.png is attached as screenshot.png.

The trial run#

Before the import, a table shows which file goes to which issue and how it was found. Errors stop the import:

• issues.csv names a file the archive lacks;
• a file is larger than 10 MB;
• the files take more space than the company has left;
• a row of issues.csv has an error, as in a plain CSV import.

Warnings let the import go on only with your consent: a file that matched nothing, and an empty file, stay in the archive. A person the company lacks leaves the assignee or reporter field empty and is listed among the warnings too.

The old key#

The old key is kept on the issue and search finds it: OLD-123 in the search box finds the issue Quevell gave its own key. Loading the same archive again creates nothing twice: a row whose old key the project already has is skipped and listed in the report.

From Quevell to Quevell#

The "Export ZIP" button in the issue search builds an archive in this very format: issues.csv with an Attachments column, issues.json with every field, the comments, the links and the history, and an attachments folder with the files. Such an archive imports into another project or another company as it is.