Two complaints send people looking, and both are about things a template app should never have asked of you: a second Jira project to hold the templates, and nothing working in team-managed projects. Blueprint does neither, and this page says where it is the weaker choice.
The short answer
Most template apps for Jira keep their templates as issues in a project of their own. That means a project to create, permissions to maintain, and a second place where work that is not work accumulates. Blueprint keeps blueprints in the site’s own app storage, so there is nothing to create and nothing to keep in step.
And team-managed projects — which is what every new Jira project is by default — define their own issue types, with identifiers valid nowhere else. An app that remembers one is refused on every single create. Blueprint asks the project each time.
A detail that only shows up on a real site: the default team-managed subtask create screen has no due date field and no priority field on it at all. A blueprint whose whole point is “three days after we start” therefore has nowhere to put the date. Blueprint creates the subtask with what the screen accepts and sets the rest immediately afterwards, which Jira allows and which is the only way those values can land.
Side by side
| Signoff | Issue Templates for Jira | |
|---|---|---|
| Where templates live | In your site’s own app storage. No project to create, nothing to keep in step. | A separate Jira project holds the templates, which has to be created and maintained. |
| Team-managed projects | Works. The subtask type is read from that project’s own metadata every time, because a team-managed project invents its own. | Its own reviews and vendor replies say it does not fully work there. |
| What a step carries | Assignee, priority, due date, labels, description and any custom field on the project’s subtask screen. | Varies by configuration. |
| Due dates on team-managed subtasks | Set, even though Jira’s own subtask create screen there offers no due date field at all — the value is applied straight after the subtask is created. | — |
| Dates | Offsets. “Three days after we start”, or “two days before it is due”, counted from the issue’s own dates. | Set by hand afterwards. |
| Before it creates anything | Every subtask shown with its assignee and worked-out date, and a plain sentence naming anything the project will not accept. | It creates the issues. |
| Where your data goes | Nowhere. Runs on Atlassian — no server of ours in the path. | Varies by vendor. |
The right-hand column describes the other product as its own listing, its published reviews and its vendor’s own replies to those reviews describe it, in September 2026. If something here is out of date, tell us and it gets corrected.
What their customers say
Public reviews on the Atlassian Marketplace listing, unedited.
From the Atlassian Marketplace listing of the largest app in this category — rated 3.9 out of 5, with 26 one-star reviews across 126 published reviews.
“Requires at least (2) JIRA Project - one for the templates and another for actual work. Too much effort to configure and maintain a shadow project.”
“Does not work with nextgen projects”
“It would be better if we could create templates for multiple projects. You can only create one templates for one project.”
“Wasted 30 mins trying to set up this thing and eventually the project I selected in the settings will not appear in the create from template form”
Being fair
There are real cases where an established templates app is the better choice, and pretending otherwise would waste your afternoon rather than ours:
Questions
No, and that is the main reason this page exists. Blueprints are kept in your site’s own app storage. There is no template project to create, no second project full of issues that are not work, and nothing to keep in step with the project it describes.
Yes. A team-managed project defines its own issue types, so an app that remembers a site-wide subtask type is refused with “Specify a valid issue type” on every create. Blueprint reads the subtask type out of that project’s own create metadata every time it is used.
Yes. Jira’s default team-managed subtask create screen carries no due date field and no priority field at all — we measured this on a real site — so those values cannot travel with the create. Blueprint creates the subtask with what the screen accepts and then sets the rest immediately afterwards, which Jira allows. If a value genuinely will not go, it says so rather than leaving a subtask that quietly has no date.
No. A Jira status is the far end of a workflow transition rather than a field, and a new subtask stands at the start of its workflow. Anything claiming otherwise is either doing a transition afterwards or is wrong.
Jira will not, and neither will we. An Epic takes stories and tasks, not subtasks — Jira refuses with “Please select valid parent issue”, which reads like a bad identifier and is actually a parent of the wrong kind. Blueprint says that in words instead of showing you Jira’s message.
The demo runs in your browser with no account, no Jira site and no install.
Not on monday.com? Send an approval from here — no account, no install.