Documentation for JIRA 4.4. Documentation for other versions of JIRA is available too.

Skip to end of metadata
Go to start of metadata
Gliffy Zoom Zoom

Creating a Project

To add a new project in JIRA:

  1. Log in as a user with the 'JIRA Administrators' global permission.
  2. Click the 'Administration' link at the top of the screen.
  3. Select 'Projects' > 'Projects' then click 'Add Project' to display the 'Add Project' screen (see Screenshot 2 below).
    • Name — type a descriptive name. This can be changed later if you wish.
    • Key — type a 'key' unique to this project (eg. 'WEB'). This will be used as the prefix of this project's issue keys (e.g. 'WEB-100'). We recommend that you define a key that describes the project and is easy to type. Please note that the key cannot be changed once the project is created.
    • Project Lead — choose the person who will manage this project. You can change the Project Lead later if you wish. Note that issues can be automatically assigned to the Project Lead (see 'People' below).
      (info) If there is only one user in your JIRA system, the Project Lead will default to that person and this field will not be available.
  4. Once created, the 'Project Summary' screen for your new project will be displayed (see Screenshot 1 below). You can then configure other details of your project as described below.

    Here is what a project looks like once created:

    Screenshot 1: Project Summary

    (View full size)

    Screenshot 2: Add Project

On this page:

Configuring a Project

To configure a project in JIRA:

  1. Log in as a user with the 'JIRA Administrators' global permission.
  2. Click the 'Administration' link at the top of the screen.
  3. Click 'Projects' and select the project of interest. The 'Project Summary' screen will be displayed (see Screenshot 1 above).
    (tick) Keyboard shortcut: 'g' + 'g' + start typing 'project'

You can then edit the project's configuration settings as follows:

Project Details

  • Name — type a descriptive name. This can be changed later if you wish.
  • URL — an optional URL associated with this project, eg. pointing to project documentation.
  • Project Avatar — an image (48x48 pixels) that represents the project. You can either use the default image, i.e.:

    or choose a different image. If you prefer not to use an image, simply upload a transparent pixel.
  • Description — an optional description of this particular project. You can include HTML, but make sure all your tags are closed.
    (minus) Warning: Please be aware that this is completely unfiltered HTML and as such, it is susceptible to cross site scripting attacks.

(info) Click the link next to the 'Category' field under the project name to assign the project into a logical category/group. This is useful for managing multiple related projects. If no categories exist, click the 'Add' link on the following page to add a new category. New categories can also be created via 'Administration' > 'Projects' > 'Project Categories'.

Issue Types

JIRA enables you to keep track of different types of things — bugs, tasks, helpdesk tickets, etc — by using different issue types. You can also configure each issue type to act differently, e.g. to follow a different process flow or track different pieces of information.


Your JIRA issues can follow a process that mirrors your team's practices. A workflow defines the sequence of steps (or statuses) that an issue will follow, e.g. Open, In Progress, Resolved. You can configure how issues will transition between statuses, e.g. who can transition them, under what conditions, and which screen will be displayed for each transition.

  • Workflow Scheme — the project's workflow scheme determines which workflows (issue state transitions) apply to issue types in this project.


JIRA allows you to display particular pieces of issue information at particular times, by defining screens. A screen is simply a collection of fields. You can choose which screen to display when an issue is being created, viewed, edited, or transitioned through a particular step in a workflow.

  • Screen Scheme — the project's screen scheme determines which screens are displayed for different issue operations (view, edit, create);
    Issue Type Screen Scheme — the project's issue type screen scheme determines which screens are displayed for different issue operations (view, edit, create), for different issue types.


JIRA enables you to define field behaviour: each field can be required/optional, rich text/plain text, hidden/visible. You define this behaviour by using a field configuration.



Different people may play different roles in different projects — the same person may be a leader of one project but an observer of another project. JIRA enables you to allocate particular people to specific roles in your project.

  • Project Lead — user fulfilling the role of project leader. Used as the 'Default Assignee' (see below), and potentially elsewhere in JIRA (e.g. in permission schemes, notification schemes, issue security schemes and workflows).
  • Default Assignee — the user to whom issues in this project are initially assigned when created. Can be either the 'Project Lead' (above), or, if Allow unassigned issues is set to 'On' in JIRA's general configuration, 'Unassigned'. There are also default component assignees.
  • Project Roles — members are users/groups who fulfil particular functions for this project. Project roles are used in permission schemes, notification schemes, issue security schemes and workflows.


If you are using JIRA to manage the development of a product, you may want to define different versions to help you track which issues relate to different releases of your product (e.g. 1.0, 1.1, 1.2, 2.0 beta, 2.0). JIRA can help you manage, release and archive your versions. Versions can also have a Release Date, and will automatically be highlighted as "overdue" if the version is unreleased when this date passes.

  • Versions — versions defined in the project. See the version management page for details.


You may want to define various components to categorise and manage different issues. For a software development project, for example, you might define components called "Database", "Usability", "Documentation" (note that issues can belong to more than one component). You can choose a Default Assignee for each component, which is useful if you have different people leading different sub-teams in your project.

  • Components — logical groups that this project's issues can belong to. See the component management page for details.


JIRA allows you to control who can access your project, and exactly what they can do (e.g. "Work on Issues", "Comment on Issues", "Assign Issues"), by using project permissions. You can also control access to individual issues by using security levels. You can choose to grant access to specific users, or groups, or roles (note that roles are often the easiest to manage).


JIRA can notify the appropriate people when a particular event occurs in your project (e.g. "Issue Created", "Issue Resolved"). You can choose specific people, or groups, or roles to receive email notifications when different events occur. (Note that roles are often the easiest to manage.)

  • Notification Scheme — the project's notification scheme determines who receives email notifications of changes to issues in this project.
  • Email — specifies the 'From' address for emails sent from this project. Only available if an SMTP email server has been configured in JIRA.

A note about Project Administrators

A JIRA project administrator is someone who has the project-specific 'Administer Project' permission, but not necessarily the global 'JIRA Administrator' permission.

A project administrator can:

  • No labels