Application and Project Configuration
What to know
Project configuration starts with the project type: company-managed (classic) projects use shared schemes, while team-managed (next-gen) projects keep configuration local to the project. Know the scheme chain: an issue type scheme maps issue types to a project, a workflow scheme maps issue types to workflows, a field configuration scheme maps issue types to field configurations, and a screen scheme maps operations (create, view, edit) to screens. A permission scheme governs who may act. Application-level settings include the defaults for new projects, time tracking, and the global permission set (e.g., Jira Administrators, Browse Users).
Traps
Questions love to ask where a change must be made. Editing a shared scheme affects every project using it; a team-managed project ignores shared schemes entirely. Another trap: renaming versus deleting an issue type, and whether a field is required globally versus in one field configuration. Watch for "scheme association" questions - a project can use a different scheme per issue type, so a change to one issue type's workflow may not touch others.
Rule of thumb
Before answering, ask: is the setting application-wide, scheme-level, or project-level? Work top-down: global settings, then shared schemes, then project association, then the issue-type mapping. If the question says "only this project," a shared scheme edit is usually wrong.
Worked example
A user wants a new status only in project ALPHA without affecting BETA. If both share a workflow, editing it breaks BETA. Correct approach: create a copy of the workflow, add the status, and associate the copy with ALPHA via a workflow scheme scoped to that project.