Runs on Atlassian
Word and PDF Document Generator is built only on Atlassian Forge. Eligibility for Atlassian's Runs on Atlassian program was checked on 14 October 2026.
Where your data goes
Nowhere outside Atlassian. The app declares no outbound network access, no remotes, no external backend, no analytics, no email and no third-party service, and it requests no content or external permissions, so the interface runs under Forge's default content security policy (no inline script, no eval, no external hosts). A test loads the production bundle under that policy and fails on any violation, script error or request to another host. Issue data is read by Forge functions through the Jira REST API, made into documents there, and written back to Jira as attachments, or kept for download in the app's storage for three days.
Forge storage follows the data residency of the host product (your Confluence or Jira site). Atlassian runs Forge functions on its own infrastructure and aims to run them in the same region.
What is stored
The app stores data in Forge hosted key-value storage only (no SQL, no object store, no custom entities). Documents made for a single issue are not stored: they go to the browser and to the issue's attachments, which belong to the customer.
| Data | Why | How long |
|---|---|---|
| Templates: the Word files uploaded by administrators, name, description, file name pattern, language, field hints, and the account ids of the people who created or changed them | The template library | Until an administrator deletes the template or the app is uninstalled |
| Job records: the JQL query, template name, values typed in, formats, counters and notes, and who started the job (account id, display name, email address, language, time zone) | Run and show bulk jobs, act as the person who started the job, fill the {user.*} fields | 14 days after the job's last change, or until the user or an administrator deletes the job |
| Issue data collected for a combined document or a spreadsheet (the fields the template or the chosen columns need) and the issue keys of a job | Make the combined document or spreadsheet | Deleted as soon as the job is done; for a job that failed or was stopped, up to 14 days after its last change, so that it can be resumed |
| What happened to each issue of a documents job: issue key, file names, messages | Show the result | 14 days after the job's last change |
| Generated files of a combined document or spreadsheet job | Download on the Jobs page | 3 days |
| Unfinished template uploads | Assemble an uploaded file | 2 hours |
| Bookkeeping of the weekly personal data report | Operation | Until uninstall |
Personal data
Atlassian account ids (job owners, template authors) and, for the person who starts a job, their display name and email address for at most 14 days. These are needed for the {user.*} fields of templates. Issue content that passes through the app may contain personal data and is kept only as the table above describes. A daily scheduled function reports the stored account ids to Atlassian's personal data reporting API at most every seven days. For accounts reported as closed, the app erases their jobs and removes their ids from templates.
Permissions
Every permission the app requests, and why. The scopes are granular unless the table says otherwise.
| Scope | Why the app needs it |
|---|---|
storage:app | Forge storage on your site for templates and jobs |
read:issue:jira read:issue-details:jira read:issue-meta:jira read:issue-security-level:jira read:issue.vote:jira read:issue.changelog:jira read:status:jira | Read the issue (fields, status, history) and search issues by JQL for bulk jobs and spreadsheets. Atlassian lists all of these for the get issue and search operations; the app uses the data that templates ask for. |
read:comment:jira read:comment.property:jira | Read comments for comment loops, only when a template uses them |
read:issue-worklog:jira read:issue-worklog.property:jira | Read work logs for work log tables and totals, only when a template uses them |
read:field:jira read:field.default-value:jira read:field.option:jira read:field-configuration:jira | List the fields of the site, so that custom fields can be used by name and offered as spreadsheet columns |
read:user:jira read:group:jira read:avatar:jira read:application-role:jira read:project:jira read:project-category:jira read:project-role:jira | Required by Atlassian for the operations above (people in comments and fields, the user's own profile and language, the project of an issue). The app uses names, email addresses, language and time zone; avatars are not used. |
read:permission:jira | Ask Jira whether the signed-in user is a Jira administrator (only administrators manage templates) |
read:attachment:jira write:attachment:jira | List the attachments of an issue (to avoid attaching the same file twice) and add the generated documents. Nothing is changed or deleted. |
report:personal-data | Report stored account ids to Atlassian's personal data reporting API |
That is 25 granular Jira scopes, plus Forge storage and personal data reporting. The app reads, and its only write is adding files to issues. Offline user impersonation (allowImpersonation) is enabled on all Jira scopes except read:permission:jira, because bulk jobs run in the background after the user has left the page. They act as the user who started the job, so Jira's own permissions decide what is read and where files can be attached.
Access control
Every Jira request is made with the identity of the user. A user who cannot see an issue gets an error and no content. Templates can be read by all licensed users and managed only by Jira administrators, checked on the server. A person sees only their own jobs; administrators can list all jobs. The license is checked in the Forge function for every request from the interface and for every automation run, and fails closed in production. A bulk job that has already started finishes.
Untrusted input
Word templates and everything in Jira are untrusted input. Uploaded files are opened by a safe reader that refuses macro-enabled files, old .doc and password-protected files, zip bombs, unsafe part names and oversized files, and are checked structurally. Template tags are parsed by our own expression parser (no eval, no inherited properties, forbidden keys). Rich text from Jira is converted structurally, never as HTML. Spreadsheet cells that look like formulas are stored as text, and file names are cleaned. Automated tests cover hostile templates and values.
Dependencies
Thirteen third-party packages are bundled (docxtemplater core, pizzip, pdf-lib, fontkit, SheetJS Community Edition, xmldom, Preact, lodash, pako, tslib and others), all under permissive licenses. The build fails if a package with another license appears. The Roboto font (Apache License 2.0) is embedded for PDF output. The list with license texts ships with the app. No paid modules are used.
Other points
Jira Automation
The Generate document from template action runs as the user that the platform runs the rule as, and as the app itself when the platform has no user for that run. In that one case the permissions of the app apply instead of a user's. The customer decides which rules use the action.
Logging
Error class and message only. Issue content, template content and values typed by users are never logged.
Encryption
Data in transit and at rest is protected by the Atlassian Forge platform. The app has no database or storage outside Forge.
Sub-processors
None besides Atlassian.
AI and language models
None. The app does not use Forge LLM and sends no content to any model.
Vulnerabilities and incidents
We fix vulnerabilities within the windows Atlassian requires of Marketplace apps (critical: 10 days, high: 4 weeks, medium: 12 weeks, low: 25 weeks) and tell Atlassian about security incidents within 48 hours. Dependencies are checked for known vulnerabilities before each release.
Report a vulnerability to support@karelialabs.atlassian.net. Please include what you found, how to reproduce it and which app and version are affected, and give us a reasonable time to fix it before you publish details.
Deleting data
Administrators delete templates. Users delete their own jobs, and administrators can delete any job, which removes its files. Everything else expires by itself (see the table). Uninstalling removes the app, and Atlassian removes its storage under its retention rules. Documents attached to issues stay with the customer's issues.