Agile Central - Administration: Managing Custom Fields

Products

• Rally On-Premise
• Rally SaaS

Issue/Introduction

As administrators, it's important that you manage your custom fields closely or else all manner of chaos can creep up on you and into the platform.

This article will walk you through the various types, what objects you can create them on, whether they can be be deleted or edited to change types, etc.

Here is a quick reference to some of the behaviors of custom fields and some tips and tricks as well:

• Custom fields cannot be deleted

  • Have a strategy for reusing fields

• Field type cannot be modified once created

  • Be familiar with field types and its differences before you start

• Required fields will be required for the entire workspace

  • They cannot be hidden at various project levels

• Custom fields must be created and made visible or hidden by a workspace or subscription administrator

• A custom dropdown list field must have the same list values in each project in which it is used.

  • If different values are needed for different projects, you must create distinct fields, with unique names and display names, for each dropdown list

• KanBan custom fields must exist in both Work Items of Story and Defect in order to display properly on the Kanban Board

• Custom field visibility at the Project level is the key for allowing program/team level customization

• Project Admins cannot see or access Fields for their respective projects

• Using a name convention for fields created for different groups can help in keeping things straight

• You can specify the order on which custom fields will appear on the artifacts details page by preceding the name with a number

 

 

Resolution

Managing Custom Fields

Determining your processes for creating and managing custom fields is critical for allowing you to scale the processes to match the growing needs of your organization.

With the ability to create custom fields on so many objects there might be additional needs beyond the scenario listed below.

Primarily there are three:

• Business

  • Business level requests will usually be applied to whole workspaces.

  • Should come to Subscription or Workspace Admins

• Product

  • Product level requests might be applied to the whole workspace or may only apply to certain projects

  • Should come to Workspace Admins

• Team

  • Team level requests will usually only be applied to the project layer the team resides in

  • Should come from Project Admins to Workspace Admins

When dealing with these requests it is always good to review current custom fields and see if there exists a field or set of fields that already fit the need of the request. E.g. Is there already an existing custom dropdown field that either has the needed values or can have one value added

While there is no native way to extract a clear list of all custom fields, their type, and values, there is a script created outside of Rally that can be used to extract it.

As with all such scripts or apps developed outside of Rally, this is not supported and the user(s) assume all repair and maintenance burdens for the script.

There are certain questions you want answered when processing requests for new custom fields:

1. What are we solving with this field/whats its value

   1. Do the requestors have a clear implementation/use or will you have to assist in building the process/reporting

2. Is it needed in specific layers/nodes or for the whole workspace

3. If requested as Required, is it really required

   1. Impact to existing processes investigated

   2. b. Communication and execution plan

With the information provided in this document you should a good foundation for creating and managing your Custom Field policies and processes with Rally.