Custom Case Fields Indexing lets Cloud administrators accelerate the filters and reports release owners depend on, without indexing every field in the instance. In TestRail 10.6.1, teams can select up to five high-value custom case fields for indexing, helping reduce delays when reviewing release readiness across large test inventories.
Performance that protects release schedules
Large test estates often create delivery risk in ordinary administrative work: creating runs, assigning ownership, updating cases, and generating approval evidence. This release targets those pressure points with measured performance and reliability improvements.
- Test case pages load about 80% faster for AI-enabled projects with more than 11,000 cases.
- API requests against archived runs with many custom fields are 35–50% faster.
- Run creation now completes reliably for projects containing 25–28 million tests, avoiding prior out-of-memory failures.
- Bulk assignment on runs with more than 30,000 tests now completes without prior timeout and failure patterns.
- PDF reports now generate successfully for plans containing more than 1,000 runs.
For release leadership, these changes reduce the chance that test administration becomes the limiting factor in a deployment decision. Less time waiting on test operations.
Govern custom-field indexing deliberately
Custom fields are commonly used to represent regulatory classifications, product areas, risk levels, test ownership, milestones, and environment-specific attributes. As data volumes increase, filtering and reporting on those fields can become slow enough to discourage evidence-based reviews.
Cloud customers can enable indexing from Admin → Customization → Case Fields when creating or editing an eligible field. Supported field types are Checkbox, Date, Dropdown, Integer, Milestone, and User. Indexed fields are visibly marked in the Case Fields list.
The five-field limit is a governance control, not just a product limit. Indexing improves read performance but can increase storage consumption and slightly affect write performance. Teams should establish selection criteria based on:
- Frequency of use in release filters and management reports
- Importance to compliance, audit, or quality gates
- Query volume across projects and business units
- Whether a field is stable enough to justify ongoing index cost
Review indexed fields periodically as reporting patterns change. A field that supports a one-time migration may not deserve a permanent slot.
Better foundations for automation and integration control
The API now includes GET /index.php?/api/v2/get_version, which returns the current TestRail version for an authenticated session. Integration owners can use this to apply compatibility checks before executing version-dependent workflows.
The get_case_fields and get_result_fields endpoints now return system fields as well as custom fields. Each field includes an is_system boolean, allowing automation to distinguish platform-defined fields from tenant-specific configuration and identify the applicable template.
TestRail CLI 1.15.1 adds read-only query commands for:
runsmilestonesconfigurationsstatusescasefieldsresultfields
The commands support pagination, JSON output, and flexible project selection. For DevOps and DevSecOps teams, this makes it easier to inventory test configuration, validate execution data, and feed controlled quality signals into internal reporting or pipeline controls.
Fixes that improve evidence reliability
The release includes 14 fixes across core test management, reporting, migration, API behavior, and integrations. Several are particularly relevant where test results serve as release evidence.
Key corrections include successful generation of large PDF, milestone, test-case, and Property Distribution reports; corrected Jira custom-field behavior; reliable saving of test cases with steps; and fixes for cases appearing missing or rendering incorrectly after API updates. The release also addresses a migration defect from version 10.1 that could incorrectly move or delete test cases.
These fixes matter beyond user convenience. Missing cases, unreliable reports, or incomplete integration metadata can weaken traceability during release reviews and audits. Teams should include these workflows in their upgrade validation plan, especially where they support regulated delivery or contractual quality obligations.
Recommended adoption approach
Treat the update as an operational change, not only a platform patch.
- Baseline current page-load, report-generation, and bulk-operation timings.
- Validate large run creation, assignment, PDF output, and key Jira flows in a representative environment.
- Identify the five Cloud custom fields with the highest reporting and filtering value.
- Update automation to use version detection and expanded field introspection where useful.
- Record upgrade test evidence and approve rollout through established change controls.
The Early Access release track begins 14 July 2026, followed by the Default release track on 23 July 2026. Organizations with large suites or high-control delivery processes should use the interval to validate production-like volumes and integration paths.
How Merito helps
Merito helps enterprises turn TestRail changes into controlled delivery outcomes. We assess test-management workflows, define performance and regression validation, govern custom-field and reporting design, and align API or CLI automation with CI/CD controls.
The result is a practical adoption plan: measurable acceptance criteria, accountable owners, and evidence that the updated platform supports release governance at the scale your teams operate.
Merito is an authorized TestRail reseller and services partner, listed as a Platinum Verified Partner in the TestRail partner directory. Our TestRail team can scope licensing, sizing, and rollout for 10.6.1, and our enterprise upgrade services help you plan and validate the upgrade with minimal disruption to release schedules.