Privacy Policy

Last updated 4 August 2026. Applies to the Routine app for Jira Cloud.

The short version. Routine runs entirely inside Atlassian's own infrastructure. It declares no external permissions, so it cannot send your data anywhere outside Atlassian. We do not receive, see, sell, or store your Jira data on our own servers, because we do not operate any servers for this app. Unlike a read-only app, Routine does create issues in Jira, which is its entire purpose; exactly what that means is set out below.

Who is responsible

This app is provided by Abdullah Khalfi (Ranzo Apps), Freiburg im Breisgau, Germany. For any privacy question or request, write to support@clientportal-platform.com. For your Jira data, your organisation is the data controller and we act as a processor limited to what is described below.

Where the app runs

Routine is an Atlassian Forge app. Its code executes on infrastructure operated by Atlassian, and its storage is Atlassian's app storage, inside your Atlassian site's own data residency arrangements. The app's manifest contains no external permissions block, which means the platform itself blocks it from making requests to any domain outside Atlassian.

What the app reads and writes

The app requests the minimum Jira scopes it needs to create scheduled work:

Scope	Why it is needed
`read:jira-work`	To list the projects you can browse and read each project's issue types, components and priorities, so the rule editor can offer real choices instead of asking you to type identifiers.
`write:jira-work`	To create the issues your rules describe, and their subtasks. This is the purpose of the app.
`read:jira-user`	To offer the list of people who can be assigned issues in a project, to check whether the person using the app is a Jira administrator, and to read your profile timezone so a new rule starts with the right one.
`storage:app`	To save your rules and their run history (see below).

What the app writes to Jira, precisely

Routine creates new issues, and optionally their subtasks, exactly as described by a rule an administrator wrote. It sets only the fields on that rule: project, issue type, summary, description, assignee, priority, labels, components and due date.

It never edits, transitions, comments on, or deletes any existing issue. It never touches an issue it did not create. Issues are created by the app itself rather than by the administrator who wrote the rule, so a rule keeps working after that person changes teams or leaves the company.

What the app stores

Your rules: everything you typed into the rule editor, including the summary and description text that will become the issue. Where a rule names an assignee, only that person's Atlassian account identifier is stored, never their name or email address; the name you see in the app is read from Jira each time it is shown.
Run history: for each rule, the last 30 runs, with the date, the key of the issue created, and the reason for any failure.
A run marker per rule: the last date a rule ran, which is how the app guarantees it does not create the same issue twice in one day.
A review-prompt marker: whether an administrator has answered or postponed the one-time question asking how the app is going.

No issue content is copied into storage beyond the rule text you wrote yourself and the issue keys in the run history. Everything above is stored in Atlassian Forge storage, scoped to your installation.

What the app never does

No data is sent to us or to any third party. The app has no network egress.
No analytics, telemetry, advertising, profiling, or tracking of any kind.
No AI or machine-learning processing of your issues, and no training on your data.
No selling or sharing of personal data. We never receive it in the first place.
No email is sent by the app.
No modification or deletion of issues that already exist.

Who can see what

Rules are visible only to Jira administrators, because a rule can describe work in any project on the site and the app cannot know which projects a given reader is allowed to see. Everyone else simply sees the created issues appear in Jira, governed by Jira's own permissions as usual. When the editor lists projects or assignable people, those lookups run as the administrator using it, so they see only what Jira already allows them to see.

Retention and deletion

Data is kept only while the app is installed. When an administrator uninstalls Routine, Atlassian removes the app's storage for that installation, and every rule and its history go with it. Deleting a rule inside the app deletes its history immediately. Issues that Routine already created are ordinary Jira issues and remain in Jira, under your control, exactly as if a person had created them.

Your rights

Under the GDPR and similar laws you may request access to, correction of, or deletion of personal data, and may object to processing. Because all data lives inside your own Atlassian site, the fastest route is usually your Jira administrator. You can also write to support@clientportal-platform.com and we will respond within 30 days.

Sub-processors

Atlassian Pty Ltd, as the operator of the Forge platform and the storage the app uses. There are no others.

Security

The app holds no credentials of its own and stores nothing outside Atlassian, which removes most of the ways an app like this can leak data. Access to Jira is mediated by the Forge platform under the scopes listed above, and only Jira administrators can create or change a rule. If you believe you have found a security issue, please write to support@clientportal-platform.com and allow us a reasonable window to fix it before disclosing it publicly.

Changes

If this policy changes in a way that affects what the app reads, writes or stores, the updated date above will change and the new version will be published here before the change takes effect.