#Custom Fields Overview - Test Case Configuration

Custom Fields allow you to extend the default data model by adding custom fields to test cases, defects, requirements, and other entities. These fields are available across all projects in the workspace (or specific projects if configured), enabling you to capture additional information tailored to your testing workflow.

#Understanding Custom Fields

Custom Fields extend the default fields available in test cases, defects, requirements, and releases. They allow you to:

• Capture Additional Data: Store information not covered by default fields
• Standardize Data Collection: Ensure consistent data capture across projects
• Enable Custom Workflows: Support team-specific processes and requirements
• Improve Reporting: Add fields that enhance filtering, sorting, and reporting

#Workspace vs Project Custom Fields

Workspace Custom Fields:

• Available across all projects in the workspace (or selected projects)
• Created and managed at the workspace level
• Can be shared across multiple projects
• Can have project scope (All Projects or Selected Projects)

Project Custom Fields:

• Available only within a specific project
• Created and managed at the project level
• Cannot be shared with other projects

#Accessing Custom Fields

#To access Custom Fields:

1. Navigate to the workspace by clicking on it from the Workspaces page.

2. In the workspace sidebar, click on “Custom Fields” or navigate to /workspace/:workspaceId/fields.

3. As a result, you’ll see the Custom Fields page with a table of all custom fields in the workspace.

#Field Types

Custom Fields support several field types, each designed for specific data input:

#Number

A numeric field for entering numeric values.

• Use Case: Version numbers, test case IDs, priority scores, counts
• Default Value: Numeric value
• Example: “Priority Score”, “Test Case Count”, “Version Number”

#Text Box

A single-line text field for short text input.

• Use Case: Short descriptions, labels, identifiers, tags
• Default Value: Text string
• Example: “Component Name”, “Environment”, “Browser Version”

#Checkbox

A boolean field for yes/no or true/false values.

• Use Case: Flags, toggles, boolean attributes
• Default Value: Checked (true) or Unchecked (false)
• Example: “Is Automated”, “Requires Review”, “Is Critical”

#Dropdown

A select field with predefined options. Each option can have a label, icon, and color.

• Use Case: Categorized values, status indicators, predefined choices
• Default Value: One of the dropdown options
• Example: “Severity” (Critical, High, Medium, Low), “Environment” (Dev, QA, Prod)
• Options: Can have multiple options with custom labels, icons, and colors
• Default Option: One option can be marked as the default

#Views

Views determine where custom fields appear. You can select multiple views for a single field:

#Release

Fields appear in release forms and views.

#Requirement

Fields appear in requirement forms and views.

#Testcase

Fields appear in test case forms and views.

#Defect

Fields appear in defect forms and views.

#Field Properties

Each custom field has the following properties:

• Field ID: Unique identifier automatically assigned
• Field Name: User-defined name
• Description: Optional details about the field
• Field Type: Type of input control (Number, Text Box, Checkbox, Dropdown)
• Is Required: Whether the field must be filled in
• Has Default Value: Whether a default value is set
• Default Value: The default value (if set)
• Project Scope: For workspace fields, whether it applies to all projects or selected projects
• Projects: For workspace fields with selected scope, the list of projects
• Views: List of views where the field appears
• Dropdown Options: For dropdown fields, the list of available options

#Next Steps

• Learn how to View and Filter Fields to find and organize fields
• Explore Creating Fields to add new custom fields
• Check out Managing Fields to edit and delete fields
• Review Best Practices for effective field management