ACP-620 key terms

A reusable set of grants that decides which users, groups, project roles, or issue security levels may perform specific actions such as browsing, editing, or transitioning issues within a project.

A project-scoped membership container, such as Administrators or Developers, to which users and groups are added; permission schemes and notifications reference roles instead of individuals so membership stays portable across projects.

A system-wide authorization, granted through a global permission entry, that controls abilities like administering Jira, creating projects, or using the shared Jira user base across all projects.

A per-issue visibility setting defined in an issue security scheme; only users matching the level's members can view the issue, which lets teams restrict sensitive tickets inside a project they otherwise share.

A project-associated collection of security levels and their members, assigned per project and applied to individual issues through the Security Level field to limit who can see those issues.

A directory-level collection of user accounts managed centrally by a Jira administrator or an external directory; groups can be granted permissions, added to project roles, and referenced in notifications and filters.

The association between a user or group and a project role within a specific project; role membership determines who receives role-based permissions, notifications, and dashboard sharing in that project.

An ordered set of statuses connected by transitions that defines the lifecycle of an issue type in a project, including the conditions, validators, and post functions that run as issues move between statuses.

A directed link between two statuses in a workflow, optionally carrying a trigger, conditions, validators, and post functions; users invoke transitions through buttons or automation to advance an issue.

A workflow element evaluated before a transition is offered or executed; if the condition returns false, the transition is hidden or blocked, controlling who may perform it and when.

A workflow element that checks input during a transition and blocks completion when the check fails, for example requiring a resolution or a non-empty custom field before an issue can be closed.

An automated action executed during a transition after validators pass, such as setting a field, assigning the issue, adding a comment, or firing an event that triggers notifications.

A project-level mapping that assigns issue types to workflows, with an optional default workflow for unmapped types; changing it can require a migration of existing issues to new statuses.

A named state an issue occupies within a workflow, such as In Progress or Done; statuses drive boards, filters, and reports, and their category determines how they appear in agile views.

A fixed classification (To Do, In Progress, Done) applied to statuses so that reports, boards, and gadgets can group statuses consistently even when projects use different status names.

A project association that defines which issue types are available and in what order they appear; it controls the options users see when creating issues in that project.

A project mapping that links issue types to field configurations, determining for each field whether it is visible, required, or has a rendered description in that project context.

A named collection of field behavior settings, such as hidden, required, or optional, applied through a field configuration scheme to control how fields behave on issues of mapped types.

A mapping of issue operations (create, view, edit) to screens, associated with a project through an issue type screen scheme so each operation shows the appropriate fields.

The configuration scope of a custom field that determines which projects and issue types the field applies to, along with its options and default value; multiple contexts allow one field to behave differently per project.

An administrator-defined field, such as a select list, date, or number, added to Jira to capture data beyond built-in fields; it requires a type, context, screens, and often configuration in field configurations.

A configured trigger-condition-action sequence in Jira Automation that reacts to events like issue creation or scheduled times to update issues, send notifications, or call external services.

The starting event of an automation rule, such as issue created, field changed, or a scheduled interval; the trigger determines which issues enter the rule and when its conditions are evaluated.

A placeholder expression in Jira Automation, written with double braces, that resolves to issue fields, user data, or computed values so rules can reference dynamic content in actions and conditions.

A named occurrence in Jira, such as issue created or issue transitioned, that notification schemes and listeners consume; workflows fire events via post functions to drive notifications and integrations.

A project-level mapping from events to recipients, such as a project role or a custom field user, that determines who receives email notifications when those events occur on issues.

A named relationship between two issues, such as blocks or relates to, with forward and reverse descriptions; link types define how issues reference each other and how dependency reports interpret them.

The HTTP interface exposing Jira resources for issues, projects, users, and configuration; integrations and scripts authenticate with tokens or OAuth and exchange JSON representations to read or modify data.

An outbound HTTP callback configured in Jira that posts a JSON payload to a URL when selected events occur, enabling external systems to react to issue changes in near real time.

A trusted connection between Jira and another Atlassian application, such as Confluence or Bitbucket, that enables shared authentication and cross-application features like issue macros and development panels.

A bulk data-loading process that maps columns from a comma-separated file to Jira fields and creates or updates issues, requiring careful mapping of issue type, project, and user fields.

A Jira administration feature that migrates data from other trackers or backup files by mapping external entities to Jira projects, issue types, statuses, and users before running the import.

A maintenance operation that rebuilds the search index from database content, required after certain configuration changes or imports so JQL and search results reflect current data.

Jira Query Language, a structured text syntax for searching issues by fields, values, functions, and operators; saved JQL filters drive boards, dashboards, subscriptions, and automation conditions.

A saved JQL query that can be shared with users, groups, or projects and reused by boards, gadgets, dashboards, and subscriptions to define which issues appear.

A preset bundle of schemes, workflows, and settings applied when creating a project, such as Scrum or Kanban software templates, which determines the initial configuration a new project inherits.

A reusable configuration object, such as a permission, notification, workflow, or issue type scheme, that is shared across projects; changing a shared scheme affects every project that references it.

A label grouping projects for browsing and filtering in the project directory and some gadgets; it has no effect on permissions or configuration and is purely organizational.

A classification of work items, such as Bug, Task, or Epic, that determines the workflow, fields, and screens applied to an issue and drives reporting and board behavior.

A configured source of user and group data, such as Jira's internal directory or an LDAP connection, that Jira queries for authentication and membership; directory order controls which record wins.

A record of administrative configuration changes and, in some deployments, user activity, used to trace who changed schemes, workflows, or permissions and when the change occurred.