Templates

Applying a template

Dry-run a draft with Try it, then walk the four-step apply flow — choose a location and template, fill in variables, review an exact server-side preview, and create the work.

Applying a template creates real work in your map. Before it does, DevStride shows you a preview that is exactly what will be created — and creates nothing until you confirm.

Try it first

While you're still building, Try it in the builder resolves your current draft, unsaved edits included, without creating anything. It shows the filled values, the resolved tree, blocking problems, and non-blocking warnings.

Use it constantly. It's the cheapest way to confirm a token resolves the way you expect or that your date offsets produce the schedule you had in mind.

Try it works on the draft. The Preview step in the apply flow works on the saved template against a real target — which is why the builder asks you to save before previewing.

Starting an apply

An apply always starts from a place in your map, or from inside the builder. The Templates page itself has no Apply action — its row actions are Share…, Duplicate, Edit, and Delete.

  • Map Value → the ellipsis (⋯) menu at the top of a workstream column → Apply Template…. The work is created inside that workstream.
  • Right-click a workstream or item on the map → Apply Template…. The work is created under whatever you right-clicked.
  • Inside the builder → Preview on a template you can edit, or Apply Template… on one you can only use. Both open the same dialog. The builder asks you to save first, because the dialog works on the saved template, not your draft.

If you don't see Apply Template… at all, you're missing a permission — see Where a template can go.

The four steps

The dialog runs four steps — 1 Template → 2 Variables → 3 Preview → 4 Apply — with a location bar across the top reading Applying into followed by the workstream or item you're applying into. That bar is editable on step 1 only; from step 2 on, the location is fixed. The primary button reads Next, then Preview, then Apply Template; Back returns a step.

1. Template

Pick where it goes and what to apply. The picker shows only templates that fit the chosen location, with a tally at the bottom — "N of M templates can be applied here." Tick Show templates that don't fit here to see the rest along with the reason each one is blocked.

Each row shows the template's name, audience, what it starts with, how many variables it asks for, and its health.

2. Variables

Answer whatever the template asks. Required answers must be filled before you can continue, and values are validated as you go — a Custom field variable is checked against the real field's rules here, not at the end.

A template with no variables skips this step entirely.

3. Preview

This is exactly what will be created. Nothing exists yet.

This is a genuine server-side dry run. DevStride resolves the saved template against the real target and re-checks everything the apply itself would check — your access to the template, your access to the target, placement legality, validation, and resolution. It uses the same plan-building code the apply job uses, so what you see is what you get.

You get a count of items to be created, the date they're anchored to, which board each cycle placement resolved to, any errors, any warnings, and the full indented tree with type, title, dates, board, and assignee.

If there are errors, the apply button stays disabled. Fix the template and come back.

Templates can specify a persona for work items and subtasks, including work waiting for a person. The preview checks the persona and person together: a compatible chosen persona is preserved, and a person without a chosen persona uses their first eligible persona. An explicitly incompatible pair is refused. Retired personas remain understandable on existing work, but cannot be selected for new template assignments.

4. Apply

Work is created and progress is reported per node. When everything succeeds the dialog reads Template applied — "All items were created successfully."

Where a template can go

Placement depends on what the template starts with:

Template starts withCan be applied to
A workstreamWorkstreams only
A top-level work type (one with no parent type, e.g. an Epic)Workstreams only
Any other work typeWorkstreams, and items of its parent type

So a template rooted at a Feature can go into any workstream, or under an Epic — but not under a Story. The Applies to chips on the template tell you this up front.

When a target doesn't fit, the picker says why, naming the target's type. If you haven't chosen a location yet, rows read Choose a location first.

Applying requires two role permissions — ACCESS_TEMPLATES and CREATE_ITEMS_AND_WORKSTREAMS — plus permission to create in that specific location. Without the role permissions the Apply Template… entry isn't offered; without access to the location, the dialog tells you which is missing.

What happens during an apply

An apply runs as a background job, so a large template doesn't hold your browser hostage. You can press Run in background and carry on working; you'll be notified when it finishes.

Node by node, you'll see created, failed, or skipped.

When it's done, Go to created work takes you straight to the first created root in the map.

After the fan-out, aggregations on the target are recalculated so rollups reflect the new work.

Where created work lands: status, priority, and board

A template node has no status field, and that's deliberate. Every item a template creates gets its status the same way an item created by hand, or by an Excel import, does:

  • Created on a board — the item lands in that board's first status.
  • Created off-board — the item lands in the first New-type status of the status collection that applies to it: its team's collection if the team has one, otherwise the organization default. If that collection has no New-type status, the first status in it is used.

What a template can fix, per work item, is:

  • Priority — the inspector's Priority section.
  • Where the item lands — the inspector's Board section, with modes None, Fixed, Variable, and Cycle. A Cycle placement resolves to a board at apply time, and the preview shows which board each one resolved to. Choosing the board is also how you choose the item's cycle.

The preview enforces the board half of this rule. If a node's board has a first status that doesn't allow the node's work type, the preview reports "The board's default status does not allow this work type" and the apply stays disabled until you pick a different board or fix that board's status collection.

A broken template can't be applied

If a template references something that no longer exists, it can't be applied — and DevStride blocks it in the picker, giving the reason and telling you to ask the owner or an admin to fix it. See Template health.

Bringing a template into your Map

"How do I import a pre-built template?" — there is no import step for Item Templates. A template that already exists in your organization is applied, not imported. What you do depends on where the template is:

Where the template isWhat to do
Already in your organization — it shows under All, Mine, or Organization on the Templates pageApply it from the map or the builder, as described above.
Built by a colleague, and you can't see itAsk them to Share… it with you. Can use lets you apply it; Can edit lets you change it too. It then appears under Shared with me. See Sharing templates.
Shared with you, but you want your own editable versionDuplicate it. The copy is yours, starts private, and is named <name> (copy).
A spreadsheetThat's the Excel flow, not an Item Template. Use Import Template (Excel) from the ⋯ menu on a workstream column — see Import Templates.
In a different DevStride organizationTemplates can't move between organizations today. Rebuild it in the target organization — Save as Template… on real work is the quickest way.