Additional Fields
The inherited process allows fields to be added without leaving the Agile template. The project adds four, each because a fact needed to be queried and no standard field carried it, and one work item type, Goal. This page is the definition each field is created from; a field that exists in the process but not here is drift, and a field here that does not yet exist is marked below.
|
Status: current. The three fields were agreed on 2026-10-24 and created the same day on the inherited process, each in a Delivery group on the Details page of the types listed under Applies to. One name changed between the proposal and the field: the Agile and CMMI templates already own a field called "Found In Environment", so the project’s picklist is named Detected In. |
1. Released In
Reference name |
|
Type |
Text, single line |
Applies to |
User Story, Bug, Task, Feature |
Written by |
The factory’s release marking, once the release is tagged and its stage manifest is bumped, from the pull requests merged since the previous release tag; a person when backfilling a release older than admin-service 2.4.26. |
Read by |
Release contents queries ("what shipped in admin-service 2.4.26"), the Deployment and Testing tasks of the item (which copy it), the Control Tower’s release lane. |
Values |
The release name as the repository and version, for example |
Why a field and not a tag or the iteration: a tag would need a new open facet in a closed vocabulary; the Iteration Path is single-valued and would be lost to any future sprint use; a text field is queryable with contains, carries two values, and costs nothing.
2. Detected In
Reference name |
|
Type |
Picklist, single select |
Applies to |
Bug |
Values |
|
Written by |
Whoever raises the bug. Required when the state leaves New. |
Read by |
Defect analysis by environment; the question "did stage catch it" for every production defect. |
The template field "Found In Environment" (Microsoft.VSTS.CMMI.FoundInEnvironment) is free text and belongs to the CMMI template, which is why this field carries a different name. Before it existed the environment was named in the repro steps. The tag vocabulary deliberately refuses production and staging as tags because every production defect would carry one; a picklist on the Bug is the right home for the same fact.
3. Target Environment
Reference name |
|
Type |
Picklist, single select |
Applies to |
Task |
Values |
|
Written by |
Whoever creates a release task ( |
Read by |
The factory’s release marking, whose stage run and production run move the Deployment tasks for that environment to Active; the "release tasks due" query, which groups by it. |
The title says what, not where: [<component>] Release task: <what>. The environment lives only in this field, and a flat list of release tasks is read grouped by it; the form Release task (stage): … belongs to Tasks created before the field existed and is still understood by the release marking.
4. Goal Slug
Reference name |
|
Type |
Text, single line |
Applies to |
Goal |
Written by |
Whoever sets the goal, once. |
Read by |
The Control Tower when it joins a Goal item to the items carrying |
Values |
The slug exactly as it appears in the tag, for example |
The Goal type itself was added 2026-10-26 with this field, Target Date and the Acceptance Criteria field shown as Met when; see Goals.
5. Activity, as used
Activity is a standard template field on Task. The project does not change its values; it assigns a meaning to three of them so that automation can create a classified task without a tag. The meanings are in Work Item Process. If a fourth kind of automated task appears, it takes one of the remaining template values before any thought of a new field.
6. Adding a field
A field is added to the inherited process by a Project Collection Administrator, under Organization settings › Process › idealogic-za Agile › the work item type › New field, or through the Work Item Tracking Process REST API: create the picklist, create the field at organisation level with a Custom. reference name, derive the system work item type if it is not yet customised, add the field to each type listed under Applies to, and place a control in the Delivery group on the Details page. Field names are unique across the organisation and the templates' own fields count, so check the name before creating. Then update this page, and add the field to the queries that read it.