Project creation, project types, and project-level configuration
Jira Cloud offers two project models, and almost every question in this domain hinges on telling them apart. Company-managed projects (formerly classic) are built on shared schemes: workflow scheme, issue type scheme, field configuration scheme, screen scheme, permission scheme and notification scheme, all maintained centrally by an administrator. Team-managed projects (formerly next-gen) own their configuration: issue types, statuses, fields, workflow and access roles live inside the project and cannot be shared or centrally governed.
When you create a project you choose a template - Scrum, Kanban, Bug tracking, Task tracking, Project management or a service project - and the template seeds issue types, workflow, board and screens. Project-level settings then include the name, the key (chosen at creation and effectively permanent), the project lead, the default assignee (project lead or unassigned), a category used for grouping and filtering, and the avatar.
Traps that appear in questions: assuming team-managed projects respect shared permission schemes (they use their own two roles, Administrator and Member); assuming a key can be edited later; assuming deleting a project deletes its shared schemes (it does not); and assuming a team-managed project converts freely - Cloud offers a one-way migration assistant, but it requires verification afterwards.
Rule of thumb: if the requirement is “the same workflow maintained once for twelve projects”, the answer is company-managed with a shared scheme; if it is “this team configures everything itself without an admin”, the answer is team-managed.