Lineset
Menu

Blockline privacy policy

Last updated 4 October 2026

Blockline (“the app”) is a Jira Cloud app built on Atlassian Forge and published by Sugar Systems, SIA (registration number 40203386400), Stirnu street 5-29, Riga, LV-1035, Latvia (“we”, “us”). This policy explains what the app does with data when a Jira site administrator installs it. What the Lineset websites and the app’s waitlist keep is in the Lineset privacy policy, which covers every app.

What the app does

Blockline reads issues and the links between them in your Jira site, works out which issues are at risk because of work they wait on, and shows the result inside Jira. It reads on behalf of the person looking at the page, using their Jira permissions, so it never shows anyone an issue they could not open themselves.

Data the app processes

  • Issue data read from your Jira site: issue keys, summaries, issue types, hierarchy levels, parent links, status categories and the time of the last status category change, issue links and link types, due dates, Target end dates, sprint values, fix versions and their release dates, and the assignee’s display name and account id. This data is processed to judge dependency risk.
  • Spaces and saved filters you can open, to offer them as a scope.
  • Your Atlassian account id, used only to keep each person’s cached views, saved scope and risk history separate from everyone else’s.

The app processes no data from outside your Atlassian site.

Data the app stores

Everything the app stores lives in Forge storage, which is hosted by Atlassian inside the Atlassian cloud. The app stores six things:

  1. Computed views: the risk levels, reasons, keys, summaries, dates and owner names of the issues in a view, keyed by the viewer’s account id, one entry per person and view. Each entry is replaced every time the view is rebuilt, served for at most ten minutes and deleted by Forge storage about 11 minutes after it is written. A person’s entries are never served to anyone else.
  2. Saved scopes: the scope a person saved on the Apps page (space keys, a filter id or their own JQL), one entry per person.
  3. Settings chosen by your Jira administrators (link types and their direction, the order of date sources, thresholds, deliverable levels and an optional default scope of space keys), one entry per site.
  4. Site metadata: your site’s list of fields (ids, names and types), its issue types and its issue link types, one entry each for the whole site, so the app does not ask Jira for them on every view. It names no person. Each entry is deleted by Forge storage about an hour after it is written.
  5. Risk history: for each open deliverable (an epic, by default) a person has looked at, the days its risk level changed for that person, with the level and the names of the rules behind it (for example “12 Oct, At risk, late blocker”). It holds the deliverable’s issue key but no summary, date or name. At most the last 20 changes are kept per person and deliverable. It is written only when that person opens Blockline, never in the background, and it is never shown to anyone else, because risk is judged with each person’s own permissions.
  6. Last visit: for each board a person opens (a space’s Blockline tab, the Apps page, a dashboard gadget), the risk level and rule names of each deliverable the board showed them last time, so the board can mark what changed since. It holds issue keys but no summary, date or name, one entry per person and board.

The app stores no passwords, no API tokens and no data about people beyond what is listed above.

Where data goes

Nowhere. The app makes no network requests to any service outside Atlassian. It has no servers of its own, loads nothing from a CDN, uses no analytics or tracking, and shares nothing with third parties. It is built to meet Atlassian’s “Runs on Atlassian” requirements, Atlassian’s designation for apps with no data egress. The app’s logs carry no issue content, issue keys or account ids.

Retention and deletion

  • Computed views are served for at most ten minutes after they are built (less if an administrator changes the settings), and Forge storage deletes each one about 11 minutes after it is written. Forge removes expired entries in the background, so an entry can stay in storage for up to 48 hours after it expires; it is never served after ten minutes.
  • Site metadata is deleted by Forge storage about an hour after it is written (again, at most 48 hours later).
  • Risk history and last-visit entries are deleted by Forge storage 180 days after they were last written, so a deliverable or board nobody opens for six months is forgotten.
  • Saved scopes are kept until the person saves a different one.
  • All app storage is deleted by Atlassian when the app is uninstalled from your site.
  • We hold no copy of your data, so there is nothing for us to delete or return on request; your Atlassian administrators control it entirely.

Permissions the app asks for

  • read:jira-work: to read issues, issue links, fields, link types, spaces, saved filters and the viewer’s own permissions.
  • storage:app: to keep the cache, saved scopes, settings and each person’s risk history in Forge storage.

The app has no write permission: it cannot change an issue, a link or a setting in Jira.

Your rights and contact

The apps keep no copy of your Jira data outside your Atlassian site, so requests about it are handled by your Atlassian site administrators. For the waitlist, or questions about this policy, an app or the websites, contact our support site at https://sumline.atlassian.net/servicedesk/customer/portal/1 or by email at [email protected]. You can also complain to Latvia’s Data State Inspectorate (Datu valsts inspekcija).

Changes

We will update this page when an app’s data handling changes and note the date above. Material changes are also announced in that app’s Marketplace release notes.