Categorizing Custom Fields

[#1]

Having the ability to determine at a glance how a custom field is used in Workfront is extremely important for efficiently managing data for multiple groups in an enterprise. Without proper identification of how fields are used creates a unique challenge, especially when changes to a field have downstream impacts, including impacts to integrations. There are at least three ways to determine how a field is used and its importance within the entire organization/enterprise.

Who owns the field?

The ability to restrict access to fields through sharing is a good start. This has the potential of helping data managers and System Administrators know "WHO" owns a field, but it does take some effort to report on this. Some questions we typically ask is: Who uses this field? Is the field used globally? Who is in charge of maintaining this field?

How is the field used?

In calculated fields, we may pull data from other custom fields. Integrations can automatically populate a text field based on selections from custom fields or built in fields such as Portfolio Name. Integrations may also retrieve the dropdown selections of a custom field in order to populate data in another application. It is important to know which fields are being used and in what circumstances. We will ask: Is this included in a calculation? Is there an integration associated with this field? Can this field be modified without breaking the associated integration or calculation?

Current Workarounds

Currently we have used the description field to notate who owns a field, or if the field is used in a calculation or integration, but the maintenance of this and ability to report on this is extremely tedious and prone to errors. It also has caused confusion for end-users when they see the field in a custom form with the [?] icon next to it, hover over the [?] and they see this information.

What we are looking for is a better way to organize, categorize, and protect our data without compromising the name, label, and description of the field. Names should be used for the end-user. Labels should be used for calculations and integrations. Descriptions should be used for instructions.

My recommendation is to provide 3 additional fields. One for identifying the owners (individual groups, multiple groups, or global), one to identify which calculated fields use this field in the calculation, and one to allow "tagging" of the field for integrations.

Example for Field Owners

Have an Owner(s) field with the ability to add multiple groups, or if it is a global field, we can use "Global".

Example for Calculated Fields:

I don't have a visual but would like to see this auto-populate with the calculated fields using this field as well as the form (since you may have the same calculated field on multiple forms with different calculations/expressions). Such as: Field 1 (Custom Form 1, Custom Form 3, Custom Form 5), etc.

Example for Field Tagging:

Allow the ability to add whether the field is used in an integration, and which integration. For example, if the field is used with Salesforce integrations, we can type #salesforce. Something like this image -

The three fields above are MOST ideal but having at least one field for the purpose of categorizing and noting who, what, and where a field is used would be EXTREMELY beneficial for custom data management.