Custom Field Index

As a newer user I was a little confused on how to access custom fields to import into projects. It seemed like as we started creating custom fields we were duplicating some and we wanted to stay consistent so we could use custom fields in the reporting. Our work around was to create a project to document the custom fields the team created. The title would be the task title and the description of how to use the field and the field options would be in the task description. This could also be embedded into a Conventions & Etiquette project as well with Custom Fields as a section header.

image

Enjoy :slight_smile:
Katie

6 Likes

Great idea @Katie_Reynolds

Jason.

This is great, @Katie_Reynolds! I’m definitely setting this up for our team. I tend to get our custom field index from the API but that’s a bit fiddly. Having them all in one task would be much more accessible.

1 Like

Thanks :slight_smile: You can also use tags to indicate to team members what projects need what custom fields.

Katie

1 Like

@Katie_Reynolds, @Jason_Woods, @Mark_Hudson, Here’s another approach to how to document custom fields:

For each logical grouping that makes sense to you of custom fields in use at your company, add one project with one single task for each, like:

  • Project: Custom Fields: Project Management; Task: Project Management Custom Fields
  • Project: Custom Fields: Inventory Metadata; Task: Inventory Metadata Custom Fields

In each project, add the set of corresponding custom fields. In each task, value each custom field to the most commonly used defaults and use the subsections/subtasks to document the definition and usage, like:

  • Stage:
    The phase of the project

  • Priority:
    How important the project is

The actual legal values for dropdowns are self-documenting in this solution, so you may be able to avoid duplicating them in documentation if obvious. This should either save time or keep them in better sync, or both. If you need extra explanations for each value, just add additional subtasks like:

  • Priority:
    How important the project is:
    High: Utmost importance
    Medium: Use this typically
    Low: Try to use this on occasion!

This overall solution includes the approach of grouping sets of related custom fields together to provide a meaningful extra level of hierarchy. If that’s not helpful, then in each of the projects, use one task for each individual custom field instead of one task for each set of custom fields as shown above. (You can also decide to do this all in a single project, but only if you’ll never have more than 20 different custom fields, otherwise you’ll have to have multiple projects, but you can still combine them later as shown below.)

Now, in your Conventions & Etiquette project (or other location), multi-home every task you’ve defined in the multiple projects above under a single Custom Fields: section, like:

  • Custom Fields:
    Project Management Custom Fields
    Inventory Metadata Custom Fields

If you used the one-custom-field-per task alternate approach, then group however you want here using one or more sections like:

  • PM-Related Custom Fields:
    Phase
    Priority

  • Inventory Metadata Custom Fields:
    Quantity
    Type

It sounds like a lot of work, but it’s really just that it’s hard to describe and quicker to implement! I think this provides a lot of flexibility and ease of maintenance. Thoughts?

2 Likes

Great suggestion. Especially for those that have large catalogs of custom fields.

1 Like