Project configuration

This page is for administrators setting up how work is classified and how it moves — issue types, priorities, workflows, custom fields, brands and SLAs.

These settings are instance-wide

Issue types, priorities, statuses and custom fields are shared across the whole instance rather than defined per project. Projects differ through the workflow scheme and the permission scheme applied to them, not through separate copies of every list.

Issue types

Admin → Issue types defines the kinds of work teams can create — Task, Bug, Story, Epic and anything else you need. Each has a colour, an icon, a name, a description and a position in the list, and one is the default.

A type can also be marked as a sub-task type: issues of that type always belong to a parent. That's what keeps decomposition meaningful — see Issues → Parent and sub-tasks.

Priorities

Admin → Priorities manages the priority scale — colour, name, description, order, and which one is the default. Priorities appear on every issue and drive sorting in lists and boards.

Workflow

A workflow is the set of statuses an issue can be in and the transitions allowed between them. This is what stops issues jumping to arbitrary states.

Statuses

Workflow → Statuses defines each status with a name, a colour and — importantly — a category: To Do, In Progress or Done. The category is how the rest of the product reasons about a status it has never seen: boards, reports, the calendar and burndown all use it to tell "not started" from "finished". A status in the wrong category will look right on the board and wrong in every report.

Renaming a status is safe — existing issues keep it.

Schemes

Workflow → Schemes is a named set of statuses and the transitions between them, applied to projects. Different projects can use different schemes.

You can edit a scheme in two views: a matrix of from-status against to-status, and a graph where you drag statuses around and draw transitions between them. The graph is easier to reason about; the matrix is faster once you know what you want.

A default scheme (To Do → In Progress → Done) ships with the product. Change which scheme a project uses from the project's Settings tab.

Custom fields

With the custom fields feature enabled, Admin → Custom fields defines extra fields on issues. Each has a key, a display name, a type — text, number, date, or a select list whose options you provide — and can be marked required.

Required fields are enforced when an issue is created, which is also what makes the Service Desk portal form work: a request type asks the customer for exactly the fields the team needs.

Custom fields also plug into automation: a rule can read a field in a condition and set it in an action.

Profile fields

Separately from issue fields, Admin → Profile fields defines extra fields on people — phone, messenger handle, job title. Each has a key, a name, a type and an optional required flag, and you choose how firmly to ask for them:

• Soft — a reminder banner the person can dismiss for now.
• Hard — they're asked to complete the fields before continuing.

Values are private to each user. See Profile → Additional fields.

Brands

If your organisation ships to multiple brands, Admin → Brands maintains the shared list — colour, name, description, position, default. Brands feed the release features, in particular release waves, whose brand sets and cell statuses are defined under Admin → Wave schemes.

SLAs

With the SLA feature enabled, Admin → SLA defines service-level policies per project:

• Working hours — either 24/7, or working days with a start and end time and a time zone. Timers respect these, so an overnight request doesn't burn its response target while nobody is working.
• Goals — each with a target in minutes and the statuses that start, stop and pause its timer.

Agents see the resulting timers on the request — see Agent guide → SLAs. Note that a breach doesn't notify anyone by itself; use an automation rule if you want an escalation.

Service Desk

Service Desk configuration — request types, queues, customers, approvals, the knowledge base and CSAT — has its own set of pages under Admin → Service Desk. See Agent guide for what each one does in practice.

Project templates

With the templates feature enabled, a project can be saved as a template and new projects created from it in one step, bringing boards, the workflow scheme and starter issues with them. The same feature schedules recurring issues — daily, on weekdays, weekly or monthly.

A template doesn't carry members, permissions or notification settings; set those up on the new project.

Where to go next

• Users & permissions — who can do what.
• Features & settings — turn features on and set global options.
• Automation — rules that act on the fields and statuses defined here.