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

[Ingo Wenke]

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.

[Jack Brickey]

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.

[Nic Brough -Adaptavist-]

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. 

[Ingo Wenke]

@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.

[Nic Brough -Adaptavist-]

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.  

[Ingo Wenke]

That's what we already do.