ACP-420 cheat sheet

Company-managed projects store their configuration in shared schemes (issue types, workflow, fields, permissions); team-managed projects keep an independent configuration inside the project itself.

The project key forms the prefix of every issue key (for example ABC-123), must be unique across the site, and is limited to uppercase alphanumeric characters.

Company-managed projects set a default assignee to either the project lead or Unassigned; the project lead is also typically placed in the Administrators project role.

A project can belong to at most one project category; categories are used to group projects in the project directory and when sharing filters and dashboards.

Creating, editing, and deleting issues inside a project requires the project permission set, but changing project configuration requires the Administer Projects permission.

Archiving a project makes it read-only and removes it from active project lists; an administrator can restore it later without data loss.

Deleting a project moves it to the trash, and an administrator can restore it within the retention window (60 days in Jira Cloud).

Moving an issue to another project succeeds only when the target project's issue type scheme contains a matching issue type and the target workflow contains the issue's current status.

Team-managed projects expose feature toggles (backlog, sprints, releases, reports, estimations) that are enabled or disabled per project instead of through shared schemes.

An issue type scheme lists the issue types available to a company-managed project and designates exactly one of them as the default issue type.

The default issue type in a scheme is the type preselected in the Create issue dialog and is also used when an issue is created without an explicit type.

Issue types are defined once at the site level; the issue type scheme only controls which of them appear in a given project.

Issue type hierarchy levels are Epic (level 1), standard issue types (level 0), and subtasks (level -1); Jira Cloud also allows one configurable level above Epic.

A subtask issue type can never be the parent of another issue and appears only as a child of a standard issue type.

An issue type scheme that is assigned to a project cannot be deleted; the project must be reassigned to a different scheme first.

The order of issue types inside an issue type scheme determines their order in the Create dialog and in type dropdowns.

An issue type that already has issues cannot simply be deleted; the existing issues must be migrated to another issue type first.

Each issue type can be mapped to a different workflow and a different screen scheme, which is how one project can run several distinct processes.

A workflow consists of statuses joined by transitions; each transition can carry conditions (who may execute), validators (what must be true), and post functions (what happens afterwards).

Editing a published workflow requires creating a draft; changes have no effect on issues until the draft is published, and the draft can be discarded instead.

A workflow scheme maps each issue type to a workflow and names one default workflow used for any issue type not explicitly mapped.

A global transition is available from every status in the workflow rather than from one specific origin status.

Status categories (To Do, In Progress, Done) drive board column mapping and report calculations such as burndown and velocity.

Post functions such as setting the issue status to the linked status, updating the change history, and reindexing the issue are added automatically by Jira.

When a workflow is replaced, any status present on existing issues but absent from the new workflow must be mapped to a valid destination status during migration.

A shared workflow is used by multiple workflow schemes, so editing and publishing it changes behaviour in every project that references it.

A workflow scheme assigned to a project cannot be deleted until every project using it has been reassigned.

A field configuration sets, per field, whether it is shown or hidden and whether it is required or optional for the issue types mapped to that configuration.

A single field cannot be both hidden and required in the same field configuration.

A field configuration scheme maps issue types to field configurations and defines one default configuration for unmapped issue types.

A screen scheme maps the Create, Edit, and View operations to specific screens; an issue type screen scheme then assigns that screen scheme to issue types.

A field is visible on an issue only if it appears on the applicable screen, is not hidden in the applicable field configuration, and its context includes the project and issue type.

A custom field context is either global or limited to selected projects and issue types, and separate contexts can hold different option sets for the same field.

Deleting a custom field permanently deletes all values stored in it across every project.

Common custom field types include select list, multi-select, number, date picker, user picker, cascading select, and labels.

Team-managed projects configure fields directly inside the project and do not use field configuration schemes or screen schemes.

A permission scheme is a named set of grants assigned to a project; grants can target individual users, groups, project roles, application roles, or Anyone.

Browse Projects is the baseline permission: without it, a user cannot see the project or any of its issues through the UI, filters, boards, or dashboards.

An issue security scheme defines issue security levels that further restrict who may view individual issues; it only removes visibility and never grants it.

Changing an issue's security level requires the Set Issue Security permission, and viewing it requires membership in that level's definition.

Permission schemes are shareable, so editing one changes access in every project that uses it.

Global permissions (such as Jira Administrators or Share dashboards and filters) are site-wide and are separate from project permission schemes.

A user needs both Jira product access and a matching project permission grant; missing product access overrides any permission scheme grant.

The Permission helper tool reports, for a chosen user and permission, which grants allow it or which requirements block it.

Project roles are project-scoped membership lists of users and groups, while Jira groups are site-wide and shared across all projects.

Project roles can be referenced in permission schemes, notification schemes, and issue security schemes, which makes them portable between projects.

Default project roles include Administrators, Developers, and Users, plus atlassian-addons-project-access, which add-on and Automation users must belong to.

Users granted Administer Projects can add or remove people from the project's roles without being a Jira administrator.

Deleting a group immediately removes every permission, notification, and issue security grant made to that group across all projects.

Team-managed projects grant access through the Administrator, Member, and Viewer roles instead of classic project roles.

The People tab in project settings lists each user and the roles or groups through which they have access.

A project role can contain both individual users and groups; effective membership is the union of both.

A Scrum board uses a backlog and time-boxed sprints; a Kanban board uses continuous flow with optional per-column WIP limits.

The board filter is a saved JQL filter that defines which issues the board may display; the board cannot show issues the filter excludes.

Every status shown on a board must be mapped to exactly one column on that board, while a single column can contain several statuses.

A board sub-filter applies additional JQL on top of the board filter and hides issues from the board without changing the saved filter.

Swimlanes group cards horizontally by assignee, epic, story, project, or a custom JQL query, independently of the column mapping.

The estimation statistic can be story points, original time estimate, or issue count, and it determines what burndown and velocity charts measure.

Completing a sprint moves incomplete issues either back to the backlog or into the next sprint, depending on the choice made at completion.

The backlog displays issues matching the board filter that are not assigned to an active or future sprint.

Users can see a board only if the saved filter behind it is shared with them and they have Browse Projects on the projects it covers.

Saved filters are built with JQL and can be shared privately, with groups, with projects, or with all logged-in users, subject to the Share dashboards and filters global permission.

A filter subscription emails the filter results to recipients on a configured schedule without requiring them to open Jira.

Useful JQL functions include currentUser(), membersOf(), openSprints(), closedSprints(), releasedVersions(), and linkedIssues().

A dashboard is a collection of gadgets and must be shared with a user before that user can see it in their dashboard list.

Gadgets such as Filter Results, Pie Chart, Two-Dimensional Filter Statistics, and Sprint Burndown are typically driven by a saved filter.

Project reports include burndown, sprint report, velocity, cumulative flow, control chart, epic burndown, and version report.

Velocity is calculated only from sprints that have been completed and whose issues carry estimates.

Cumulative flow and control charts are available for Kanban boards, while burndown and sprint reports require sprints.

A dashboard gadget shows only the issues the viewing user is permitted to browse, so two users can see different numbers on the same gadget.

Access troubleshooting order: confirm Jira product access, then Browse Projects on the project, then the issue security level, then filter or board sharing.

A field that does not appear on an issue is usually absent from the relevant screen, hidden in the field configuration, or scoped out by its custom field context.

A workflow change that appears to have no effect usually means the draft was never published or the project is attached to a different workflow scheme.

A scheme cannot be deleted while a project still references it; reassign the project to another scheme first.

A newly created board that shows no issues usually has a filter or sub-filter that excludes them, or its viewers lack Browse Projects.

Automation rules and post functions can change statuses and fields after a user action, which explains unexpected transitions in the history.

Bulk change operations are capped at 1,000 issues per run, so larger clean-ups must be split into batches.

The audit log records administrative configuration changes such as scheme edits, permission changes, and workflow publications.

Deleted Jira Cloud projects and issues rest in trash for 60 days, after which they are permanently purged and cannot be recovered.