Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,294,689
Community Members
 
Community Events
165
Community Groups

Master Data Management: How to setup a report about custom field configuration?

Edited

As part of our master data management, we are providing a documentation of our master data to our business departments.

This is part of our strategy to manage the growing number of custom fields.

As a Jira Admin, I'm able to access the configuration details of a custom field, it's type and description on page "Custom fields". 

Is it possible to access this list (custom field Name, description, Type) and the custom field ID as a report to be used in Confluence?

We're using cloud, so I can't step into the database.

 

2 answers

0 votes
Jack Brickey Community Leader Jun 01, 2022

hi @Ingo Wenke ,

There isn't any ability to create such reports OOTB. You might check the Marketplace for database reporting or if leveraging the APIs is an option for you consider creating your own solution.

0 votes

There's no reporting on the configuration of Jira built in, it assumes that admins can look at the admin screens to understand what it is doing (and that's not actually wrong - taking the admin data out of context reduces its usefulness for anything other than analytics)

There are apps you can add which can generate reports, but they also fall into the "out of context reports are not as much help as you think".  They are mostly aimed at making administration easier too, rather than reporting, and they tend to be good at it.

A request for reporting on admin always brings me back to the root of the question though.  Why do you want to do this?

You've said "growing number of custom fields", which tells me you've got a problem.  There's a simple rule for looking after custom fields in Jira - if you feel a need to document them, then you've got too many and/or they're poorly named and described.  

For most projects,  people should be able to create or view an issue and understand what they're seeing without having to read documentation.  Some specialised projects are going to have lots of fields that aren't immediately obvious or use internal jargon, and that's fine, but you should be documenting the project and the process in this case, not the fields themselves. 

@Nic Brough _Adaptavist_ 

Thanks for your answer. To be more precise it's "the growing number of requests for new custom field".

With a data dictionary, clarification could become easier and business departments could search for exiting solutions or even discuss changes upfront internally before asking our admins.

Oh, I'm all for a document that tells departments "this is how we work", but a "data dictionary" idea screams that people don't understand what the data is for.

You should be documenting at a project or process level, and then having fields that support that.  

Like Ingo Wenke likes this

That's what we already do. 

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
TAGS
Community showcase
Published in Jira Software

Upcoming changes to epic fields in company-managed projects

👋 Hi there Jira Community! A few months ago we shared with you plans around renaming epics in your company-managed projects. As part of these changes, we highlighted upcoming changes to epics on...

14,240 views 35 44
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you