Today I expected Jira to behave one way and after some experimentation, I learned that I was wrong. Sometimes this happens and there’s no reason to be afraid of it or embarrassed. Mistakes are an inevitable part of Jira administration. I don’t see them as a waste of time, I see them as opportunities to learn and improve. Allow me to explain.
In 2023, Atlassian launched Jira Product Discovery (JPD) in Cloud for product teams track and prioritize ideas. Just like all Jira project types, JPD projects come with built-in settings and templates to help you quickly build and get started. When evaluating project types and templates, I always recommend creating them in a test environment first. It’s important to understand what additional settings different project templates create in the background. That’s because lots of new settings may mean more items to clean up in the future.
For this article, I set out to document all the new settings added when Jira Product Discovery projects are created. This way you can see what to expect in your own application without messing it up. E.g.: I’ll make the mess so you don’t have to! But after experimenting, I learned that there were few new settings to document. Here’s why:
Scope of Settings
The JPD project configuration is similar to other team-managed project types in Jira Cloud. Projects are scheme-less meaning the settings are not shared with other Jira projects. Therefore there are less global application settings created than for company-managed projects. So, there’s actually not much to report! As such, I’ve categorized the information below into more impactful (global) and less impactful (project-specific) settings.
After I created a sample JPD project, I checked the Jira audit log which records some (but not all) admin changes. (Visit: Admin > System > Audit log) The log recorded 152 actions, but only a few of them were related to creating shared settings. I was pleasantly surprised by the low new global setting count! As I mentioned, in my 9 Ways to Learn Jira Administration article, having a healthy curiosity and willingness to try things out (in a test environment, of course) is a great way to learn new things!
New application-level settings (More impactful)
I found the following new settings by hunting around the Jira admin area.
Global Link Types
Three new link types were created. Atlassian sometimes give new products and features a temporary name during their beta testing phase. I’m assuming that “Polaris” was the initial name for JPD.
Global Groups
The following global access and admin groups were also created:
| Name | Description |
| jira-product-discovery-contributors-1-<cloud-site-name> | Grants contributor access to shared Jira Product Discovery projects on <cloud-site-name>. |
| jira-product-discovery-contributors-<cloud-site-name> | Grants access to contributors for Jira Product Discovery on <cloud-site-name>. (E.g.: grants contributor product access) |
| jira-product-discovery-user-access-admins-<cloud-site-name> | Grants access to administer users and groups for Jira Product Discovery on <cloud-site-name>. Doesn’t grant any product access. |
| jira-product-discovery-users-<cloud-site-name> | Grants access to Jira Product Discovery on <cloud-site-name>. (E.g.: grants licensed user product access) |
That’s it! Everything else I found is stored at the project level. Those settings are:
new Project-Level Settings (Less Impactful)
The Jira audit log reports the following were created. These settings exist in the background and are managed by project-level admins. They are not listed with other similar schemes in the Jira application admin area. Here’s how they work.
Issue types
In JPD projects, there is only one issue type displayed with an orange light bulb icon. There are currently no settings for managing or adding additional issue types. Users can query for issues in JPD projects using the JQL statement: type = idea.
Fields
The audit log shows 1 new field configuration scheme, 28 new custom fields, 28 custom field contexts, and 7 custom field selection options. Again, all this information is scoped to the specific project. Here are the fields and the page to manage them.
As the screenshot shows, it’s also possible to leverage global custom fields, although none are added to the project by default.
Additional settings
A workflow scheme, workflow with a few specifically-worded statuses (Ex: “discovery” and “ready for delivery”), permission scheme, and notification scheme were also created. Those settings are managed in the project settings area. The menu options in the left sidebar look slightly different than in other Jira project types.
Group membership
Additionally, default Atlassian-created service account users like Automation for Jira, Atlassian Assist, Statuspage for Jira and more are added to the new groups noted in the “application-level settings” area above. This is done in the background and membership for these users is not managed by Jira admins.
So, what did I miss? Add your findings in the comments section below!
See also: Default Jira Global Permissions | Default Jira Project Permissions | Default Jira Notifications | Settings Created for Jira Product Discovery Projects