Formerly published as "Create Child Tasks." Same extension, same templates, same functionality — renamed to reflect that it creates child work items of any type, not just Tasks.

Create Child Work Items

Overview • What's New? • How-To • Examples • Troubleshooting • FAQ • Security • Changelog • Support • Credits

Overview

Every parent work item needs the same set of children — and someone has to create them by hand, one field at a time, every single time.

Create Child Work Items eliminates that. Define the children you want once as Azure DevOps team templates, then create the whole set — correctly typed, pre-populated, and linked to the parent — from a single menu action on the work item form, backlog, or board. Select several parents in a backlog and it works through all of them in one pass, with live progress you can cancel.

Common uses: standing up a definition-of-done checklist on every story, breaking features into consistent delivery steps, or generating the same triage and verification items on every bug.

👋 Coming from 1‑Click Child‑Links? This extension is its actively maintained evolution — your existing team templates and filter rules work as-is, with nothing to recreate or reconfigure. See Compatibility for the two-step switch.

Create Child Work Items

Key Features

One click, many children. Create a full set of child work items from a parent in a single action, each linked into the parent hierarchy automatically.
Bulk creation. Select multiple parents in a backlog and run once — with live progress and a cancel button for long runs.
Any child type your process allows. Tasks, Bugs, Features, and custom types, based on your backlog levels.
Templates you already have. Uses native Azure DevOps team templates — no separate configuration store, nothing new for teams to learn.
Precise matching. Decide when each template applies with simple or advanced filters on type, state, board column and lane, title wildcards, tags, area, and iteration.
Reuse parent values. Inherit or compose field values with dynamic field values and special tokens.
Works within your permissions. Runs under your Azure DevOps user context and never asks for personal access tokens or passwords.

Compatibility

Azure DevOps: Works with Azure DevOps Services (cloud) and Azure DevOps Server 2020 Update 2 or later. Not compatible with Azure DevOps Server 2019 or any earlier TFS versions — for those, use the 1‑Click Child‑Links extension.
Migrating from 1‑Click Child‑Links: Disable or uninstall 1‑Click Child‑Links, then install this extension. Your existing team templates and filter rules keep working unchanged — there is nothing to recreate or reconfigure.

What's New?

Latest — 1.4.2, released 2026-08-14. The extension is now called Create Child Work Items, reflecting that it creates child work items of any type — not just Tasks. Nothing changes for you: your templates, filter rules, and existing installations continue to work exactly as before. This release also adds an organization-level admin and settings page, giving administrators a single place to review extension and deployment details for their Azure DevOps organization.

Recent releases:

1.4.1 · 2026-07-19 — Fixed child type resolution for Basic process projects without a Requirement backlog level.
1.4.0 · 2026-06-28 — Added Terms of Use, Privacy Policy, and Security documentation.
1.3.0 · 2026-06-07 — Added backlog and board menus, bulk processing across multiple parents, and the live Progress Dialog.

See the full details in the Changelog.

How-To Guide

How-To Shortcuts

Quick Start
Defining Work Item Templates
- Creating Filter Rules
  - Simple Filter (Square Brackets)
  - Advanced Filter (JSON)
- Setting Field Values
  - Dynamic Parent Field Values
  - Special Tokens
Applying Child Work Items
Ordering
Wildcards for Title

Quick Start

Install: Install the extension at your Azure DevOps organization. Once installed, it is available to all projects in that organization / collection.
Define Templates: Define one or more Templates for your team (Project Settings → Boards → Team Configuration → Templates).
Create Child Work Items: Open a parent work item (User Story / PBI / Bug) and choose "Create child work items" from the toolbar — child work items will be created from matching templates.

Defining Work Item Templates

Create work item Templates via Project Settings → Boards → Team Configuration → Templates.

Templates have two parts: how they match, and what they set. Use filters (in the template Description) to control when a template applies to a parent work item, and set field values (in the template fields) to define what values the created child work item receives.

ADO Project Team Templates

Creating Filter Rules

The template's Description is used for filtering rules. Two formats are supported:

Simple Filter – Square-bracket list of parent work item types. Example: [Product Backlog Item, Bug]
Advanced Filter – Single-line minified JSON with an applywhen array (see below)

Team Templates - Description Field - Filter Rules

Simple Filter (Square Brackets)

Place a square bracketed list of parent types in the template Description. This will apply the template for those parent types.

[Product Backlog Item, Bug]

Advanced Filter (JSON)

Put a single-line JSON object containing an "applywhen" array into the template Description. Each entry in applywhen is evaluated as OR; fields inside an entry are combined as AND.

Example

{
  "applywhen": [
    {
      "System.WorkItemType": "Product Backlog Item",
      "System.State": [ "New", "Approved" ],
      "System.BoardColumn": "Development",
      "System.BoardLane": "Expedite",
      "System.Title": "*Mobile*",
      "System.Tags": [ "Tag1", "Tag2" ],
      "System.AreaPath": "Project\\Area 1",
      "System.IterationPath": "Project\\Iteration\\Sprint 1"
    }
  ]
}

The above JSON filter rule will match any parent work item when: (WorkItemType = "Product Backlog Item") AND (State = "New" OR "Approved") AND (BoardColumn = "Development")...

See the Examples section below for a more extensive set of filter examples.

Supported Filter Fields

Currently supported filter fields (in template Description JSON):

System.WorkItemType
System.State
System.BoardColumn
System.BoardLane
System.Title
System.Tags
System.AreaPath
System.IterationPath

Notes

Multiple applywhen entries = OR (any entry matching will apply the template).
Arrays = OR across values for that field (with the exception of Tags).
Tags as an array means all listed tags must be present (AND). For tag OR, add separate applywhen entries.
Title supports wildcards (*) and is case-insensitive.
AreaPath/IterationPath must match full path strings (case-insensitive). Escape backslashes in JSON (\\).

Setting Field Values

Templates can set field values on the child work item when it is created in the following ways:

Static Values – Set explicit field values in the template to apply fixed values on the child.
Dynamic Parent Field Values – Inherit parent values or compose strings with tokens.
Special Tokens – Resolve runtime values like the current user (@me) or current iteration (@currentiteration).

Team Templates - Setting Fields

Dynamic Parent Field Values

In addition to simple constant values, child templates can dynamically pull values from the parent work item when the child is created.

There are two complementary methods:

Field Tokens – Copy a parent field into a string field on the child using {FieldName} syntax.
Blank Values – Inherit a parent field value for any field type by leaving the template field value empty.

Using field tokens in string fields

You can include tokens in any string field defined on the template (for example, System.Title, System.Description, or custom string fields).

Syntax: {System.Title}, {System.Description}, {Custom.MyTextField}
Always use the field reference name in tokens, not the display name.
You can combine plain text and one or more tokens in the same value (for example, Dev Task: {System.Title} [{System.State}]).
The token text itself is case-sensitive and must match the field reference name exactly (for example, System.Title, not system.title).

Some common and popular field tokens:

System.Title
System.Description
System.AreaPath
System.IterationPath
System.AssignedTo
System.Tags

For a complete list of available work item fields and their reference names, see the official Microsoft documentation: Work item field reference.

Examples

Child title that prefixes the parent title:
- Template field System.Title = Dev Task: {System.Title}
Child title that uses mulitiple tokens:
- Template field System.Description = Dev Task: {System.Title} [{System.State}]
Child description that copies the parent acceptance criteria:
- Template field System.Description = {Microsoft.VSTS.Common.AcceptanceCriteria}

[Deprecated] Using field tokens in 'non-string' fields: Using {FieldName} tokens for non-string fields (e.g. integer, boolean, date, or complex identity objects) is considered an advanced, unsupported scenario and is now deprecated. For the time being, the extension will still attempt to send such values, but if used inccorectly, it will log an error and the work item not be created. The recommended pattern for non-string fields is to use blank-value inheritance.

Using blank values to inherit parent fields

For any field you add to the template (string, number, date, identity, etc.):

If the template field value is left blank (empty), the extension will:
- Check the parent work item for a value for that field.
- If the parent has a value, copy it to the child.
- If the parent does not have a value, the field is simply not set on the child.

This blank-value inheritance is the recommended way to reuse parent values for all non-string fields, and also works well for string fields when you just want an exact copy.

Special Tokens

In addition to {FieldName} tokens, the extension supports special values in templates:

@me – Assign the work item to the current user (used with System.AssignedTo).
@currentiteration – Use the team's current iteration (used with System.IterationPath and team settings).

These special values are resolved at creation time based on the current user and team configuration.

Applying Child Work Items

Open a parent work item.
Select "Create child work items" from the toolbar.
The extension finds matching Work Item Templates and creates them as child work items.

Create Child Work Items - Results

Ordering

By default, child work items are created in alphabetical order based on the Template Name. To control the creation order, prefix template names with numbers (for example, 01-, 02-).

Work Item Templates Order - Prefix Template Names with Numbers

The child work items will be created in the same alphabetical order of the Template Name fields. Keep in mind, that the title of the child work item is derived by specifiying the System.Title field in the work item template – it is not derived from the Template Name.

Work Item Templates Order - Results

Wildcards for Title

You might want to apply child work items to a parent work item if the parent work item title matches exactly or only partially. It's possible to match the parent work item title by using a wildcard filter rule which uses the asterick character ("*").

{
    "applywhen": [
    {
        "System.WorkItemType": "Product Backlog Item",
        "System.Title": "*WildcardString*"
    }]
}

The following are examples of how the wildcard matching can be used:

- "a*b"     Everything that starts with "a" and ends with "b"
- "a*"      Everything that starts with "a"
- "*b"      Everything that ends with "b"
- "*a*"     Everything that has an "a" in it
- "*a*b*"   Everything that has an "a" in it, followed by anything, followed by a "b", followed by anything

Note: Wildcard filter rules currently only work for the System.Title field.

Examples

Template Description basic example:

[User Story, Bug]

Minimal JSON example (applies to User Story titles containing "integration"):

{
  "applywhen": [
    {
      "System.WorkItemType": "User Story",
      "System.Title": "*integration*"
    }
  ]
}

Multiple rules (OR across rules, AND within rules):

{
  "applywhen": [
    {
      "System.WorkItemType": "User Story",
      "System.State": "Approved"
    },
    {
      "System.WorkItemType": "User Story",
      "System.State": "Committed"
    },
    {
      "System.WorkItemType": "Bug",
      "System.Tags": ["Security"]
    }
  ]
}

Multiple rules (AND across rules, OR within rules):

{
  "applywhen": [
    {
      "System.WorkItemType": ["Product Backlog Item", "User Story"],
      "System.State": ["New", "Approved", "Committed"],
      "System.BoardColumn": ["Backlog", "Ready"],
      "System.BoardLane": ["Default", "Expedite"],
      "System.Tags": ["Overdue", "Urgent"],
      "System.AreaPath": ["Project\\Area 1", "Project\\Area 2"],
      "System.IterationPath": ["Project\\Iteration\\Sprint 1", "Project\\Iteration\\Sprint 2"]
    }
  ]
}

Troubleshooting

No templates found error:
- Verify templates exist for the project team (Project Settings → Boards → Team Configuration → Templates). Templates are defined and scoped per team and will only apply to work items for that specific team — they do not apply to other teams even if the user creating the child work items belongs to those teams. If you need the same templates elsewhere, create or copy them for each team (or switch the active team in the web UI to manage that team's templates).
- Verify the supported work item types configured for the Project in the Azure DevOps Organization Process settings (Project Settings → Boards → Process → Backlog Levels).
- Known limitation (temporary): Custom portfolio backlog categories above Epic may not resolve child types correctly in the current extension version, which can surface a "No templates found" warning even when templates exist.
Work Items not created:
- If running on-premise Azure DevOps / TFS Server, verify that the installed extension version is compatible with your Azure DevOps Server version. See the Compatibility section for more inforation and guidance.
- Confirm filter rules match indended target parent work item field values.
- Check for malformed JSON in template description. Ensure your JSON is valid. Common issues include trailing commas, missing brackets, or improper escaping of backslashes. Use a JSON validator if unsure.
- Confirm you have permission to create work items in the target project.
- Check browser console logs for error messages from the extension.
Tags filter not matching:
- Template tag filters require all listed tags (AND). Use multiple applywhen entries for OR.
Iteration/Area not matching:
- Use exact full path strings; escape backslashes in JSON (e.g., "Project\\Iteration\\Sprint 1").
Child work item title is same as parent work item:
- The child work item title is determined by specifying the System.Title field in the template. If System.Title is not specified in the template, the extension will copy the parent work item's title to the child. The Template Name is not used as the child work item title.
Inheriting parent field values not working:
- Check browser console logs for warnings or errors; look for messages about unresolved parent fields or invalid types during creation.
- Ensure the template field value is truly blank (empty), not whitespace. Remove spaces; leave the value empty to inherit.
- Confirm the parent has a value for that field; inheritance only copies parent values if the field and value exists.
- Verify the child work item type supports the field; some fields are type-specific or process-specific.
- For tags, use System.Tags-Add and leave it blank to inherit; do not use System.Tags in the template.
- System.Title, System.IterationPath, and System.AreaPath automatically inherit from the parent when not set in the template; you do not need to set them as blank to copy these values.
- Use field reference names in templates (e.g., System.Title), not display names.
- Confirm the correct field refernace name is being used:
  - For a complete list of available work item fields and their reference names, see the official Microsoft documentation: Work item field reference.
  - To view a field's reference name in the Azure DevOps Process UI (including custom fields): Organization Settings → Process → select the process used by your project → Work item types → Fields → "Edit" a field → click the Options tab; the "Field Reference Name" appears in the details.

FAQ

Q: What child work item types are supported?
- A: The extension supports creating many child work item types, not just Tasks. The available child types depend on how your process is configured in Azure DevOps Organization Process settings (Project Settings → Boards → Process → Backlog Levels) and on current extension category-resolution support. For example, you can use this extension to create Bugs, Features, or custom types as children when they are defined as valid child types in your process/backlog configuration. Temporary known limitation: custom portfolio backlog categories above Epic are not yet fully supported.
Q: Does this extension work with Azure DevOps Server / TFS (on-premises)?
- A: The latest version of Create Child Work Items is supported on Azure DevOps Services (cloud) and Azure DevOps Server 2020 Update 2 and later. It is not compatible with Azure DevOps Server 2019 or any earlier TFS versions. For older Azure DevOps Server / TFS support, use the 1‑Click Child‑Links extension
Q: How do I match templates for multiple states or types?
- A: Use arrays in the JSON for that field (e.g., "System.State":["Approved","Committed"]).
Q: Can I use wildcards on Area/Iteration?
- A: No — AreaPath and IterationPath require exact full paths (case-insensitive).
Q: How do I make tags match either A or B?
- A: Add multiple applywhen entries, one per tag, to produce an OR effect.
Q: Why is the child work item title the same as the parent work item? How do I specify the title?
- A: If the template does not define System.Title then the extension copies the parent’s title. To set a custom title, add the System.Title field to the template with the desired text.
Q: Can I use parent field values in child work items?
- A: Yes. Use Dynamic Parent Field Values to inherit parent values or compose strings with {FieldName} tokens, and see Special Tokens for runtime values like @me (AssignedTo) and @currentiteration (IterationPath). Note: System.Title, System.IterationPath, and System.AreaPath automatically inherit from the parent when not set in the template.
Q: Can I create child work items for more than one parent at a time?
- A: Yes. In backlog views, you can select multiple parent work items and run Create Child Work Items once. The extension will process each selected parent and show progress in the status dialog.
Q: Can I enable the extension for only some projects?
- A: No. Azure DevOps Services installs extensions at the organization level (Azure DevOps Server: collection level). They become available to all projects in that scope. To restrict usage you’d need to control permissions or uninstall/disable the extension at the org level.

Security

Create Child Work Items runs inside the Azure DevOps UI in your browser and does not require a separate backend service.

Required Azure DevOps Permissions

The extension requests only these scopes:

vso.work - Read access used to evaluate the selected parent work item, retrieve team templates, and determine which templates apply.
vso.work_write - Write access used to create child work items and link them to the parent hierarchy.

Azure DevOps Authorization Boundaries

The extension runs under your current Azure DevOps user context. It cannot bypass your Azure DevOps project and work item permissions.

Secrets and Source Code

The extension does not request personal access tokens (PATs), passwords, or other secrets from users.
The source code is private commercial software. For review and governance details, see the Terms of Use and Privacy Policy.

Changelog

All notable changes to Create Child Work Items. Dates in YYYY-MM-DD.

1.4.2 — 2026-08-14

Changed: Renamed the extension from "Create Child Tasks" to "Create Child Work Items" to reflect that it creates child work items of any type, not just Tasks. This is a display name change only — functionality, templates, and existing installations are unaffected.
Added: A new organization-level admin/settings page for Create Child Work Items.

1.4.1 — 2026-07-19

Fixed: Child type resolution for Basic process projects that do not define a Requirement backlog level, preventing Epic-level parents (for example, Issues under Epics with no Feature level) from returning no child template types and showing a "No templates found" warning

1.4.0 — 2026-06-28

Added: Terms of Use documentation and license information for clearer governance and usage expectations
Added: Privacy Policy documentation describing current data handling and future telemetry disclosures
Added: Security documentation to explain extension permissions, authorization boundaries, and secrets handling guidance

1.3.0 — 2026-06-07

Added: Create child work items directly from backlog item menus and board card menus, in addition to the existing work item form toolbar action
Added: Ability to process multiple parent work items at once from backlog views, with confirmation for large selections and an option to cancel during processing
Added: Progress Status Dialog for child work item creation with live progress, multiple parent queuing, process cancellation, refresh support, and completion status

1.2.0 — 2026-02-16

Fixed: Dynamic parent field value tokens not working correctly in child work item templates
Added: Dynamic Parent Field Values – inherit parent work item values on child work items using {FieldName} tokens and blank-value inheritance. See Dynamic Parent Field Values for details.
Added: Special Tokens support – @me for AssignedTo and @currentiteration for IterationPath (documentation)
Changed: Improved troubleshooting guidance for field value inheritance scenarios

1.1.2 — 2026-01-25

Fixed: Error creating work items on Azure DevOps Server 2020 due to api-version=6.0 compatibility; Extension now uses the required 6.0-preview version.

1.1.1 — 2026-01-16

Fixed: Big speed boost in Chrome and Edge browsers
Changed: Improved overall performance of child work item generation
Changed: Logging glow-up that brings clearer formatting and coverage when you need details
Changed: General tune-ups and polish across the extension
Changed: Updated compatibility to Azure DevOps Services and Azure DevOps Server 2020 Update 2+ to take advantage of improved performance on modern platforms; dropped support for older on-premises installs (Azure DevOps Server 2019 and earlier TFS). See the Compatibility section for how to continue using version 1.0.0 on older servers.

1.0.0 — 2025-12

Fixed: Broken Tag filtering
Fixed: Resolved "Error saving [object Object]" error message when creating child work items
Fixed: Invalid/malformed template JSON failing remaining template matching (possibly causing not all matching child work items to be created)
Fixed: Graceful handling use of @currentiteration when no default iterations are setup for respective Project Team
Added: IterationPath filtering
Added: Release Notes / Changelog
Changed: Improved end user documentation: Overview, Key Features, How-To, Examples, Troubleshooting, FAQs
Changed: Improved browser console logging
Changed: Marketplace lising updates: Description, Tags

0.3.x — 2020

Added: Wildcard filtering on Title
Changed: Removed "Create child work items" button from backlog and board menu views to prevent child work items not being created reliably

0.1.x — 2019

Original fork from https://github.com/figueiredorui/1-click-child-links
Added: Area Path Filtering
Added: Dark theme support
Added: Improved documentation and screenshots
Changed: Logo and icons

Support

For help and to get in touch:

Check docs first: Review the Overview, How‑To Guide, Examples, Troubleshooting, and FAQ sections to see if your question is already answered.
Use Q&A: For questions, feature requests, and anything not covered by the documentation, please use the extension's Q&A to submit and discuss.
Email: For other scenarios or to contact the developer directly, email support@mattwilks.ca.

Credits

Originally cloned from https://github.com/figueiredorui/1-click-child-links

Create Child Work Items

Matt Wilks

Create Child Work Items

Overview

Key Features

Compatibility

What's New?

How-To Guide

Quick Start

Defining Work Item Templates

Creating Filter Rules

Simple Filter (Square Brackets)

Advanced Filter (JSON)

Setting Field Values

Dynamic Parent Field Values

Using field tokens in string fields

Using blank values to inherit parent fields

Special Tokens

Applying Child Work Items

Ordering

Wildcards for Title

Examples

Troubleshooting

FAQ

Security

Required Azure DevOps Permissions

Azure DevOps Authorization Boundaries

Secrets and Source Code

Changelog

1.4.2 — 2026-08-14

1.4.1 — 2026-07-19

1.4.0 — 2026-06-28

1.3.0 — 2026-06-07

1.2.0 — 2026-02-16

1.1.2 — 2026-01-25

1.1.1 — 2026-01-16

1.0.0 — 2025-12

0.3.x — 2020

0.1.x — 2019

Support

Credits