Privacy policy

In short

• The app runs entirely on Atlassian’s platform (Forge). I don’t run any servers or databases for it, and nothing leaves Atlassian.
• It reads issues from Jira as the person viewing, each time a schedule opens, and never stores issue summaries, descriptions or comments.
• It stores view settings, site settings and a history of date write-backs in your site’s app storage, with the Atlassian account IDs of the people who own views, change settings or write dates.
• It writes to Jira only the start and due dates someone previews and confirms.
• There are no analytics, no tracking, no cookies and no ads, and I never sell or share your data.

Who this policy covers

This policy covers the Jira Cloud app Estimate Scheduler (“the app”), offered on the Atlassian Marketplace by Christian Ortiz, an individual publishing as Christian Ortiz Studio (“I”, “me”). It explains how the app handles data on the Jira sites where it’s installed, and how I handle the information Atlassian and you share with me.

It doesn’t cover Jira itself, or Atlassian’s own processing of your data, which is governed by Atlassian’s privacy policy.

Questions about this policy: support@christianortiz.studio.

Where the app runs

The app is built on Atlassian Forge, which means its code runs on Atlassian’s infrastructure and its data is kept in Atlassian-hosted app storage that belongs to your Jira site.

• The app declares no external servers and makes no network requests outside your Jira site. Its screens load nothing from third parties: no scripts, fonts or images from elsewhere.
• I have no database or server of my own that holds your data.
• Data residency. Forge hosted storage follows your site’s data residency: if your Jira site is pinned to a location (such as the EU, US, Australia or Germany), the app’s stored data is kept there too, and it moves with your site if the site is migrated. The app keeps all of its data in Forge hosted storage and has no remotes or outbound requests, so it qualifies without any extra setup. Atlassian aims to run the app’s code in the same location but doesn’t guarantee it, so processing in memory may occasionally happen elsewhere within Atlassian’s infrastructure.

What the app reads

The app works only within your Jira site, and only reads what it needs:

• Issues, as the person viewing, so everyone sees only what Jira lets them browse: key, summary, project, issue type, parent, assignee, status, rank, original estimate, time spent, story points, start and due dates, and links. They’re read each time a schedule loads and shown on screen; summaries and assignee names aren’t stored.
• Projects, saved filters and JQL results, as the person viewing, to build each view’s issue list.
• Field and link type definitions, as the app, to detect your start date, due date, story points and estimate fields and the dependency link type.
• Whether you’re a Jira administrator, to decide who can change site settings and delete shared views.
• Issue update events from Jira: when an issue changes, Jira tells the app which fields changed. The app checks only whether the estimate, story points, links, start date or due date of an issue it has written dates to changed, and if so marks those dates out of date. It makes no Jira calls for this.
• The license state Atlassian gives it, to decide whether views can be edited.

What the app writes to Jira

Only when someone chooses Write dates to Jira, reviews the preview and confirms, the app updates the start date and due date fields of the selected issues, as that person, so Jira’s permissions and issue history apply. It never creates or deletes issues, and writes nothing on install or when a view opens.

What the app stores, and for how long

Everything below is kept in your site’s Atlassian-hosted app storage.

• Views: each view’s name, visibility (private or shared), issue source (project keys, a saved filter’s ID, or the JQL text), schedule start date and anchor mode, working calendar, points-to-hours ratio, zoom, columns, hidden projects and issue keys, collapsed rows, a revision number, when it was created and last saved, and the account ID of its owner. Kept until the view is deleted.
• Site settings: the detected and overridden field IDs, the dependency link type, non-working dates, defaults for new views, when fields were last detected, and the account ID of the administrator who last changed them. Kept while the app is installed.
• Write-back runs: for each confirmed write, its view, the account ID of the person who ran it, when it started and finished, its status, counts, and for each failed issue the issue key, Jira’s status code and Jira’s error message. Deleted 180 days after the run, by a weekly clean-up.
• Written dates: for each issue the app wrote to, the issue ID and key, the view and run, the start and due dates written, the estimate and story points at the time, whether the dates are now out of date and why, and when they were written. Deleted 180 days after they were written, or when the view is deleted.
• Per-person records, keyed by account ID: whether the person has seen, finished or skipped the tour, and the view they last opened. Kept while the app is installed, unless the account is closed.
• App bookkeeping: when the personal data report last ran.

The app doesn’t store issue summaries, descriptions, comments, attachments, or people’s names, email addresses or profile pictures.

Personal data

Atlassian account IDs are personal data. View names and JQL text may also contain personal data that your team types into them (for example a JQL query naming an assignee); the app handles them only as described here.

Once a week, the app sends the account IDs it stores to Atlassian’s personal data reporting service, as Atlassian requires. When Atlassian reports that an account has been closed, the app deletes that person’s tour record, preferences and private views (with their written-date records), and replaces their account ID with deleted-user in shared views they owned and in write-back runs. It also removes their account ID from the site settings.

Logs

Atlassian gives me access to the app’s logs and usage metrics so I can keep it working. The app’s own code writes no log lines. Atlassian’s runtime records each time a function runs and, if a function fails unexpectedly, the error message, which could include an error message from Jira. Errors you see on screen, such as a failed write, are shown to you and kept in the write-back run as described above, not logged.

Who’s responsible for your data

• For the content and account IDs the app handles on your Jira site, your organization is the controller and I’m the processor: the app processes them only to do what your users ask. The data processing agreement sets out the terms and applies automatically.
• For the licensing and contact details Atlassian shares with me, and for support emails you send me, I’m the controller.
• Under the California Consumer Privacy Act, I’m your organization’s service provider. I don’t sell or share personal information.

What I receive, and what I don’t

I don’t receive your issues, your schedules or anything else from your Jira site. The app has no way to send them to me.

When your organization installs, evaluates or buys the app, Atlassian shares licensing information with me, which can include your site address, organization name, and the names and email addresses of technical and billing contacts. I use it only to manage licenses, provide support and send notices that matter (such as security notices), and I keep it only as long as I need it for those purposes and for my legal and tax records.

If you email me for support, I keep your message and email address to help you and to improve the app. I’ll delete them on request unless I need to keep them by law.

Sharing

I don’t sell, rent or share your data with anyone. The only sub-processor is Atlassian, which hosts the app’s code and storage on Forge under the Forge Data Processing Addendum. There are no other third parties. I’d disclose information only if the law required me to.

Security

• The app asks Atlassian only for the access it needs: reading Jira work, updating issue dates, its own storage, and personal data reporting. It requests no credentials and holds no tokens of its own.
• Issues are read and written as the person using the app, so Jira’s own permissions decide what each person can see and change. Field and link type detection is the only thing done as the app.
• Every change is checked on the server: the license, who may change site settings or delete a shared view, and the data itself, which is validated before anything is stored or written. Write-backs are limited to start and due date fields, in batches, and only for issues the person selected.
• Conflicting saves of a shared view are detected instead of silently overwriting each other.
• Security contact: email support@christianortiz.studio with Security in the subject line. I acknowledge security reports within two business days.
• I don’t hold security certifications of my own, such as SOC 2 or ISO 27001. The app’s code and data run on Atlassian’s infrastructure, which Atlassian’s own audits cover.
• If I learn of a security incident that affects your data, I’ll tell affected customers without undue delay.

Deleting your data

• Views can be deleted at any time with Delete view, which also deletes their written-date records.
• Write-back history is deleted 180 days after each run.
• Closed accounts are erased automatically, as described under Personal data.
• Uninstall the app to remove all of its data from your site. Atlassian then deletes the app’s storage under its data lifecycle for Forge hosted storage: the data is soft-deleted when the app is uninstalled and kept for 28 days, then permanently deleted. Reinstalling doesn’t bring it back on its own; within the first 21 days it can be reconnected to a reinstalled app only if your organization asks for that. I don’t keep a copy.
• Ask me at support@christianortiz.studio with your site address, and I’ll help and confirm what was removed.

Dates the app wrote to Jira are part of your issues. They stay in Jira, with Jira’s own history, after the app is removed.

Your rights

Depending on where you live, you may have the right to access, correct, delete or move your personal data, or to object to how it’s used. Because the app’s data lives in your organization’s Jira site, the quickest route is usually through your site admin, but you can always email me and I’ll respond within 30 days.

For content in your Jira site, your organization decides what’s stored and why; the app processes it only to provide the schedules your users build. The data processing agreement applies to that processing.

Children

The app is a business tool and isn’t directed at children.

Changes to this policy

If I change this policy, I’ll update the date at the top of this page. If a change affects how your data is handled in a meaningful way, I’ll also say so in the app’s release notes or Marketplace listing before it takes effect.

Contact

Christian Ortiz, publishing as Christian Ortiz Studio
support@christianortiz.studio