How it works: data, storage & security
How Connected Table works under the hood — written for IT, security reviewers, and technical administrators evaluating the app.
Built entirely on Atlassian Forge
Connected Table is a Forge app. It runs inside Atlassian’s own cloud infrastructure — there is no external server, no third-party hosting, and no separate database. The app’s code executes on Atlassian-managed infrastructure and in your browser; nothing is deployed to or operated by the vendor outside Atlassian’s cloud.
Where your data is stored
Each table is stored in the Jira issue’s own field value (and, on Jira Service Management, in the portal request). It lives with the issue, inside your Jira instance, and is backed up, exported, and access-controlled exactly like any other Jira field data.
- No external or vendor-side data store is involved.
- The table travels with the issue (clones, exports, and the issue’s own history include it).
- Because the whole table is held in one field value, there’s a practical size ceiling of roughly 100–150 rows per table (depending on the number of columns and how much text each cell holds).
What the app can access
At install, Connected Table requests a small, mostly read-only set of permissions. In plain terms:
| Permission | Scope | Why it’s needed |
|---|---|---|
| Read Jira work | read:jira-work | To read the table from an issue and build the Connected Table History tab from the issue’s change log. |
| Read Jira users | read:jira-user | To power the user-picker column and show people’s names in the table and its history. |
| Read field configuration | read:field:jira | To find the Connected Table field’s contexts. |
| Read custom field context configuration | read:custom-field-contextual-configuration:jira | To load the column setup an administrator saved for each field context. |
| Write app data | write:app-data:jira | To save table edits into the app’s own Connected Table field. It can’t change any other issue field. |
The app does not request permission to edit issues in general, to manage Jira configuration, or to use app storage, and it accesses only Jira/JSM data granted at install — nothing outside your Atlassian environment.
Saves are made by the app on the user’s behalf, and only after the app checks the user’s own Jira permissions: Edit issues for agents on the issue panel, and access to the request for customers on the portal.
How it’s processed
The interactive grid and all in-table computation (formulas, aggregation, sequence numbering) run in your browser. There is no external computation service; formula evaluation is sandboxed client-side.
Export and import files
- Export (Excel, PDF, Word, CSV) builds the file in the user’s browser from the table on screen and saves it directly to their device. The file isn’t stored in Jira or anywhere else, and no copy is sent to the vendor.
- Import (CSV, Excel) reads the chosen file in the user’s browser. The file is never uploaded. Only the rows the user reviews and saves are written to the issue’s field — through the same save path, permission checks and validation as typing them in by hand.
- Text beginning with
=,+,-or@is neutralised in CSV and Excel exports, so data entered in the table (for example by a portal customer) can’t run as a spreadsheet formula when someone opens the file. - Neither feature needs extra permissions. Administrators can turn each one off per field.
Where the table appears
| Surface | Behaviour |
|---|---|
| Issue view — field cell | Click to edit inline. |
| Issue view — Apps panel | Always-on grid in the main content area (read-only → Edit → Save). |
| Activity — Connected Table History tab | Read-only, row/cell-level change log built from Jira’s own history. |
| JSM customer portal — request detail | Read/edit panel for customers and unlicensed users. |
Change history & auditability
Every edit to a table is captured in Jira’s own issue history, and surfaced as a readable row/cell-level diff in the Connected Table History activity tab. Nothing is stored outside Jira to make this work.
Updates
The app is delivered and updated through the Atlassian Marketplace / Forge app lifecycle. Administrators review and approve any permission changes as part of the standard upgrade flow.