A template references your organization's configuration — work types, custom fields, priorities, tags, boards, users, and teams. Those things change. Template health is how DevStride tells you when a change has left a template unable to do its job, instead of letting it quietly create the wrong work.
Health is checked every time a template is read, against your live configuration. There are two states:
| Badge | Meaning |
|---|---|
| Healthy | Everything it references still exists and is usable |
| Needs attention | At least one reference is broken — the template cannot be applied |
Hover the badge for the full list of what's wrong.
A template marked Needs attention is blocked from being applied. It's blocked in the picker, which names the problem and suggests asking the owner or an admin to fix it, and it's blocked again server-side — so a stale browser tab can't slip one through.
DevStride reacts differently depending on whether the change can be undone.
When something is deleted outright, there is nothing to restore, so the reference is removed from the template and the owner is notified. The template stays applicable; it just no longer sets that value.
This happens when:
The owner gets a notification naming exactly what changed, and the affected node in the builder shows a dismissible note.
When something is archived or deactivated it can come back, so DevStride changes nothing in the template and just marks it as needing attention. Restore the referent and the template heals itself.
This happens when:
The fix is either to restore the thing that was archived, or to edit the template to stop referencing it.
When you delete a custom field, tag, or priority, DevStride first tells you how many templates use it and what will happen to them — whether they'll be repaired or flagged.
Templates you don't have access to are counted but redacted: you'll see that N private templates belonging to other members are included, without their names or owners. The count is honest even when the details aren't yours to see.
The builder shows a problems count covering everything that would block an apply: broken references, fields that ask for a variable that isn't set, and blocking findings from the dry run. Non-blocking notes are deliberately kept off that counter and shown on the field they concern instead — a permanent warning badge on a perfectly good template just teaches people to ignore it.
A template must stay inside these bounds:
| Limit | Value |
|---|---|
| Nodes | 500 — workstreams, work items, and sub-items combined |
| Depth | 10 levels — sub-items don't count as a level |
| Variables | 20 |
| Title length | 500 characters, after variables are filled in |
| Options per Options variable | 2 to 50 |
| Template name | 100 characters |
| Template description | 500 characters |
The variable cap is enforced as you build — the add control switches off at 20. Node count, depth, and title length are only checked when you save, so a very large template can be built and then refused. If that happens, the exact reason appears in a red banner above the builder.
"This template cannot be applied inside a workstream" / "...inside a Story" — the template's root doesn't fit the target. Check the Applies to chips and see where a template can go.
A title shows {{SomeName}} literally after applying — that was a description, not a title. Unknown tokens in descriptions are left verbatim by design; in titles they're a blocking error. Check the variable name matches exactly.
The assignee didn't come through — the node also sets a team, and the assignee wasn't on it. An assignee outside the node's team is dropped when the item is created.
A variable type won't insert into a title — User, Team, and Board variables resolve to records rather than text. Only Text, Number, Date, and Options can be interpolated.
The apply stopped partway — an apply isn't a transaction. The failed node and its descendants are skipped, siblings still complete, and created work is kept. Use Copy error details to get the list of what failed.
Sharing templates
Templates start private. Share one with specific people, teams, or the whole organization — and use an explicit exclusion when a team grant reaches someone it shouldn't.
Knowledge Base Overview
Write articles once and publish them to your team, your customers, or both — with categories, audience controls, and a searchable help center.