Security

How Haulcopy runs

Haulcopy runs on Atlassian Forge, inside the customer’s Jira Cloud site. Haulcopy has no servers of its own.

Scopes

The app asks for three scopes:

• read:jira-work, with impersonation. A schedule and a queued export search as the user who owns them, so issue security and project permissions still apply. The app does not search as itself.
• storage:app. Files, job records, presets, and schedules stay in that installation’s Forge storage.
• report:personal-data. Once a week the app reports the account ids it has stored.

The app does not request email, user administration, or permission to edit issues.

What is stored

All of this stays in Forge hosted storage on the customer’s site. Haulcopy does not keep a second copy.

• Export files: the Jira field values the user selected.
• Job records: the JQL, field ids, formats, status, size, timestamps, and the Atlassian account id of the person who ran it.
• Presets and schedules: the name, JQL, fields, formats, cadence, timezone, and the owner’s account id.
• PDF branding: a title and a logo.

The app does not store account emails, display names as profiles, or passwords.

How long it is kept

• Export files are kept for 7 days, then the object expires. Download them from History before then. The app cannot rebuild an expired file. History rows cannot be deleted.
• A download link is created when you click download. It lasts one hour.
• Presets and schedules stay until a user deletes them, or until uninstall. Job records stay until uninstall.
• After uninstall, the app cannot read that storage, and a reinstall does not restore it. Atlassian soft-deletes Forge hosted storage and keeps that copy for 28 days. Haulcopy has no copy of its own.

The privacy policy is the full account of what is stored.

Data residency

End-user data is stored only in Forge hosted storage: the Key-Value Store and the Object Store. Both follow Forge data residency. The app has no remote backend, so it is eligible to pin with Jira. When an admin pins Jira, Forge moves that storage with it. Haulcopy does not offer its own region list. A function can sometimes run outside the pinned location. That is Atlassian’s compute, not a copy on a Haulcopy server.

Personal data

A job stores the Atlassian account id of the person who started it. A schedule stores the account id of the person who created it, and that owner stays if someone else pauses it. Those ids exist so the search can run as that person. The page does not show the raw id. It shows “You”, “You, from a schedule”, “Schedule owner”, or “Another person”.

The app does not store an email, a display name, or an avatar as a profile. If you include a user field such as Assignee, the file contains the display name Jira returned, for the 7 days the file is kept.

Once a week the app reports those account ids to Atlassian. Atlassian can then show Haulcopy on that person’s account profile. The account id unknown is never reported. If Atlassian says an account is closed, the app removes that id from schedules and from History. A schedule that belonged to the closed account is turned off and left in the list with no owner, so it does not run. History rows stay, without the id. A running export for that person is stopped. If Atlassian says the account was updated, the app keeps the id, because it does not store a name or email to refresh.

No servers of our own

This website is static. It does not receive issue data. The app has no remote backend, no external fetch, and no webtrigger. Export files are written in the Forge function and stored in Forge Object Store on the same site.

How to report

Email suspected vulnerabilities to security@haulcopy.com. Do not send an API token or a password. The target for a reply is within 24 hours. There is no paid bug bounty. Product questions go to support@haulcopy.com. See support.