Privacy Policy — Stencil Issue Templates for Jira

Effective: 6 September 2026

Stencil Issue Templates for Jira ("the app") is published on the Atlassian Marketplace by Two Little Moons Consulting, ABN 49 732 400 198, Penrith, NSW 2750, Australia ("we", "us"). Contact: support@twolittlemoons.com.

This policy explains what the app does with data. It is specific on purpose: every category of data the app stores is itemised below.

What the app does

The app stores reusable issue templates and applies them to Jira work items — filling in fields and creating child work items. It runs entirely on Atlassian's Forge platform and sends data to no server outside Atlassian.

Data the app reads from Jira

When you use a screen in the app, these reads happen as you, with your own Jira permissions and never with elevated rights:

the work item you are looking at — key, id, summary, description, issue type, status, priority, reporter, assignee, labels, components, due date and the values of any custom fields a template refers to;
its parent and its children, when you save a work item as a template;
the project's id, key and name; its issue types; its sub-task type; its Jira Service Management request types;
the fields available on a given create screen, so the template editor can offer them;
your Atlassian account id and display name, and the display names of people a template assigns work to;
your email address, but only as Jira itself chooses to disclose it — Jira returns it only when your own profile visibility allows. It is used for one thing: the {{user.email}} placeholder. If a template author has put that placeholder in a field, the address is written into that field on the work item, exactly as if you had typed it. It is never stored in the app's own storage and never appears in the audit log;
your permissions on a project, to decide what you are allowed to do;
the result of any JQL condition a template uses, evaluated by Jira against the work item in question.

When a template is applied automatically in response to a work item being created or its type being changed, or by a Jira Automation rule, there is no signed-in person to act as, so those reads and writes are made by the app itself. For Automation specifically, a project administrator must switch that on for their project first; it is off by default.

Data the app writes to Jira

Work items. Creating child work items from a template is the app's purpose. They are ordinary Jira work items in your project, subject to your workflows and permissions.
Field values on an existing work item — the fields a template fills in. By default the app only writes into fields Jira reports as empty; overwriting or appending is opt-in per template.
An issue property named stencil-templates on each work item a template has been applied to. It records which templates were applied, when, by which route, the keys of the work items that run created, which template items were skipped, and a fingerprint (a short non-reversible hash) of each field value the app wrote. The fingerprints exist so that if the issue type later changes, the app can tell its own untouched boilerplate apart from something you have since written, and replace only the former. This property is what makes the app's behaviour idempotent and JQL-searchable, and it holds no field content.
Issue links. A template item can be configured to create a work item beside the target and link it, rather than under it. In that case the app creates the Jira issue link of the type the template names.
One comment per apply, if the project has that setting on, summarising what the run did.
Clearing the "Issue template" custom field on a work item, after using its value to choose a template.

The app never transitions a work item and never deletes one, except in one case: if a project administrator explicitly enables roll back on failure, a partially-failed run deletes the work items that same run created, and nothing else.

Data the app stores in Forge app storage

All of the following is held in Atlassian's own Forge storage, inside your site's installation. None of it leaves Atlassian.

What	Why	Keyed by
Templates — name, description, category, and for every item in the tree: its issue type, how it hangs off its parent, its conditions, and the field values it sets (including rich-text descriptions, which may contain whatever text an author typed)	This is the product	site (global library) or project
Template index — the name, category, scope, issue types, request types, project restrictions and enabled/default/auto-apply flags of each template	So opening the template list and deciding which template applies costs one read, not five hundred	site or project
Variable declarations — the name, label, type, default and choice list of each value a template asks for	So the app knows what to prompt for	inside the template
Default-template mappings — issue type id → template id, and request type id → template id	So a type can have a default template	site or project
Project settings — whether auto-apply is on, whether to comment, who may edit templates, whether to re-evaluate on an issue-type change, whether to roll back on failure	So the project's choices persist	project
Audit log — one entry per template created, updated, deleted, applied or failed: the timestamp, the action, the actor's display name and account id, the template's id and name, the work item key, the project id, how the apply was triggered, how many work items it created, how long it took, and a short safe summary	So an administrator can see what happened and why, which is the "why did it stop working" question the app exists to be able to answer	site (bounded to the most recent 500 entries)

Data the app stores in your browser

One item, in the Global Issue Create dialog only:

What	Why	Where
A list of Jira field ids (for example `summary`, `customfield_10042`) that templates on this site have filled in before — ids only, never any value	Jira requires an app to name the fields it may modify in the create dialog before it is allowed to ask which template applies, which is impossible to do exactly the first time. Remembering the ids is what lets a template fill in a custom field on the next create dialog you open	`localStorage`, under the key `stencil.uim.fields`, in your own browser

It contains no work item content, no personal data and nothing about you. Clearing your browser's site data removes it; the app will simply relearn the ids.

Template content is written by your own administrators and authors. If somebody types personal information into a template's description, the app stores that description — it has no way to know. Nothing in Forge storage is copied from a work item unless a person used "save this work item as a template", which copies exactly the fields shown in that dialog.

The audit log records who did what, never the values written. An audit trail that quoted the description it wrote would be a second copy of your data with weaker access control.

Removal

Uninstalling the app deletes everything in the table above, because Forge app storage belongs to the installation.

Three things survive an uninstall, and you should know which:

Work items the app created are not deleted. They are ordinary Jira work items and always were.
The stencil-templates issue property remains on the work items it was written to. It contains no field content. A Jira administrator can delete it through Jira's own REST API (DELETE /rest/api/3/issue/{key}/properties/stencil-templates) if you want it gone.
The stencil.uim.fields entry in each person's browser, described above. It is a list of Jira field ids and nothing else; clearing the site's data in that browser removes it.

Data leaving Atlassian

None. The app declares no external fetch permissions in its Forge manifest, so it is not technically capable of contacting any host other than Atlassian's own APIs. It qualifies for Atlassian's Runs on Atlassian designation, and data residency follows your Jira site.

The app uses no third-party analytics, no advertising, no tracking pixels, and no AI or machine-learning service.

Logging

Forge keeps invocation logs for troubleshooting. They contain timestamps, the Jira REST paths called, HTTP status codes, Jira's own error messages, and counts. They do not contain field values, template content, display names or email addresses. Site administrators control whether log access is shared with us.

Sub-processors

Atlassian Pty Ltd, as the operator of the Forge platform on which the app runs and in which all of its data resides. There are no others.

Children

The app is a business tool sold to organisations and is not directed at anyone under 16.

Your rights

Templates can be exported to JSON from the app's own screens at any time, so you can take a copy of everything the app holds before you remove it.

To delete what the app has stored, uninstall it. That removes everything in the table above, because Forge app storage belongs to the installation. It is not, however, a single act that erases every trace: as set out under Removal, three things deliberately survive, and each is removed separately if you want it gone.

Work items the app created are not deleted. They are ordinary Jira work items and yours to keep, edit or delete through Jira itself.
The stencil-templates issue property remains on the work items it was written to. It contains no field content, and a Jira administrator can delete it through Jira's own REST API (DELETE /rest/api/3/issue/{key}/properties/stencil-templates).
The stencil.uim.fields entry in each person's browser remains until that site's data is cleared in that browser. It is a list of Jira field ids and nothing else.

For anything more specific, or any question about this policy, email support@twolittlemoons.com and we will respond within 30 days.

Changes

We will update this page and the effective date if the app's data handling changes. Adding an external service, or any new category of stored data, would be announced in the app's release notes before it ships.