Jira Cloud Administration Fundamentals and System Settings
Two consoles, one site
Most questions start with one decision: is this a site concern or a Jira configuration concern? Site-level work - creating users, granting product access, billing, verified domains, security policies, app management - happens at admin.atlassian.com. Jira-level work - schemes, workflows, fields, project templates, general configuration, look and feel - happens inside Jira under the gear icon (Settings).
Global permissions gate everything else
Global permissions are the top tier: Administer Jira (the only route into Jira settings), Browse users and groups, Create shared objects (shared filters and dashboards), Bulk change, and Share dashboards and filters. They are granted to groups, not individuals. Crucially, they do not cascade downward - a Jira administrator who is not in any project's permission scheme still cannot read that project's issues.
Traps that appear in questions
- "Site administrator" and "Jira administrator" are different grants in different consoles.
- Global permission is not project permission; Administer Jira alone does not grant Browse Projects.
- Jira Cloud offers no database access and no SMTP server configuration; answers involving
setenv.sh, JNDI or mail servers are wrong for Cloud. - The audit log is the answer to "how do I find out who changed this scheme or permission?"
- Deleting versus deactivating a user is a site-level decision, not a Jira settings one.
Rule of thumb: if the change affects who can log in and which products they use, it lives at admin.atlassian.com. If it changes how Jira behaves, it lives in Jira settings.