Share this page

# Fields

You can add custom user-defined fields (UDFs) to spaces and workspaces. You can also change the display labels for system fields.

In this topic:

## Add a custom field

Add a custom field to a shared space or workspace.

Space/workspace hierarchy. In a shared space, custom fields added at the space level are available in all its workspaces. Workspace admins can define fields that are specific to the workspace.

Workspace fields cannot have the same name or label as shared space fields.

To add a custom field:

1. Open the global menu and select Administration > General Settings.

2. Select a shared space or workspace.

3. Select the Entities tab and select an entity.

4. Select the Fields tab.

5. Click Field button to add a new custom field.

6. Enter the field details.

   Setting | Description
   --- | ---
   Name | An internal name for the field. APIs use the name to access the field. No uppercase letters or punctuation are allowed. A suffix _udf is automatically added to the field. You can use the same name for custom fields in different entities. This can increase the number of custom fields that you can add. For details, see Custom field quota. You cannot reuse names of previously-deleted custom fields.
   Label | The field's display name. Tip: To apply the same field to related subtypes, such as Priority in manual tests and suites, create fields in all the subtypes with the same Name, Label, and Field type. Reserved names: Some words are reserved and cannot be used as field labels. These include: Product.
   Type | Select a field type from the list. The field types include standard data fields and reference fields, which reference other workspace items. Standard data fields: Boolean, Date and Time (in UTC format), Date, Integer, Long string (up to 1500 chars), Memo, String (up to 255 chars). Reference fields: Application Module, Environment, List, Milestone, Release, Sprint, Team, User. For details on reference fields, see Reference fields.
   List | If the field is of type List, associate the field with a list. Users will be able to select values from the selected list. For details on creating custom lists, see Lists.
   Allow multiple values | Select to allow users to select multiple values for the field. Available for field types: Application Module, Environment, List, Milestone, Release, Sprint, Team, User.
   Is trendable | Select to allow the field to be included in trend widgets. Supported for all entities, except runs and tasks. Available for field types: List, Boolean, Integer, User, Team, Release, Date, Date and Time For more details, see Trendable fields.
   Is searchable | For String, Long string, and Memo fields: Select to include the field in global searches. For details, see Searchable fields.
   Hide field | Select to hide the field from specific users based on their roles. Hidden fields are indicated in the Fields grid by the Is hidden and Show only for columns. For details on configuration, limitations, and special cases, see Field hiding.
   Description | Enter a description for the field. The description can be displayed as a tooltip when the user hovers over the field's label. For more details, see Change display labels and descriptions. Language support: The description text remains the same in all display languages.
   Add to form | You can add the field to existing custom forms. Select the forms to which to add the field. For shared space-level fields, you can select shared space-level forms. For workspace-level fields, you can select workspace-level forms.

## Reference fields

Reference fields enable you to create links between items, by referencing another item. The reference field type determines the possible values for the item. For example, the field type Release references release items, and so the available values for a Release-type field are the releases defined in the workspace or shared space.

Using custom reference fields, you can include additional information relevant to an item.

Example: Using custom fields of the type Milestone, you can:

- Define multiple milestone fields for a single entity, such as a security milestone and a go-to-market milestone.
- Include milestone-related information for entities that do not support a system milestone field.

Note the following when working with reference fields:

- Reference fields can reference items in the same workspace, or shared items within a shared space. For details on creating shared items, see Shared items in workspaces.
- You can use business rules to modify the available values for a reference field, based on a condition that you define. For details, see Modify available values for a reference field.

## Change display labels and descriptions

You can change a field's display name and description.

Note:

- Changing a field's display name does not change the field's internal name. The internal name is used in APIs and remains the same even if the display name is changed.
- A field's description is displayed as a tooltip when users hover over the field in an item's details view. To enable the tooltips, set the SHOW_FIELD_TOOLTIP parameter. For details, see Configuration parameters.

To change field labels or descriptions:

1. Open the global menu and select Administration > General Settings.

2. Select a shared space or a workspace in an isolated space.

3. Select the Entities tab and select an entity.

4. Select the Fields tab and select a field.

1. Modify the Label field to change the display name, or the Description field to edit the description, and click Save.

## Custom fields for subtypes

Various grids combine items of different subtypes in the same list, as listed in the table.

Grid | Subtypes
--- | ---
Backlog grid | Defects, user stories, quality stories
Test grid | Manual tests, BDD scenarios, Gherkin tests, model-based tests, test suites, automated tests
Run grid | Manual test runs, automated test runs

You can add the same custom field to related subtypes.

Example: Add the same Group field to the Defect, User Story, and Quality Story entities.

To ensure that the custom fields in the various subtypes are represented by the same grid column, create the custom field with the same settings in all the subtypes. The following settings must match: Name, Label, Field Type.

## Trendable fields

You can define a custom field as trendable, enabling filtering and grouping by the custom field in trend widgets. This is available for all entities except runs and tasks.

Note:

- If you define a custom field as trendable, it cannot be reverted to non-trendable. We recommend that you do not define custom fields as trendable, unless it is absolutely necessary. Setting a large amount of custom fields as trendable has an impact on performance.

- When you define a custom field as trendable, a Trend sync status property on the custom field shows the status of synchronization. The synchronization job runs in the scope of a space, and it synchronizes all pending newly trendable custom fields within the space. There is a 10-minute delay when the job is triggered to allow the space admin to mark a set of custom fields as trendable. The delay is determined by a site parameter UDF_BECOME_TRENDABLE_SYNC_DELAY and can be modified by the admin.

- If you define the same custom field in multiple subtypes (such as user story and defect), it must be either trendable or non-trendable in all the subtypes.

## Searchable fields

When searching for an item, the search term can be looked for in the following default attributes: ID, name, description, and comments. You can define other custom fields to be searchable too. Searchable custom fields can be of the types String, Long string, and Memo.

The quota of searchable shared space fields and workspace fields is defined by the following parameters:

- SEARCHABLE_UDFS_LIMIT_IN_SHARED_SPACE
- SEARCHABLE_UDFS_LIMIT_IN_WORKSPACE

By default, the maximum is 14 for shared space fields and 0 for workspace fields. The total combined quota must not exceed 20 searchable fields. For details, see Configuration parameters.

### Performance impacts

Setting custom fields as searchable might have the following impacts on performance:

- Exceeding 15 searchable fields can impact performance.

- After you set a custom field as searchable, the data must first be indexed before it is available in a search. Indexing fields that have existed for a long time might cause performance issues. We recommend making existing custom fields searchable at a time when there is minimal usage. For example, at the end of a business day or on a weekend.

Tip: Plan ahead and determine which custom fields should be searchable. If you plan to set multiple custom fields as searchable, enable the Is searchable option for the custom fields at the same time, for optimal performance.

## Field hiding

You can hide custom fields from specific users by configuring visibility restrictions based on roles. Hidden fields are concealed throughout the system, including dashboard widgets, grids, and forms. This helps protect sensitive data and simplify the user interface for different user groups.

Editions: Field hiding is available for shared spaces in Enterprise edition.

In the Fields grid, hidden custom fields are indicated in the Is hidden and Show only for columns.

### Configuration details

- Role-based visibility: You can select specific roles that are allowed to view and use the field in the Show only for list. Users without these roles will not see the field anywhere in the system.

  Note: If you are allowing roles on fields at the space-level, you must include at least one workspace-level role.

- Users with multiple roles: If a user has multiple roles assigned, the field is visible if at least one of their roles is included in the Show only for list.

- Subtype propagation: When field hiding is configured for a common user-defined field (UDF), the configuration is automatically propagated to all subtypes that use that field.

- Shared entities management role: Users with the Shared Entities Management role can view and manage hidden fields in shared entities. However, this role alone does not grant field visibility. Users must also be assigned at least one workspace-level role that includes the field in its Show only for list. If a field is hidden from all workspace roles, it remains hidden even for users with the Shared Entities Management role.

- Retrieve hidden user defined fields by role (API): To retrieve the list of hidden fields for a specific role, use the metadata fields API. For the detailed process, see Retrieve hidden fields by role.

### Limitations and special cases

- Filters: Filters involving hidden fields may exist for entities editable by the user. In these cases, the user can modify and override the original configuration.

- Favorites: When a favorite configuration includes hidden fields, users with Edit permissions but without visibility to those fields will see an adjusted version of the favorite, where the hidden field configurations are automatically removed. If these users save the favorite, the favorite will be saved minus the hidden fields.

- Quality Risk settings: Settings in the Quality Risk tab are not displayed when they include hidden fields. Users with the Update Risk Settings permission can still modify and override the original configuration, even if it contains hidden fields. Administrators should restrict this permission carefully to prevent unintended exposure of hidden field data through risk configuration changes.

- Release processes:

  - Quality criteria: Hidden fields configurations are not applied in quality criteria entities. Avoid using hidden custom fields in quality criteria, as the field label and value are displayed in the quality criteria setting to all users with quality gate permissions.

  - Auto actions: Hidden fields can be included in emails sent by release process auto actions to disallowed users when hidden fields are passed as variables in add-comment or send-mail auto actions. Avoid including hidden fields in email templates and variable substitutions to prevent exposure of sensitive field data.

- Visibility in the Settings area: In the Settings area, items such as Business Rules or Dynamic Labels that include hidden fields are visible to users with Manage permissions for these items. Such users can see the names and values of hidden fields within the settings, but the fields remain hidden at the application level. Also, these items appear as inactive for users who are not supposed to see the hidden fields, even though they remain active on the server side.

- Moving entities between workspaces: If a user has permission to move entities from one workspace to another, and some fields are hidden in the source workspace, but not in the destination workspace, the hidden data could become visible after the move. Administrators should ensure that the same visibility restrictions are applied in the destination workspace to prevent unintended exposure of hidden fields.

- Activity log:

  - Any users with privileges to access the activity can see change details regarding fields that are defined as hidden to the same users.

  - If a hidden field is deleted and a new field is created with the same name, the new field is not displayed in the activity log.

- OData: Hidden fields can be retrieved in cross workspace OData queries.

Caution: For all the cases described above, administrators should carefully review and assign privileges to ensure that users who are not authorized to view hidden fields do not receive permissions to manage or edit configurations that include them. This helps prevent unintended exposure or modification of sensitive configuration data.

## Custom field quota

Before creating user-defined fields, determine how many user-defined fields you need. Certain field types have limits on the number of user-defined fields that can be created.

The following table lists the number of allowed user-defined fields in a workspace for each field type.

Field type | Quota per workspace
--- | ---
Date and Time / Date | A combined total of 40 for both types
Long string | 5
Memo | 30 Note: You can modify this value by setting the MEMO_UDFS_LIMIT parameter. For details, see Configuration parameters.
Number | 50
String / Boolean | A combined total of 100 for both types
Reference fields | Unlimited. For details, see Reference fields.

You can increase the number of custom fields beyond the quota by using the same name for custom fields in related subtypes.

Depending on your needs, you can either create identical fields, including the label and type, or create fields with the same name but different labels:

- Identical fields. Use this option if you want to add the same field to related subtypes, such as the Group field in user stories and defects. For details, see Custom fields for subtypes.

- Non-identical fields. Use this option if you want to create unique fields in related subtypes and not count towards the quota of the field type. For example, create long string fields in the user story and defect entities. In both entities, enter the same value in the Name property and different values in the Label property. It will be considered that you've used up one long string field rather than two.

  Note: In combined grids, the two fields will display under the same column, using the common Name as its title.

The following are related subtypes. Using the same name for custom fields in the different subtypes will save on your custom field quota.

Type | Related subtypes
--- | ---
Work items | Epics, features, user stories, quality stories, defects
Testing items | Manual tests, Gherkin tests, automated tests, test suites, BDD scenarios, model-based tests
Run items | Suite run, manual run, automated run
Release process items | Manual action, auto action, quality gate

## String field security

To provide a full range of defect management capabilities, users are allowed to enter web-specific information in string fields, including code snippets that support HTML and JavaScript.

Entering such information is allowed in all text and rich-text fields in the system, including entity names and descriptions, where users often report defects containing JavaScript and HTML code snippets.

We ensure that none of the text input entered by users is executed by the web application, preventing cross-site scripting (XSS) attacks.

To the best of our knowledge, OpenText Software Delivery Management has no XSS vulnerabilities. This is rigorously tested through our automated testing processes and reinforced by security-focused code reviews.

## Delete a field

Delete custom field when they are no longer needed.

Delete shared space fields from the shared space settings and workspace fields from the workspace settings.

You cannot reuse the name of a deleted field in a new custom field.

When you delete a field, the following areas are affected:

Area | Effect
--- | ---
Forms | Deleted fields are removed from forms.
Rules | All rules containing the deleted field are invalid and deactivated.
Dashboard widgets | Dashboard widgets that include the deleted field become not valid. Modify the configuration as needed or remove the widget.
Filters, Groupings, Sorts | Deleted fields are removed from filters, groupings, and sorts. A message is displayed.
Grid displays | Deleted fields are removed from the grid display without a message.
Audit log | Deleted fields remain in the server audit log.

## See also

- Forms
- Lists
- Labels

https://admhelp.microfocus.com Software Delivery Management 8942
Tips to improve your search results... OpenText™ Software Delivery Management Help Center OpenText™ Software Delivery Management Help 26.3 All View Local Help Center View Online Help Center Version: