Project Configuration and Project Administration
The anatomy of a project
A Jira project is a bundle of references: an issue type scheme, a workflow scheme, a field configuration scheme, a screen scheme, a permission scheme, a notification scheme, and an issue security scheme. Project administration is largely about understanding these shared objects and how changes propagate. Schemes can be shared across projects or project-specific; editing a shared scheme affects every project that uses it, which is the single most common trap in this domain.
Know the difference between company-managed and team-managed projects: team-managed projects keep configuration inside the project and are simpler but less reusable, while company-managed projects rely on the shared scheme model. Questions often test which project type supports a given capability.
Traps to watch
- Deleting or editing a shared scheme and expecting the change to be isolated to one project.
- Confusing project roles (flexible, per-project membership containers) with groups (global). Roles are the recommended way to drive permission schemes because membership is project-specific.
- Forgetting that a project must have exactly one scheme of each type assigned; you swap schemes, you do not stack them.
Rule of thumb
Before changing any scheme, ask: "Is this scheme shared?" If yes, model the blast radius across all associated projects. Prefer creating a copy of a scheme for a single project rather than editing the shared original.
Worked example: a new project needs a slightly different workflow. Copy the existing workflow scheme, associate the copy with the new project, then edit freely without touching other projects.