Jira words used in these guides
Plain-language definitions of the Atlassian terms that appear throughout, including who is allowed to do what.
You do not need to memorise this page. Come back to it when a word in another page is unfamiliar.
The basics
- Issue
- One record in Jira: a task, a bug, a support ticket. Everything in Jira hangs off issues.
- Issue key
- The short identifier of an issue, like
OPS-4412.OPSis the project,4412is the number. - Project
- A container for issues, with its own key, its own people and its own configuration.
- Company-managed vs team-managed project
- Two kinds of Jira project. Company-managed projects share configuration (fields, workflows, schemes) across the site and are administered centrally. Team-managed projects keep their configuration to themselves and are simpler. Some app features only work in company-managed projects, because only those expose the configuration the feature needs. Your project's type is shown in Jira's project list.
- Field
- One piece of information on an issue: summary, assignee, priority. Jira ships many; you can create your own.
- Custom field
- A field you or an administrator created. Our Custom Fields Toolkit adds new types of custom field that Jira does not offer.
- Field ID
- The internal name of a custom field, like
customfield_10016. Jira uses it in queries and rules. You can see it in the URL when you edit the field.
Configuration words
- Field context
- The settings of one field for a specific set of projects and issue types. One field can have several contexts, which is why the same field can behave differently in two projects. When a guide says “configuration is per context”, it means: check which context covers the project you are looking at.
- Screen
- The list of fields shown when you create, edit or view an issue. A field only appears if it is on the screen.
- Scheme
- A reusable bundle of configuration that projects share. There are workflow schemes, permission schemes, notification schemes, screen schemes, field configuration schemes and issue type schemes. Sharing one scheme across ten projects is good. Having 200 schemes that nobody can account for is what our cleanup tools are for.
- Workflow
- The set of statuses an issue moves through, and the allowed moves between them.
- Transition
- One move between two statuses, such as In Progress → Done. The button a user clicks is a transition.
- Condition, validator, post function
- Three things you can attach to a transition. A condition decides whether the button is shown at all. A validator checks the issue when the user clicks and can refuse with a message. A post function runs after the move succeeds. Our Workflow Toolkit adds one of each.
- JQL
- Jira Query Language: the search syntax, like
project = OPS AND status != Done. If you can build a filter in Jira's issue search, you can write JQL, because Jira shows you the query it built.
Service desk words
- Jira Service Management (JSM)
- The Atlassian product for support and service teams. It adds a customer-facing side to Jira.
- Service desk
- One JSM project seen from the service side: its queues, its agents, its customers.
- Portal
- The simplified website your customers use to raise and follow requests. They never see Jira itself.
- Request type
- One option in the portal, such as “Report a hardware problem”. It maps to an issue type and decides which fields the customer fills in.
- Agent
- A licensed JSM user who works on requests. Customers are not agents and do not consume an agent licence.
Who is allowed to do what
This is the single biggest source of “the app is not working”. Four different roles get called “admin”, and they are not the same thing.
| Role | Where it comes from | What it can do |
|---|---|---|
| Project administrator | The Administer projects permission in one project | Change that project's own settings. Cannot create fields or edit schemes. |
| Jira administrator | The Administer Jira global permission | Create fields, edit workflows and schemes, open our apps' admin pages. This is the role most of these guides assume. |
| Site administrator | Admin of the Atlassian site | Everything a Jira admin can do, plus manage users and group membership. Some operations, such as adding somebody to a group, are refused for anyone else. |
| Organization administrator | admin.atlassian.com | Manages the whole organisation: all sites, all users, billing, API keys, and suspending accounts. Needed by License Waste Manager and by AI Triage's team routing. |
Check this before you blame the app
If an app reports that a change was refused, read the message: it usually names the permission you are missing. Group changes and account suspension in particular are blocked by Atlassian for anyone below site or organisation admin, and no app can work around that.
Words about our apps
- Atlassian Forge
- Atlassian's platform for building apps that run inside Atlassian's own cloud. All our apps are Forge apps. There is no server of ours in the picture, which is why installation never asks you to open a firewall or hand over credentials.
- Scope
- A permission the app declares, like
read:jira-work. Atlassian shows you the list when you install, and the app can do nothing outside it. Each app's reference page explains why every scope is needed. - App storage
- Where a Forge app keeps its own data, inside your Atlassian site. When you uninstall the app, this is deleted.
- Forge LLM
- Atlassian's built-in AI service, using models Atlassian hosts. Our AI features use it. You do not buy an API key, and your data does not go to an outside AI provider.
- Web trigger
- A private URL that lets your own tools talk to an app. Only AI Portal Chat uses one, and only if you generate a token for it.
Next: installing one of our apps.