## Where reports are configured

Reports are defined for a specific issue type: **Configuration → Issue types → [type] → Reports**. A report always returns issues of that one type — create a separate report for another type.

The report list for a type shows the report name together with its schedules and versions, the description and the PDF orientation. The menu next to each report lets you edit it, go to its field configuration or delete it.

## Creating a report

The **Add report** button opens a panel with the settings:

| Field | Description |
| --- | --- |
| **Report name** | Visible to users in the report list; also used as the file name and sheet name in exports (up to 255 characters) |
| **Description** | A short explanation of what the report shows (up to 500 characters) |
| **PDF orientation** | Portrait or landscape — affects PDF export only |

{% callout type="note" title="Landscape for wide reports" %}
A report with many columns can be unreadable in a portrait PDF. With more than a few columns choose landscape orientation, or limit the number of columns and use XLS export.
{% /callout %}

The number of reports in an account may be limited by your plan. Once the limit is reached the **Add report** button is disabled and the maximum number of reports is shown underneath.

## Report columns

A newly created report has no columns — until you add them, users see a warning instead of the results table.

Columns are configured from the report menu → **Report fields**. This works exactly like application fields in other modules (see [Application fields](/config/appfields)): you add a field, set its name, display order and report-specific options.

A report can contain:

- **system issue fields** — including internal number, external number, order number, creation date, income date, finish date, close date, purchase date, step finish date, customer, distributor, service, products, category, step, status, priority, channel, owner, creator, last editor, description, comments, cost, days, working days,
- **custom fields** defined for the given issue type.

{% callout type="note" title="Days and working days" %}
The **days** column is the number of days since the issue was received (or created) — counted to the close date for closed issues and to today for open ones. The **working days** column is calculated the same way but skips weekends.
{% /callout %}

### Report options of a field

The configuration of a field added to a report has a **Report options** tab:

- **Filtering** — whether users may filter the report by this field. Only fields with this option enabled appear in the filter builder
- **Hide column** — the field stays in the report configuration but is not shown in the table or in exports
- **Sorting** — whether the report should be sorted by this field
- **Sort direction** — ascending or descending

Column order in the table and in the file follows the **display order** of the fields. The same order determines sorting priority when sorting is enabled on several fields. If no field has sorting enabled, results are sorted by issue creation date, newest first.

A column header can be overridden at the report field level — useful when the system field name differs from the header the recipient of the listing expects.

## Schedules and versions

Underneath the report name in the list you can see the attached:

- **Schedules** — recurring generation and e-mail delivery (see [Report schedules](/reports/schedules)). Clicking the name opens editing, the bin icon deletes the schedule
- **Versions** — saved filter sets (see [Reports](/reports)). They can be deleted from here

Both schedules and versions are created by users from the report results screen — the issue type configuration is where they are reviewed, edited and deleted.

## Permissions

Access to reports is controlled by permissions assigned to groups (**Administration → Groups & permissions**):

| Area | Permissions |
| --- | --- |
| Reports | browse, create, edit, delete and execute reports |
| Schedules | browse, create, edit, delete |
| Versions | browse, create, edit, delete |

The **execute** permission gives access to the **Reports** menu, running reports, exporting and the downloads list. The remaining permissions cover configuration and are normally granted to administrators.

{% callout type="warning" title="Reports and organisation scope" %}
A report does not bypass data permissions. Whatever its configuration, a user only sees issues from the organisations they have access to.
{% /callout %}

## Deleting a report

Deleting a report is irreversible and removes all of its schedules, versions and column configuration. Issues and their data are untouched — a report is only a way of presenting data.

---

## FAQ

### Can one report cover several issue types?
No. A report belongs to a single issue type. Create a separate report with its own columns for another type.

### Why does a user see a message that the report has no fields?
No column has been added to the report yet. Go to the report menu → **Report fields** and add fields.

### How do I make a report available only to selected people?
Through group permissions — access to the reports module is granted at group level. The scope of visible data is further limited by the user's organisation assignment.

### Can a field hidden in the report still be used for filtering?
Yes. Hiding affects presentation only — a field with filtering enabled still appears in the filter builder.

### Does changing the report configuration affect existing schedules?
Yes. Schedules store only the filters; the set of columns and the sorting are taken from the current report configuration on every run.

### How many reports can be created?
It depends on your plan. Once the limit is reached the add button is disabled and the maximum number of reports is shown.