Jira Custom Fields & Field Clean Up | Rachel Wright | Skillshare

Jira Custom Fields & Field Clean Up

Rachel Wright, Author, Jira Strategy Admin Workbook

Jira Custom Fields & Field Clean Up

Rachel Wright, Author, Jira Strategy Admin Workbook

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
8 Lessons (21m)
    • 1. Introduction

      0:37
    • 2. About Custom Fields

      1:50
    • 3. Custom Field Requests

      1:07
    • 4. Custom Field Checklist

      0:32
    • 5. Proper Field Types

      2:48
    • 6. Do's and Don'ts

      2:37
    • 7. Field Cleanup Checklist

      10:53
    • 8. Resources

      0:17
  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.

41

Students

--

Projects

About This Class

How many custom fields do you have?  For most of us the answer is:  too many!  With research and diligence, you can clean up your duplicate and unused custom fields and get your count down to a manageable number. 

In this course, you’ll learn how custom fields work, how to determine when a new custom field is warranted, and how to clean up custom fields added by application admins and add-ons.

You’ll learn:

  • the attributes of a custom field,
  • how to handle custom field requests,
  • the 7 pieces of information to collect for each new field request,
  • the differences between commonly confused field types,
  • how to audit your custom field list,
  • how to research add-on and admin created fields,
  • and how to remove fields.

This course is for Jira administrators, but even if you’re not an admin, you can take this information back to your admin team.

Need help cleaning up or maintaining your Jira instance?  Learn more at:  jirastrategy.com

Meet Your Teacher

Teacher Profile Image

Rachel Wright

Author, Jira Strategy Admin Workbook

Teacher

Rachel Wright is an entrepreneur, process engineer, and Atlassian Certified Jira Administrator.

She started using Jira and Confluence in 2011, became an administrator in 2013, and was certified in 2016.

Rachel also uses Atlassian tools in her personal life for accomplishing goals and tracking tasks.  Her first book, the “Jira Strategy Admin Workbook“, was written in Confluence and progress was tracked in Jira!

Help for Jira and Confluence Users and Administrators is here!  Visit jirastrategy.com for templates, worksheets, and materials to help you set up, clean up, and maintain your applications.

See full profile

Class Ratings

Expectations Met?
  • Exceeded!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Your creative journey starts here.

  • Unlimited access to every class
  • Supportive online creative community
  • Learn offline with Skillshare’s app

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.

phone

Transcripts

1. Introduction: Hi. I'm Rachel, Right. Certified Your administrator and author of the Jiro Strategy. Admin Workbook in this course will talk about how custom fields work and have to determine when a new custom field is actually warranted and we'll clean up custom fields added by application, add mons and add ons. Let's get started. 2. About Custom Fields: here comes with standard built in fields like summary description and components. But you can also create additional custom fields to track more data. All custom fields have the same attributes. For example, a name, which is the label display to the top or left of the field. A description, which is the copy display below the field. A type like text, select lis number or date and other settings and options like selection values and validation rules. You could see your fields on the custom fields Page in the jeer Admin console here comes with a to 30 custom fields, depending on whether you have cloud or server. Custom fields could be created by jezeera by application administrators or by add ons, plug ins and applications. For example, do your server 7.7 That one comes with eight custom fields and installing Jura service desk on top of your server adds six additional fields. There are three ways to find your custom field count. The total is listed in the database statistics section on the System Info Admin page. My favorite way is to use the browsers control F or find in page feature, visit the custom fields Aven Page and search for something common to each line item. So in the screen shot, you can see I searched for the copy issue types and 14 results were found on the page. Finally, you can count the rows in the Customs Fields table in the Jura database. How many custom fields does your instance Half. 3. Custom Field Requests: Now let's talk about creating new custom fields. The best place to collect and log custom field requests is injera. I recommend you created Project for your Gear admin team. This is a great way to track changes to your application. This works perfectly, except during an upgrade when gear won't be available. So keep that in mind. Before you create a custom field, you should know the answer to the question. Will you query for or report on this field? There's a difference between information that needs to be queried and information that just needs to be visible. Here's an example. Let's say you collect a serial number for a piece of equipment. What will you do with that information? Will you produce a report of all serial numbers in all issues? If so, this is easiest to do with the custom field. But what if that report is not needed? Then you can simply store that information in a standard field like description. 4. Custom Field Checklist: Here's my custom field checklist for any new custom field creation request. Collect this information. What is the fields display name? What will the field be used for? What field description should be shown to the user? What is the fields type? What field properties air needed? What screens should the field be shown on? And what are the validation rules? You can download this checklist as a worksheet at the link shown. 5. Proper Field Types: it's important to know that once you create a field, you can't change its type. For example, you can't change a single select field to a multi select field, so it's important to choose wisely. Here. Some commonly confused types choosing between a single line text field and the multi line text field is a matter of determining the desired character length. If the text limit is 255 characters or less, the single line type is the best choice. This type also takes up the least amount of vertical space on your screen. But for long paragraph type responses, the multi line type is the best choice. The check box and the radio button types are often misused, both injera and in other applications. Here's the difference. If the user can choose multiple selections, use the check box field type with the check box. The user can choose none one or several options, like shown in this screenshot. If the user must choose on Lee one of multiple mutually exclusive options. The radio button type is best, since the user can only choose one. Make sure you use distinct selection labels, and here's a tip for all selection type fields offer and other or n A selection to account for any non listed responses. Here's a mistake I made with field types. I had just built Ajira project for the legal team, which had custom date fields and workflow validation rules we were tracking when approvals occurred. But later I decided I wanted custom timestamp fields instead of custom date fields. Since year doesn't let you change field types, I had to delete the date fields and recreate them in the new date and time format. Then I had to update all the workflow behaviors when I deleted the original fields. You're automatically removed them from all screens, and I assume the related workflow behaviors would be automatically removed as well. Well, I was wrong. They weren't. I immediately cause conflicts in my active workflow and received error reports from end users. The only solution was to apologize and quickly delete and recreate the behaviors. So here's a tip. Before deleting a custom field search for it in the descriptor column in the work flows database table or in your work flows, XML then remove any workflow behaviors for that field before deleting it. We'll talk more about this later 6. Do's and Don'ts: Let's talk about some custom field, do's and dont's first, you wanna limit the number of custom fields you have. Too many can affect performance. If the custom field admin page is slow to load, that's one indication there are too many fields. Here are two links where you can learn more about performance impacts. Next, use a field configuration or the context feature. If you need different feel descriptions or values between projects. Don't create duplicate custom fields. Here are some things to avoid, As I said before Onley create fields that will be queried. Keep field names short and generic so they can be used by multiple projects. Don't create duplicates similar or plural versions of fields. Here's an example from the swamp. One company had three custom fields that all meant the same thing. They had business owner, owner and project contact. One custom field or the use of the Standard Reporter field should have been used to signify who owns an issue. Also, always watch out for misspellings. If you find one, correct it instead of creating a new field. One more example from the deer a swamp. One company used text fields to create date values. So this meant that dates were entered in multiple formats like Jan Juan Janot one Jan first or 1-1 And this makes data impossible to query for or sort, so the data is less useful. Next, don't create more than one field with the same name, even if the field is of a different type. The names will be confusing for application administrators on screens and for end users. Right inquiries. In the screenshot example, there are two custom fields named Owner. How does the end user know which to select? I have no idea, and neither will they. Now you know how and when to create custom fields. But what if you already have a custom field mess? First, I need to say, Don't just start deleting custom fields. You need information before you can make deletion decisions. Deleting a custom field can't be undone, and custom field data cannot be recovered. So be careful when clicking that delete button 7. Field Cleanup Checklist: Here's my method for reducing your custom field count. The first step is an audit. You need to understand what you have right now and how much it differs from the default gear. A set up. You can use the worksheet link to compare your application to a default installation. Also, figure out how many additional custom fields you have. There are a few ways to approach your audit. First, a manual examination, which will cover next. There are also some add ons in the Alaskan marketplace that can help you with the examination. Check out cleaner for Ghira, Custom fields, Usage, Verge era and admin tools for Jura. While these plug ins can help tremendously with your research Onley a human converter min the value of a specific custom field in your organization. Next, make a list of all the field names and types for examination. Literally copy all the data from your custom fields admin page and paste it into excel or confluence. Now that you have your list, you'll want to start researching and classifying. Each field first flagged the fields created by Jura. These fields are likely needed or locked and can't be removed anyway. Don't spend time researching these, then flag the ones created by an add on or plug in. When plug INS air deactivated or uninstalled their custom fields remain. You'll need to determine if data in those fields needs to be retained. Finally, flag all the fields created by humans. These will require the most research. By now, you probably have a spreadsheet or a table like this one. I've created a free field audit worksheet you can use to enter your data, collect your research findings and total the fields to remove. So go download that next. We need to find out everything we can about the three categories of fields. Hide the gear created fields in your spreadsheet so we can focus on the others for each ad on created field. Determine which plug and created it. There are multiple ways to figure this out. First check jeras application audit log in the screen shot. You can see that the satisfaction date field was created today. The logs description shows that this feel this part of Jura service desk. So mystery solved for this field at this information to your spreadsheet. If the application audit log didn't help determine the plug in. You can use the add on audit law to help look for an additional audit log link at the bottom of the manage add ons. Page just match up the custom field created date with the add on installed date in the screen shot. You see the JEER Service desk was installed on April 3rd. If neither of the audit logs help, you can also do a few things. First, check the Fields description on the manage Add ons. Admin page. So as an example, gear service desk fields are always identified. Next, you can log in as an end user, use the add on and see which feels air displayed. And finally, you can check the plug ins documentation. In the screenshot example, you can see the maker of sweet utilities for Jura added documentation on their custom fields. Good job. Be calm from Switzerland. Thanks for doing that. By now, you should know which plug in created which custom field. Next, It's time to check plug in status, which are active, disabled or uninstalled. You can get add on status information from the add on audit log the manager add ons, Admin page or sometimes you can also find traces of an old plug in on your file. Server fields belonging toa active plug ins can be ignored Those air needed but flag any fields for disabled or uninstall plug ins on your spreadsheet For each of these fields, you'll need to determine whether or not it's worth retaining any existing field data. If the plug in is disabled temporarily are you plan to use it again in the future? Leave those fields as they are, but if not, flag those fields for removal. Now let's talk about fields created by ad mons. Hide the Jiro and add on created fields in your spreadsheet so we can focus on the remaining ones. For each admin created field, Look for the following things first duplicates. Look for fields with the exact same name or fields with similar uses. Look for poor type choices as well. For example, a text field that should have been a Eurail field. A check box that should have been a radio button, a text field that should have been a date. Field and admin may have fixed this problem by creating a dupe field of the correct type. Also look for unused fields feels that you know are old and fields in unused year projects . Here's an example of two fields that may have the same meaning. There's no known business reason to keep both. So this is a dupe. Additionally, the screenshot shows that the total quantity field doesn't appear on any screens, so that could mean that the field is old or no longer needed. In this example, I would flag the total quantity field as a dupe of quantity in the spreadsheet. By now, you should have a list of admin created fields that you might not need next. We need to determine the scope of their use, and there are three places to look. Look on the screens in workflow behaviors and in user Jake you well queries. We just talked about fields associated to zero screens. Looking for this on the custom fields. Admin page saves you from hunting through screens individually. Now, after you've checked the screens, look for fields in workflow conditions, validators and post functions. If you have your cloud, the easiest thing to do is export each workflow as XML so you can see all the behaviors. But if you have dear server a database query. It's faster than searching through XML. Check the Descriptor column in the Jiro Workflow table for all behavior information. Next, do it J QL query To see how the field has been used, some things to find out, our how many issues were returned and how many of those issues are in active projects. As a quick tip, I put all my inactive projects in an inactive category, and that way I can quickly exclude those issues. Now, just because data is returned doesn't mean it's useful. Try to determine the business value of the data returned. Finally, check how many users are querying for the custom field. You can get this information from the wreck Content column in the search requests table in the database. Think about the different ways that users may have constructed there. Jake you Well, I recommend searching for both the Fields name and the fields unique. I d find a field unique I d from the address bar of the fields at it page. Or you can get a list of Field I DS from the custom field database table. When you find Duke Fields, you need to determine which to remove. There are three things to consider. First, which field is more popular? Next? Which field has a better name or type? And finally, which field is easier to delete? It's generally easier to retain the most popular field and delete the one with less data. Okay, we've covered research, and we're back to our checklist. Now it's time to take action. Take a look at your spreadsheet and see how many unneeded custom fields you want to remove for each field. Decide if you need to retain the existing data or not. If no, take a database backup and then remove the field from the admin console. If yes, take a database backup and then move or upend the data to a different field. There are a few ways to accomplish this in the sweet utilities. For Jiro, plug in. There's a post function called copy value from other field in the script Runner for Jiro, plug in. There's a copy custom field values function. The Gear command line interface Plug in has a copy field value command, and alternatively, you can export issues manually. Change the data and reimport them when cleaning up your gear. Instance. It's always good to go slow Onley change or delete one thing at a time so you can track the cause of any problems that arise. And this is good to know. User filters will break after custom fields are removed. I always ask users to either update or remove their broken filters. After you've completed your data migration and feel deletions, it's a good idea to re index Now. Re indexes can impact performance, so always do them outside of peak hours. After any cleanup activity, be sure to update your documentation and log your changes finally, at a custom field audit to your regular Jura maintenance schedule. 8. Resources: I have a ton of Jura help. Resource is waiting for you. Check out my Jiro Strategy. Admin workbook available Ajira strategy dot com and Amazon. And also look for my online training courses on Jura mistakes, work flows for business teams and other topics.