Retiring of custom fields v1

The transition from custom fields v1 to v2

A while ago, we announced the switch to a new architecture of custom fields:

As of October 17, 2022, the previous version of Custom Fields will no longer be supported:

Constraints of Custom Fields V2

  • For V2 Custom Fields it is not allowed to create Custom Fields with the same name and different types. For example, if there is a Custom Field named "test" for User Story with a type number, all other Custom Fields named "test" should have a type number in the system.
  • Maximum name length for Custom Fields is restricted to 100 characters (previously, it was 255).

For several months before the deprecation date, the Targetprocess Support team had been working with all customers we found conflicting Custom Fields of mismatched types in the system. If you were contacted but haven’t updated such custom fields, the fields were automatically renamed.

The side effect on usage of custom fields in REST API

The change in custom field storage does not imply changes in the public REST API v1 or REST API v2.

However, since deprecating the old custom field storage, it is no longer possible
to pull one specific custom field specifying the name of the column in the database, e.g. include=[id,name,CustomField1]

This specific use case was not highlighted in the release notes because this approach was never a part of the public API. Even though some customers have discovered this approach and used it as a workaround to pull specific custom fields via APIv1, it never worked stably, as the column names were changed over time.

The officially supported approaches were (and still are):

  1. Using APIv1 to pull all custom fields as a collection, e.g. include=[id,name,CustomFields]
  2. Using APIv2 to pull all custom fields as a collection, e.g. select={id,name,customvalues}
  3. Using APIv2 to pull a specific custom field by its name, e.g. select={id,name,customfieldname}