What Is Jira Shared Configuration? What It Copies, What It Misses, and When You Need More
Jira shared configuration is a native project creation feature that assigns a new project the same schemes (workflow, permission, notification, screen, field configuration, and issue type) as an existing project. It skips issues, attachments, components, versions, and project role member assignments. The name is misleading enough that Atlassian’s own users filed JRASERVER-45840 (52 votes, still “Gathering Interest” as of 2026) requesting clearer wording such as “Use Existing Schemes.”
How Shared Configuration Works
When you select “Create with shared configuration,” Jira creates a new project and points it at the exact same scheme objects used by the source project. The new project gets references to those schemes, not copies of them.
The consequence catches most admins off guard. As Atlassian Community Champion Trudy Claspill confirmed: “If at a later date you make a change to any of those Schemes, those changes affect all projects that use the changed Scheme.” Edit a workflow in one project, and every project sharing that scheme changes too. To make a project independent afterward, you must manually copy each scheme and reassign, negating most of the time savings.
What shared configuration excludes entirely:
- Issues, attachments, and subtasks
- Components and versions
- Boards (Scrum/Kanban) and sprint data
- Project role member assignments (individual users; groups in roles are shared)
- Issue security scheme, project category, default assignee, and custom field contexts
These exclusions are by design. Components and role assignments are “not schemable”; they have never been part of Jira’s scheme system. A separate feature request (JRASERVER-60335, 41 votes) asks Atlassian to add role copying, also still unresolved.
Shared Configuration vs. Full Project Cloning
| Shared Configuration | Full Project Cloning (Plugin) | |
|---|---|---|
| Schemes | Linked; changes propagate across projects | Independent copies per project |
| Issues, attachments, subtasks | Excluded | Copied |
| Components & versions | Excluded | Copied |
| Best for | Projects that should follow the same evolving process | Projects needing independent config and pre-loaded content |
Shared configuration gives you an empty shell wired to shared schemes. Full project cloning gives you a standalone replica: configuration and content together.
Quick Examples
- Good fit: A DevOps team where every project follows the same ITIL workflow and process changes should roll out everywhere simultaneously.
- Poor fit: An agency creating client projects from a template. They need issues, components, and versions copied, plus the freedom to customize workflows per client without affecting other projects.
- The surprise scenario: An admin edits a notification scheme for one project, unaware that 12 other projects share it. All 12 now send unexpected notifications.
If shared configuration’s limitations are blocking your workflow (especially the missing ability to copy issues and content) a project cloning plugin can duplicate both configuration and content in a single operation, with independent scheme copies so changes stay isolated.