Data & privacy

This page answers the two questions every admin asks before installing an app: what does Linker store, and where does the data go? The short answer: very little, and it never leaves Atlassian.

What Linker stores

Field values: the lists of work item keys, stored by Jira itself like any custom field.
Which links the app created: so the safe delete mode can tell app-made links apart from hand-made ones and protect the latter.
Your settings: the per-context configuration, the panel definitions and, for panels where viewers choose their own columns, each viewer's personal column pick.
Who created a panel: the Atlassian account id of whoever created a panel definition, so an administrator can see who to ask about it. The display name is never stored, it is looked up from Jira when the list is drawn. Panels created before this existed carry no author.

Technical details

Link ownership is stored as link IDs in Atlassian Forge storage. Per-context configuration and the panel definitions live in Atlassian-managed storage as well, and so does each viewer's personal column pick, keyed by panel and Atlassian account id. A panel definition additionally carries the account id of its creator and, when a space built it, the id of that space. All storage stays inside Atlassian's infrastructure.

Who may link what

Two questions come up in every security review, and neither has the obvious answer.

Which permission gates a link

The permission scheme kept Jira's older names. Jira's interface says work item and space, but the entries in a permission scheme were not renamed with it. So you look for Edit Issues, Link Issues, Create Issues, Browse Projects and Administer Projects, spelled exactly like that, and this page names them the way you will find them there.

When a Linker field creates or removes a native link, that link is written with the app's permission, not the person's. So Jira's Link Issues permission is not what stands between somebody and a link. What stands there is being able to change the field, which means Edit Issues on the work item.

Action	Link written as	What the person needs
Picking in the field and saving	The app	Edit Issues. Jira enforces it when it stores the field value.
The + or × on a field panel	The app	Edit Issues. Here the app asks Jira whether the caller has that permission and refuses with its own message if not.
The + or × on a link-type panel	The person	Link Issues, enforced by Jira itself on the call.
A status change in a panel	Not a link	The transition runs as the person, so the workflow and their permissions decide.
Editing a cell in a panel	Not a link	The edit is written as the viewer, one field at a time, so Jira decides whether they may edit that work item and whether the field is on its edit screen. See Work item panels.
Sync, resync, the safety net, the repair on display	The app	Nothing. No person is asking.

What follows from that. Taking Link Issues away from a role does not stop them creating links through a Linker field. To control who links what through a field, use the field's context, the screens it sits on, or the edit permission itself. The link-type panel is the one place where Link Issues really is the gate.

Who may change the configuration

Reading an admin page and writing to it are two different questions, and Linker asks the second one on every write, in the caller's name. Being shown a page is never taken as permission to save from it.

What is being changed	Who may
Fields, field contexts, global panels, and the switch that allows space panels	A Jira administrator. Linker asks Jira for the site-wide administration permission, as the caller.
The panels of one space, in that space's settings	Whoever holds Administer Projects on that space. The space is taken from where the call arrived, not from what the caller sent, so the permission is always checked against the space that will actually be written.
An existing space panel, from the admin area	A Jira administrator, for editing and deleting. Its space cannot be changed and it cannot become a global panel, so a panel never loses its owner. See Space panels.

Which links the app will delete

In the default delete behavior, Only delete links created by the app, Linker removes a native link only when it recorded that link as its own. A link it merely found is never recorded, so the following all survive deselection, by design:

Links somebody created by hand in Jira's own Linked work items section.
Links a resync adopted into a field.
Links created by the + on a link-type panel, which are the person's links, not the app's.
Links made by an Automation rule, a CSV import, a bulk edit or the REST API, where the link itself was created outside the app.
Links a clone brought with it. When Jira clones a work item and copies the Linker field value and the links, everything the field wants is already there, so the app has nothing to create and records no ownership. Deselecting on the clone then clears the field value but leaves the native link, and reverse sync brings the value back. If the clone copied the value but not the links, the app creates them itself and owns them as usual, so whether a cloned link can be removed depends on what Jira's clone dialog copied.

To remove any of these, delete the native link itself, or switch that context to the mirror mode Delete all links of the configured type. See Delete behavior.

What Linker never does

No data leaves Atlassian's infrastructure: the app talks to no outside servers (eligible for Atlassian's Runs on Atlassian program).
No tracking, no third-party services, no personal data beyond what Jira already shows (e.g. assignee display names, shown live from Jira).

Uninstalling the app removes its stored data, following Atlassian's standard data lifecycle for apps. Field values remain in Jira (they belong to the field) until the field itself is deleted.

See also the general Garhe Solutions privacy policy.