How are Jira customizations scoped?

Question

Our company has two different business groups considering Jira Software on-prem. The usage models between these groups will be quite different, and we expect that each group will want to do its own customizations without impacting the other group and will want its members to see only the relevant data for that group.

Examples of customizations that could be needed: workflows, forms, list views, dashboards, custom fields, custom naming of entities such as Story or Sprint. Mostly stuff that relates to process; as far as cosmetic changes such as CSS, I don't think those will be required.

I am used to using TeamForge, where most of these changes are scoped to the project level, and you can create a site template to replicate them or, in some cases, copy the structure of an object from one project to another. This is not an ideal model, but at least it's straightforward.

So the simple question is: how are customizations scoped in Jira? At what point must two groups decide they are going to need separate Jira instances? I have had trouble finding a description of this in the online docs. I'd appreciate any pointers to a good source of this info.

Nic Brough -Adaptavist- · Accepted Answer

>workflows, forms, list views, dashboards, custom fields,

All core parts of Jira admin.

>custom naming of entities such as Story or Sprint

You can use separate entities for this (e.g. imagine fields called "start date" and "date of start", although I'd recommend sharing as much as possible, to avoid "fielditis" and other problems).  Stories are easier - one team has Story in their project, another has User-Story.  The one issue type you will have to share is Epic, as Jira can only have one type of Epic.

You mention sprint, which is not a project or issue thing, it's part of the structure - that's going to be harder, but there is the option of "translations"

Css and so-on, no, that's down to coding.

But, the need to split a Jira is very rarely to do with this level of customisation.  I've only ever seen it done for sizing reasons, or because the business is about to separate into sub-divisions who will be independent.   It is entirely possible for two teams to use the same Jira in very different ways, without even knowing the others are there if you want.