In a TestRail- or Xray-class case repository, what is the difference between a built-in case field and a custom one, and what does adding a custom field cost?
answer
- the product's model versus an administrator's
- template decides which fields appear
- a half-filled field misreports silently
- free text drifts into synonyms
- removal means deciding about stored values
basics
~20 sBuilt-in fields belong to the product's own model of a case, so its filtering, exports and integrations already understand them. Custom fields are declared by an administrator with a name, a type and allowed values, and each adds something everyone must fill.
solid answer
~50 sBuilt-in fields ship with the product. Its search, saved views, export and any integration written against it already know what they mean, and they behave the same way in every project. A custom field is declared by an administrator — a name, a type such as a free-text value, a date, a pick from a fixed list, or a person — and then appears on cases whose **template** includes it. The template is what decides which fields a case shows and whether its body is a step table or one free-text block. The cost of a custom field is ongoing rather than one-off: someone must populate it on every case, an owner must govern the option list before it drifts into synonyms, projects diverge if each defines its own, and the value usually degrades to a plain string when the data leaves the tool.
go deeper
Know that some case fields come with the product and others are declared by an administrator, and that the template a case was created from decides which of them it shows.
Explain the mechanics: a custom field's name, type and allowed values are declared, then appear via templates, while built-ins are already understood by search, export and integrations.
Show what carrying one costs after the excitement: population discipline, an owner for the option list, and the half-filled field that quietly misreports to whoever reads the chart.
Own the governance call. Decide whether field sets are standardised across projects for comparability or delegated for local fit, and be able to defend the reporting consequence either way.
## Where a field comes from A case's fields come from two places, and the difference matters more than it first appears. **Built-in fields** are part of the product's own model of what a case is. Because the product defines them, everything inside the product already understands them: the search, the saved views, the export, the reporting surface, and any integration somebody wrote against the tool. They also mean the same thing in every project in the instance, which is what makes cross-project comparison possible at all. **Custom fields** are declared by an administrator. The declaration is roughly always the same shape: a name, a type — a short value, a longer text block, a date, a pick from a fixed list, a person — and, for a list type, the set of allowed values. From that point the field exists on cases whose template shows it. | | Built-in field | Custom field | |---|---|---| | Defined by | the product itself | an administrator, per project or template | | Meaning across projects | uniform | uniform only if someone governs it | | Understood by export and integrations | yes | partially, often as a plain value | | Cost to remove | not yours to remove | a decision about every stored value | ## What the template decides A **template** is the case's shape: which fields appear, in what order, and whether the body is a numbered step table or a single free-text block. Templates are why one repository can hold a stepped case and a step-free one side by side without either looking malformed, and they are how a project keeps the field set an author faces down to what that project actually uses. Changing the template of cases that already exist is the disruptive operation in this area. Fields that the new template does not show still hold values; fields it newly shows are empty on every existing case. Neither is a corruption, but both mean the repository is briefly describing itself inaccurately, so template changes are done deliberately and with a plan for backfilling, not as a quick tidy-up. ## What a custom field costs 1. **Population.** A field that half the inventory leaves blank cannot be reported on honestly: a report over it silently describes only the filled half, and the reader has no way to see that from the chart. 2. **Governance of its values.** A free-text custom field drifts into synonyms within weeks — three spellings of the same team, four capitalisations of the same component. A fixed list stops that, but the list then needs an owner who adds values and retires them. 3. **Divergence between projects.** When each project declares its own set, two projects' cases stop being comparable, and any question asked across the whole repository has to be answered per project and stitched together by hand. 4. **Weaker support downstream.** Product reporting, exports and integrations understand built-ins first. Custom values often arrive as a bare string, or need mapping work at every boundary the data crosses. 5. **Removal is expensive.** Deleting a field means deciding what happens to every value stored in it, and by then someone's report or saved query depends on it. ## When a custom field earns its place - It answers a question somebody actually asks on a schedule, and no existing field answers it. - The answer is a small closed set rather than an opinion, so a list type can hold it. - The value cannot be derived from something the repository already knows, such as the folder the case sits in or an existing built-in. - Somebody will own its option list, and somebody will notice when it stops being filled. The useful test before adding one is: **which report or which query stops working without this field, and who reads that report?** If the answer is "it would be nice to have", the field will be created, filled for a month, and left half-populated forever — which is worse than never having it, because a half-filled field invites conclusions the data does not support. ## The wider shape Built-in and custom is a question about the *field layer* of the case, sitting around the title, preconditions and step table. It is worth separating in your head from the question of what to classify cases by in the first place. This is the mechanical part: where a field comes from, who can declare one, which template shows it, and what carrying it costs from then on.
- What makes changing the template on cases that already exist a disruptive operation?Values in fields the new template no longer shows are still stored but invisible, and fields it newly shows are empty on every existing case. Neither state is corrupt, but the repository is briefly describing itself inaccurately, so the change needs a backfill plan rather than being done as a tidy-up.
- Why is a free-text custom field usually worse than a fixed list for the same information?Free text drifts. Within weeks the same value exists in three spellings and two capitalisations, so any grouping over it undercounts every variant. A fixed list keeps the values comparable, at the price of needing an owner who adds new options and retires dead ones.
saying these in an interview costs you the question
- Treats custom fields as free because creating one is quick
- Reports on a field most cases leave blank
- Lets every project declare its own field set unmanaged
- Assumes exports carry custom values as richly as built-ins
- Confuses the template with the folder the case sits in