Variables

A variable turns a field into a question. Instead of every applied copy carrying the same assignee or the same start date, the template asks once at apply time and fills the answer in everywhere it's used.

Adding a variable

1. In the builder, make sure the Variables toggle is on.
2. In the Variables panel, add a variable and choose its type.
3. Give it a name. Names must be unique and use letters, numbers, or underscores only — the name is what a {{token}} matches.
4. Optionally set a Label — the prompt shown when the template is applied. Without one, people see the raw name.
5. Leave Required ticked if the template can't be applied without an answer.

A template may declare up to 20 variables.

The eight types

Options is for choices that belong to the template itself — "Region", "Tier", "Environment" — where you don't want to create an organization-wide custom field. Custom field is the opposite: it borrows an existing field's type and validation so the template can't produce a value the field would reject.

Narrowing a User variable

A User variable can be scoped so people only pick from the right group. Under Scoped to, choose:

• Anyone in the organization — no restriction.
• A specific team — always that team, whoever applies it.
• Another Team variable — the person list narrows to whichever team was chosen for that variable. The panel marks these with "filled before this one", because order matters.

The second option is the powerful one for onboarding-style templates: ask "which team?" once, and every assignee slot then offers only that team's members.

If a team choice later invalidates someone already picked, the fill form clears them and says so — an assignee outside the team would be dropped when the item is created anyway.

Using variables in text

Titles and descriptions accept {{variableName}} tokens:

Sprint {{SprintName}} — Backend
Installation in {{Region}}
Website: {{website_url}}

Insert them with the Insert control rather than typing, so you can't misspell a name.

A bad token behaves differently depending on where it is, and the difference is deliberate:

• In a title it's a blocking error. Titles are how you find work later; a title reading Sprint {{SprintNam}} is a defect, so the template won't save or apply.
• In a description it's a warning, and the text is left exactly as typed. Descriptions are prose, and {{ sometimes belongs there literally.

Dates derived from other dates

This is what makes scheduling templates worthwhile. A date field is either:

• Fixed — the same calendar date every time. Rarely what you want.
• Variable — derived from a Date variable, plus an offset in days.

Set the offset with the − / + stepper. The readout shows 0 days, +7 days, -1 day. A negative offset lands before the filled date.

So a template with one KickoffDate variable can lay out an entire schedule relative to it: prep work at -5 days, kickoff at 0 days, first review at +14 days. Fill in one date at apply time and the whole tree dates itself.

Switch the Structure pane to Timeline to see these offsets drawn as bars, measured in days from the anchor variable. It's the quickest way to sanity-check a schedule before sharing the template.

Filling variables in

Whoever applies the template answers the questions in the apply dialog's Variables step. A template that declares none skips that step entirely.

You can also fill them in while building, using Try it — see Applying a template.

Turning variables off

Setting the Variables toggle off doesn't just hide the UI — it rewrites the template to fixed values. If there's anything to lose, DevStride asks first, with an exact count of what goes:

• Every variable is removed.
• Every field that asked for one is cleared.
• Every {{token}} is stripped out of titles and descriptions.

Fixed values you've already set are kept, and nothing is committed until you press Save Template — so you can back out by leaving without saving. Turning variables back on is free and asks nothing, but it can't recover what the strip removed.