Import & export
Export tasks as CSV, Excel and PDF; create and update tasks in bulk from a spreadsheet.
You export tasks from the menu above the list view, and create tasks in bulk from a file in the same place. The two directions match: you can export a file, edit it in a spreadsheet and load it back.
Export
| Format | What you get | When |
|---|---|---|
| CSV | EVERY field of the task, regardless of which columns are visible on screen. | Moving to another system, keeping a copy, bulk editing in a spreadsheet and loading it back. |
| Excel | The same scope as CSV, as a ready-formatted sheet. | When you will work in a spreadsheet; column widths and headers arrive ready. |
| Only the columns currently VISIBLE on screen. | A report to print or share. Twenty columns do not fit a page, so the column selection is deliberately respected here. |
In all three formats the filter and sort on screen decide which tasks are included. Open a saved filter and export, and the file holds exactly that result set.
CSV and Excel carrying every field is a matter of round-tripping: the description was not a list column, so it never reached the file, yet import recognised a "Description" column. Loading your own exported file back therefore wiped descriptions silently. The same gap existed for start date, sprint, versions, class of service, reporter, parent task and every custom field.
Columns recognized on import
Columns are mapped on the server. Built-in fields match by their header, sprints and versions by NAME, class of service by its label. A column that matches no built-in field is mapped against the board’s custom field names, so there is no separate mapping screen for custom field columns: matching the name is enough.
| Column | How it is matched |
|---|---|
| Title | The only required field. A row without it is not imported. |
| Task id | If it already exists on the board the row is skipped; with "update existing" ticked, that task is updated instead. |
| Description | Taken as text. |
| Status | Matched by status NAME. When empty, the task lands in the first status of the workflow. |
| Priority | Looked up by both its value and its visible label. |
| Assignee · Reporter | A person’s name or email address. |
| Labels | Comma separated, up to 20 labels per row. |
| Due date · Start date | An unreadable date does not drop the row: the task is created, the field stays empty, and that value is reported separately in the result. |
| Issue type | Matched against the board’s issue type names. |
| Sprint | Matched by sprint NAME. |
| Fix version · Affects version | Matched by version name. |
| Class of service | Matched by its label. |
| Parent task | The link is built in a SECOND pass, so the parent may appear further down the file. Parents that cannot be linked are reported by name; the task is still created, only the hierarchy is not. |
| Custom fields | The column header is matched against the board’s custom field name or key; on select fields the option label is recognized too. |
Preview and choosing rows
- 1Upload the file. Every row is listed in the preview, not just a sample.
- 2Untick the rows you do not want; "select all" toggles them together. You do not need to split the file by hand to drop one unwanted row.
- 3Rows whose id already exists on the board are marked "already exists" and come in UNTICKED. You can select them again if you want.
- 4If you want to update existing tasks, tick the "update existing records" box.
- 5Import. The result screen tells you how many tasks were created, how many updated, how many rows were skipped and what could not be matched.
Updating existing records is powerful but needs care, which is why you have to tick it deliberately: a single stale cell in your file can silently overwrite a change someone made in the meantime. An update only touches the fields present in the file.
Statuses, assignees, labels, issue types, priorities, sprints, versions, custom fields and parents that could not be matched are reported BY NAME; the row is not silently dropped and the value is not silently swallowed. You never walk away thinking you assigned work that was never assigned.
A single import handles at most 500 rows; split a larger migration into parts. Section fill-in rules apply to imports as well: filling a field in a section you are not allowed to fill is rejected here too.