ACP-120 key terms

The top-level container in Atlassian Administration that holds your sites, users, billing, and security policies. Organization admins manage those settings across every Jira or Confluence site claimed by the company.

The settings area inside a single Jira Cloud site where admins configure projects, users, global permissions, and system options. It affects only that site, while organization-level administration spans all sites owned by the company.

Site-wide permissions granted to groups that control who can administer Jira, create shared objects such as filters and dashboards, and browse users and groups. They apply across all projects and are separate from project permission schemes.

A record of administrative changes and user management events in Jira Cloud, showing what changed, who made the change, and when. Admins use it to investigate configuration problems and meet compliance requirements.

A recovery area in Jira Cloud where deleted issues are held after removal. Site admins can restore them for a limited period of roughly 60 days before they are permanently deleted.

A user account created and verified by an organization admin through a verified company domain. Managed accounts fall under the organization's security policies, such as enforced two-factor authentication and session controls.

A collection of user accounts used to grant access and permissions in bulk. Groups can be created in Jira or synced from an identity provider, and they are referenced by permission schemes, notification schemes, and global permissions.

The group that determines whether a user can use Jira and which Jira apps they can access, such as jira-software-users. Admins assign users to these groups when granting product access.

An identity standard that lets an identity provider automatically create, update, and deactivate Atlassian users and group memberships. It reduces manual user administration and keeps access aligned with the company directory.

A named set of project members, such as Administrators or Developers, defined per project and used by permission and notification schemes. Roles let you grant access to individuals without changing group membership.

A project type whose configuration is controlled by Jira administrators through shared schemes for workflows, fields, screens, permissions, and notifications. It suits teams that need standardized, centrally governed processes across many projects.

A project type that lets the team configure its own workflow, fields, and settings without affecting other projects. Configuration is self-contained, so administrators have limited ability to share schemes with it.

A preset bundle of issue types, workflow, screens, and settings used when creating a new project. Choosing a template determines the starting configuration and the project type you get.

The practice of attaching one scheme, such as a workflow or permission scheme, to multiple company-managed projects. Editing the shared scheme changes behavior in every project that uses it.

A mapping that defines which issue types are available in a project and their order, including which one is the default. Company-managed projects can share one scheme across many projects.

A field added by an administrator to capture information beyond Jira's built-in fields, such as a team name or a target date. Each custom field has a type that determines the kind of data it stores.

The set of projects and issue types where a custom field is available, along with its options and default value. A field can have several contexts so its choices differ by project.

A collection of settings for the fields on an issue, defining whether each field is required or optional and what description it shows. Field configurations are attached to projects through a field configuration scheme.

A mapping that assigns a field configuration to each issue type in a project. It lets different issue types show different required and optional fields within the same project.

A layout that groups fields into tabs for a specific action, such as creating, viewing, or editing an issue. Screens control which fields appear, not whether those fields are required.

A mapping that assigns screens to the create, view, and edit operations for issues. Screen schemes are then assigned to issue types through an issue type screen scheme.

A defined sequence of statuses and the transitions that connect them, describing how an issue moves through its lifecycle. Workflows can include conditions, validators, and post functions that govern each step.

A mapping that assigns a workflow to each issue type in a project. Company-managed projects can share a workflow scheme so that many projects follow the same process.

The movement of an issue from one status to another, or back to the same status, triggered by a user action or by automation. Transitions can carry conditions, validators, and post functions.

A rule on a transition that decides whether a user can see or use it. If the condition is not met, the transition is hidden or disabled for that user.

A check that must pass before a transition completes, such as requiring a field to be filled in. If validation fails, the issue stays in its current status and the user sees an error.

An action that runs automatically after a transition completes, such as updating a field, adding a comment, or creating a sub-task. Post functions run in a defined order.

A set of grants that defines who can do what in a project, such as browsing issues, creating issues, or administering the project. Grants are given to users, groups, project roles, or anyone.

A project-level scheme that defines security levels and who can view issues assigned to each level. It restricts visibility more finely than the browse projects permission does.

A named visibility setting within an issue security scheme, such as Internal Only, with its own list of users, groups, or roles allowed to see issues at that level.

An administrative tool that explains why a given user does or does not have a specific permission in a project, showing the grants and scheme in effect. It speeds up troubleshooting of access problems.

A project-level scheme that decides which events send email notifications and who receives them, using users, groups, project roles, or the issue's reporter and assignee.

A trigger within a notification scheme, such as issue created, issue updated, or issue assigned, that determines when notifications are sent. Each event has its own list of recipients.

A system view that lists outgoing email messages Jira has generated, showing their status and any delivery errors. Admins use it to diagnose why expected notifications were not received.

A no-code rule that runs actions automatically when a trigger event occurs and its conditions match. Rules can be scoped to a project or the whole site and can include branches and smart values.

The event that starts an automation rule, such as an issue being created, a field changing, or a scheduled time. A rule runs only when its trigger fires and its conditions pass.

A section of an automation rule that acts on related issues, such as the parent, sub-tasks, or linked issues, rather than only the issue that fired the trigger.

A placeholder in an automation rule that pulls data from an issue or the rule context, such as {{issue.summary}}, so actions can use dynamic values. Smart values also support text and date formatting functions.

An operation that edits many issues at once from the issue navigator, such as moving, transitioning, or updating fields. Bulk change requires the appropriate permission and is limited to a maximum number of issues.