nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Company projects -> anyone make a "template" project for shared settings?

Justin_be6gb0

Hi Jira Pro's.

I'm trying to understand the difference between Company and Team projects. I'm looking to have all our projects have the same configuration and settings. Team members will not be doing their own thing.

If I understand company projects - they allow the settings to be shared to other company projects.

If this is correct, do people create a "template" project which will never have any real issues, etc. But this is where the project is configured with issue settings, workflow settings, etc.

Then we create other projects based off this one.

e.g.

- Template Project: nothing in here. just customized

- Project A: Based off Template

- Project B: Based off Template

- etc.

Is this the correct understanding of things?

or is there a separate section/place for company project settings which will always apply to any new project that is a 'company project' ?

Cheers!

Accepted answers

Akash Singh_vujl0e

@Justin Welcome to Atlassian Community!

You're on the right track! The key difference between Company-Managed and Team-Managed projects in Jira lies in how configurations are handled:

Company-Managed Projects (CMP): Configurations (workflows, issue types, screens, etc.) are centrally managed and can be shared across multiple projects. This ensures consistency and standardization across your organization.
Team-Managed Projects (TMP): Each project is independent, meaning configurations (workflows, fields, etc.) are specific to that project and cannot be shared. These are more flexible but harder to maintain across multiple projects.

Setting up a "template" project with predefined workflows, issue types, and configurations can be helpful for testing automation or troubleshooting. However, there's no need to base every new project on a dummy template. Instead, you can establish a standardized set of project schemes for a project used by your teams and create new projects using the same configurations. For any configuration changes or troubleshooting, use a separate dummy project with replicated schemes rather than the ones actively in use.

Best Practices for Modifying Shared Configurations

If you're on Jira Premium, it's best to test any changes in a Jira Sandbox before rolling them out. If you’re on Standard plan, consider using a separate project with cloned schemes (not the exact ones in use) to validate changes before applying them to live projects as explained previously.

All comments

Akash Singh_vujl0e

@Justin Welcome to Atlassian Community!

You're on the right track! The key difference between Company-Managed and Team-Managed projects in Jira lies in how configurations are handled:

Company-Managed Projects (CMP): Configurations (workflows, issue types, screens, etc.) are centrally managed and can be shared across multiple projects. This ensures consistency and standardization across your organization.
Team-Managed Projects (TMP): Each project is independent, meaning configurations (workflows, fields, etc.) are specific to that project and cannot be shared. These are more flexible but harder to maintain across multiple projects.

Best Practices for Modifying Shared Configurations

Justin_be6gb0

Hi @Akash Singh - thank you for your help. Much appreciated!

> Instead, you can establish a standardized set of project schemes for a project used by your teams and create new projects using the same configurations

So does this mean each jira company account (e.g. example.atlassian.net) has a list of project schemes? and this is set/defined outside of any project ? and when ready, we can "apply" a project scheme to a project?

Akash Singh_vujl0e

@Justin Each Jira project is made up of multiple smaller schemes, such as Workflow Schemes, Issue Type Schemes, Priority Schemes, Issue Type Screen Schemes, and Field Configuration Schemes. These schemes are modular and can be reused across different projects. When I refer to a "project scheme," I mean the collective set of these schemes that define a Jira project.

For example, if you have 10 projects and need to hide a field in only 5 of them without affecting the rest, you can duplicate the existing Field Configuration Scheme, modify the copied version to hide the field, and apply it to the 5 projects. This ensures that only the intended change is applied without impacting the other projects.

Lukas Nicolai_Seibert

@Justin welcome to the Rebellion!

If that describes your use case:

- establishing a standardized set of project with pre defined schemes for a project used by your teams and create new projects using the same configurations -

This is not a trap! - If you do not mind using a third party app for this our Templating.app might be a solution for you. You can create various Project Templates based on pre defined schemes. You can even define permissions for your team members to make them available only for certain user groups: