ACP-120 cheat sheet

Jira Cloud has two administrative scopes: site administration (Settings, apps, global permissions, users, product access) and project administration (project settings, roles, components, versions).

Global permissions are granted to groups only, never to individual users; examples include Jira Administrators, Create Shared Objects, Browse Users and Groups, and Bulk Change.

Users need the Create Shared Objects global permission to share filters, dashboards, and boards with groups or all users; without it, saved items remain private to the owner.

Browse Users and Groups controls whether users can see user-picker results, @mention suggestions, group names, and user search results site-wide.

Product access (Jira Software, Jira Service Management) is granted per product in Atlassian Administration; a user can hold Jira access yet see nothing if no project permission matches.

The audit log records administrative configuration changes with category, actor, and timestamp; it does not log ordinary issue edits, comments, or transitions.

Deleted issues move to the trash and are permanently purged after 60 days; deleting a project also sends its issues to the trash.

Archiving a project makes it read-only and hides it from most project lists; archive instead of delete when history must be preserved.

A site default time zone applies to new user profiles and system functions; each user can override it individually, and most timestamps render in the viewer's time zone.

Groups are site-wide and managed centrally in Atlassian Administration; project roles are project-scoped and can be managed by project administrators.

Decision rule: use groups for global permissions and application access, and project roles for project permissions, notification schemes, and issue security.

Default Cloud groups include site-admins, jira-administrators, jira-software-users, jira-core-users, and jira-servicedesk-users.

A project role can contain individual users, groups, or both; the same user may hold different roles in different projects.

The built-in atlassian-addons-project-access role is reserved for Marketplace apps; removing it can break app fields, workflows, and integrations.

Users in Cloud are deactivated or removed from the site rather than hard-deleted; their comments, history, and mentions remain attributed to their account.

Product access can be granted through group membership (for example adding a user to jira-software-users) or individually; individual grants persist after group removal.

SAML single sign-on and SCIM user provisioning are configured in Atlassian Guard and are available on higher-tier Cloud plans.

Because permission schemes reference groups rather than members, adding or removing a group member changes that user's access in every project instantly.

Cloud offers two project types: team-managed (self-contained, simplified settings) and company-managed (scheme-driven, shared configuration).

Team-managed projects cannot share schemes with other projects; configuration changes affect only that single project.

Conversion is one-way: a team-managed project can be converted to company-managed, but the reverse is not supported.

Company-managed projects draw on issue type, workflow, field configuration, issue type screen, permission, notification, and issue security schemes.

The project key is fixed at creation and cannot be changed; it prefixes every issue key in the project (for example PROJ-123).

Templates such as Scrum, Kanban, bug tracking, and task tracking preconfigure issue types, a workflow, and a board at project creation.

Board columns map to statuses; a status can appear in only one column of a given board, and statuses not mapped fall into the rightmost column.

Project categories group projects, appear in JQL as category = "Name", and can be used to filter project pickers and reports.

Archived projects are read-only and must be restored before any configuration or issue changes can be made.

Every company-managed project has exactly one issue type scheme, which defines the available issue types and the default issue type.

Subtask issue types sit at a lower hierarchy level and cannot be used as top-level issues; standard issue types can be restricted to specific parent types.

A field configuration scheme maps issue types to field configurations, and each field configuration sets every field to required, optional, or hidden.

A field must be present on the create screen to be captured at creation; a hidden field cannot be set even by a workflow post function.

Screen schemes define which screens serve the create, edit, and view operations; issue type screen schemes map issue types to those screen schemes.

A field must be added to the relevant screen to appear during create, edit, view, or a transition.

Custom field contexts let a single field carry different options, default values, and descriptions per project and issue type.

Deleting a custom field sends it to a trash for 60 days, during which it can be restored together with its data.

Team-managed projects do not use screens or field configurations; field required-ness and visibility are set directly in project settings.

A workflow consists of statuses and transitions; the workflow scheme maps each issue type in a project to a workflow.

Evaluation order on a transition: conditions first (control availability and visibility), then validators (block with an error), then post functions (run after the transition completes).

Common conditions include user is assignee, user is in group, user is in project role, and permission-based conditions.

Common validators include field required, regular expression, and permission validators, which stop the transition and show a message.

Post functions can set field values, assign the issue, add a comment, or fire an event that triggers notifications and automation.

A transition defined without a source status is global and is available from every status in the workflow.

A status can belong to many workflows, and editing a shared workflow immediately affects every project that uses it.

Avoid loops by ensuring post functions or automation do not transition an issue into the status that triggered them.

Team-managed project workflows use simplified statuses and transitions without conditions, validators, or post functions.

Jira permissions are additive: a user receives a permission if any grant matches them; there is no explicit deny rule.

Grants target users, groups, project roles, or anyone (public); role-based grants scale best because membership changes need no scheme edit.

Browse Projects is the foundational permission; without it a user cannot see the project or any of its issues regardless of other grants.

Issue-level security overrides project permissions: a user lacking the issue's security level cannot see the issue even with Browse Projects.

The Set Issue Security permission lets a user choose or change an issue's level; it does not grant visibility to levels they are not a member of.

Security levels grant visibility to users, groups, project roles, or to field-based values such as reporter, assignee, or a custom user field.

Site administrators and members of the Jira Administrators global permission bypass permission schemes and can see all issues.

Team-managed projects replace permission schemes with three built-in roles: Administrator, Member, and Viewer.

The Permission helper in company-managed project settings explains exactly which grant gives or withholds a permission for a specific user.

Notification schemes map events (issue created, commented, transitioned, assigned) to recipients such as assignee, reporter, watchers, groups, roles, or a user field.

A recipient must hold Browse Projects permission on the issue to actually receive the email; notifications are filtered by permission.

Users control their own notification preferences and autowatch settings; administrators cannot force notifications onto an individual user.

With autowatch enabled, a user is automatically added as a watcher to issues they create, comment on, or are assigned.

The email visibility setting (public vs private) determines whether users can see each other's addresses and whether JQL can search issues by email address.

Jira Cloud sends mail through Atlassian infrastructure; custom SMTP servers and mail-queue management are not configurable in Cloud.

Automation Send email actions can target users, groups, or raw addresses and can embed smart values in the subject and body.

An @mention notifies the mentioned user provided they have Browse Projects permission and have not disabled that notification type.

To send mail on a transition, pair a Fire event post function with a notification scheme entry, or use an automation Send email action.

Rule anatomy: trigger, then optional conditions, then actions, with optional branches that iterate over related issues (subtasks, linked issues, or a JQL result).

Triggers include issue created, edited, transitioned, assigned, field value changed, scheduled (cron), incoming webhook, and manual trigger.

A rule executes with the permissions of its actor; if the actor lacks Transition Issues or is deactivated, transition actions fail.

Smart values such as {{issue.key}}, {{now}}, and {{issue.summary}} inject dynamic data; functions like .toUpperCase, .asNumber, and .jiraDate transform them.

Scheduled rules run on a cron schedule against a JQL query and act only on issues returned by that query at run time.

A 'for each' branch runs the actions once per related issue, so branch scope directly multiplies the number of action executions.

The automation audit log records each rule run and its errors, making it the first place to check for failing conditions or permission problems.

Project administrators can create rules scoped to their own project, while site administrators manage rules spanning multiple projects.

Bulk change from a JQL search is capped at 1,000 issues per operation, so larger clean-ups must be split or handled by automation.