Skip to content

Project settings

Project settings are where a project administrator shapes one project: its details, its parts, which views it offers and its life cycle. Site administrators also archive, trash and restore projects.

Workflows, custom fields, screens and schemes are also set here. They are covered in Workflows and Custom fields, screens and schemes. Who may change them depends on whether the project is team-managed or company-managed, which you choose once when you create it.

Setting Rule
Name The project’s name
Key 2 to 10 uppercase letters or digits, starting with a letter, and unique. Ordinary edits never change it.
Lead The creator at first. Later the lead can be any active member with the administrator or member role.
Description Up to 4,000 characters
Category 1 to 60 characters. The project directory groups by it.
Icon and colour An icon from a fixed set, and a colour such as #6554c0
Default assignee Unassigned (the default) or the project lead

With the lead as default assignee, new work created without an assignee goes to the lead. This holds while the lead can still work in the project.

A component divides a project into parts. Its name is unique in the project, ignoring case, and has up to 120 characters. It can have a description and a lead who can work in the project.

The assignee type decides who gets new work: project default, component lead, project lead or unassigned. A work item can have several components. When it is created without an assignee, Orbit looks at its components in name order. The first one whose assignee type is not the project default decides. Otherwise the project’s default assignee applies.

A project administrator can delete a component that work still uses. You choose between moving that work to another component and removing the component from it.

A version is a release of the project. It is unreleased, released or archived, and it can have a release date.

  • Release a version. Work that is not yet done can move to another version. You can also unrelease it.
  • Archive and unarchive a version.
  • Merge one version into another. The source is deleted and its work moves.
  • Delete a version after moving its work to another version or removing the version from that work. A version in use cannot be deleted otherwise.
  • Order the versions.

Merging, deleting and ordering need a project administrator. A target must be another version of the same project that is not archived.

Project administrators decide what the project offers, for everyone in it.

  • Features. Switch backlog, timeline, calendar, reports, releases, components, Folio, Forge and Pulse on or off. Everything is on by default.
  • Navigation order. Order summary, board, backlog, work items, timeline, calendar, reports and Folio.
  • Default view. The view the project opens on. It must be one that is turned on.
  • Shortcuts. Up to 12 links, each with a name of 1 to 60 characters and an address. The address is an http or https address without credentials, or a path on your site.

Templates and recurring work live in the project settings.

  • Templates. Create a work item from a template, which opens in the side panel, or delete a template. From a work item’s menu you can save it as a template, private to you or shared with the project.
  • Recurring work. Create work on a schedule: daily, weekly on chosen days or monthly, every N periods, at a local time in a time zone you pick. You can pause, resume and delete a schedule. The server runs the schedules, avoids duplicates and is tested across time zones.

Only site administrators can change a project’s life cycle. Every step is audited.

  1. Archive. The project becomes read-only for everyone. Members can still read it, and the directory and project switcher mark it.

  2. Move to the trash. This is allowed when nothing blocks it. Archived or restricted work, and links from other projects’ work, are blockers. A trashed project and its work disappear from every list, search and read, for site administrators too. Orbit first lists the boards, filters, rules, shared forms and links that the change affects.

  3. Restore. From the archive or the trash, a project returns to active. Restoring from the trash does not return it to the archive.

  4. Delete permanently. From the trash, or when the retention period ends.

The retention period is set for the site, from 1 to 365 days, and is 60 days by default. It is fixed for each project when it moves to the trash, so a later change applies only to projects moved afterwards.

While a project is archived or trashed, writes to its work, settings, versions, components, sprints and forms are refused with 409 project_archived or project_in_trash.

Renaming a key is a reviewed, two-step action. A site administrator renames the key of a company-managed project, and a project administrator renames the key of a team-managed project. You must be able to read every work item, archived ones included.

  1. Enter the new key. Orbit shows how many work items change, plus any blockers and warnings.
  2. Confirm. If the work items or the project changed in the meantime, you review again (409 project_key_rename_stale).

Project and work item ids, numbers, hierarchy and numbering stay. Old project keys stay reserved for good, and existing work item keys become aliases that still work. Old keys also resolve in JQL, in search suggestions and in CSV imports.

Project roles are administrator, member and viewer, for people and for groups. A person’s role is the strongest of their own and their groups’ roles. On the project’s people page, administrators pick a person, and optionally a work item. They see each permission allowed or refused, with the reason. See Invite people and set roles.