Spreadsheet Lookup Fields for Jira

1. Overview

This Privacy Policy describes how the vendor of Spreadsheet Lookup Fields for Jira handles data when customers install and use the app from the Atlassian Marketplace.

The app is an Atlassian Forge app for Jira Cloud. It lets Jira administrators create spreadsheet-backed lookup catalogs, publish those catalogs as Jira custom fields, search selected catalog values, and configure a workflow post-function that can set, copy, or clear a Spreadsheet Lookup field after a workflow transition.

Atlassian Marketplace documentation refers to customer data processed by Marketplace apps as End-User Data. This policy explains the app's access to, collection of, processing of, storage of, sharing of, and deletion behavior for that data.

2. Customer and Vendor Roles

The Atlassian customer controls the Jira site where the app is installed and decides what data is entered into Jira and into the app's catalogs.

For data entered by or on behalf of the customer, the customer is typically the controller and the app vendor processes that data to provide the app. Customers are responsible for ensuring they have the rights, permissions, and notices required to enter data into Jira and into the app.

This policy does not replace Atlassian's own privacy policy, Atlassian Cloud terms, or the customer's internal privacy obligations.

3. Data the App Processes

Catalog administration data

Jira administrators can create and manage catalogs. The app stores:

• catalog names, keys, descriptions, health state, and picker level count;
• spreadsheet or CSV column headers;
• source rows imported or pasted by administrators;
• level mappings that define which spreadsheet columns become picker levels;
• generated catalog options, parent-child relationships, paths, and published catalog versions;
• draft catalog changes that have not yet been published;
• manual options added, renamed, or deleted by administrators;
• a snapshot of the catalog's published state, taken when a catalog is published, so an administrator can discard later draft changes and return the catalog to the published version. The snapshot holds the level mapping, level count, headers, catalog details configuration, and a copy of the source rows as they were at that publish. One snapshot is kept per catalog and it is replaced on every publish.

Import data and import history

During import and update flows, the app stores normalized import session rows, detected delimiter, headers, row counts, generated option counts, validation summaries, import source type, import history, and the Atlassian account ID of the administrator who created an import session.

Raw pasted text and uploaded CSV files are parsed by the app and stored as normalized table rows. The app does not store uploaded files as separate file attachments.

Jira field configuration data

When a catalog is connected to a Jira custom field, the app stores the Jira custom field ID, key, display name, the link between the Jira field and the catalog, and field context configuration required for the Spreadsheet Lookup field to render and read the published catalog.

Jira issue field data and search index data

When a user selects a value in a Spreadsheet Lookup field on a Jira issue, Jira stores the selected field value. The app also stores a compact Jira issue entity property named catalogfield so the value can be searched with JQL.

The search index property contains only the catalog-field search data needed for JQL, such as catalog names, selected leaf values, level values from Level 1 through Level 5, path tokens, and searchable path text. Index text is truncated to the app's configured indexing limit.

Workflow post-function configuration and runtime data

Jira administrators can configure the workflow post-function Set Spreadsheet Lookup field for company-managed workflows. The configuration can include target field ID, action mode, source field ID for copy mode, and the selected fixed catalog value for fixed-value mode.

At runtime, the post-function reads only the issue and Spreadsheet Lookup fields needed to apply the configured action and then updates the target issue field and the app's search index property.

Browser session data

The admin interface uses tab-scoped browser sessionStorage to remember the active view and import session ID while the administrator works through the import flow. The app does not use persistent browser storage for raw catalog rows or raw source text.

Activation metrics

The app uses Atlassian Forge custom metrics counters to count setup milestones such as opening onboarding, using example data, validating an import, publishing a catalog, linking a field, saving a first value, or enabling a catalog for the customer portal. These counters do not include catalog values, issue content, spreadsheet rows, names, emails, or other customer-entered catalog data.

4. How the Data Is Used

The app processes data to:

• create and maintain spreadsheet-backed Jira lookup catalogs;
• validate pasted or uploaded table data;
• generate dependent picker options from spreadsheet columns;
• publish catalog versions for Jira fields;
• render the Spreadsheet Lookup field on Jira issue Create/Edit/View screens;
• connect catalogs to Jira custom fields;
• update the Jira issue property used for JQL search;
• support the catalogValue(...) JQL function and indexed search aliases;
• configure and run the workflow post-function;
• show import history and help administrators understand previous imports;
• enforce app limits, permissions, and catalog integrity;
• count high-level setup milestones with Atlassian Forge custom metrics counters.

The current app does not use customer catalog data or Jira issue field data for advertising, tracking, third-party analytics, AI model training, or unrelated product research.

5. Storage and Data Location

The app stores data in Atlassian-hosted services used by Forge and Jira:

• Forge SQL for catalog data, source rows, generated options, published versions, published state snapshots, import sessions, import history, and field links;
• Jira custom field values for values selected on issues;
• Jira issue entity properties for the app's compact JQL search index.

The current app manifest does not declare external egress, remotes, or web triggers. The app runtime does not send customer catalog data or Jira issue field data to vendor-controlled servers or third-party analytics services.

Data location, residency, backup, and infrastructure controls for Forge and Jira-hosted data are governed by Atlassian's cloud and Forge platform behavior for the customer's Atlassian site.

6. Sharing and Subprocessors

The app does not sell customer data.

The current app runtime does not share customer catalog data or Jira issue field data with advertising networks, analytics providers, AI services, or vendor-hosted external services.

Customer data processed by the app remains in Atlassian-hosted Forge and Jira services. Atlassian processes that data as the platform provider under the customer's Atlassian agreements.

Vendor personnel do not automatically receive customer catalog data through the app. If a customer chooses to send diagnostic information, screenshots, exports, or issue details to the vendor for support, the vendor processes that support information only to provide support and resolve the request.

7. Retention and Deletion

The app keeps data while it is needed to provide the configured functionality.

• Deleting a catalog deletes the catalog's rows, generated options, published versions, option index, published state snapshot, import configuration, import sessions, import history, customer portal sharing setting, and field links managed by the app.
• A catalog cannot be deleted while it is linked to a Jira field.
• Discarding an import session deletes its stored session rows.
• Successful create or update flows delete staged import session rows after canonical catalog source rows have been written.
• Unfinished import sessions are tied to the creating administrator's Atlassian account ID.
• Import sessions older than 24 hours are purged opportunistically when a new import starts.
• The app retains the latest 250 import history records per catalog.
• Selected Jira issue field values remain in Jira until changed, cleared, deleted, or otherwise handled according to Jira and customer configuration.
• The app's catalogfield issue property is updated when the app saves or syncs Spreadsheet Lookup values and is removed when no Spreadsheet Lookup values remain in that issue property.

Atlassian controls the lifecycle of Forge-hosted app storage when an app is uninstalled. Customers should follow Atlassian and Jira administration controls for app uninstall and app data lifecycle questions.

8. Atlassian Permissions

The app currently requests these Atlassian scopes:

The app does not request external egress permissions.

9. Security

The app is designed to keep customer data inside Atlassian-hosted Forge and Jira services.

Current security controls include:

• no declared external egress, remotes, or web triggers in the app manifest;
• no app-managed API tokens, passwords, or external service credentials;
• Jira ADMINISTER permission checks before catalog administration data is read or changed;
• Jira EDIT_ISSUES permission checks before user-initiated issue property sync writes;
• catalog options are readable from a Jira Service Management customer portal only after an administrator shares that specific catalog, which is off by default, with the row's extra detail columns behind a second, separate switch;
• that decision is made on the server on every read, from the account type Atlassian Forge reports for the caller, so a client cannot assert its own access;
• import session ownership checks using the creating administrator's Atlassian account ID;
• server-side validation of catalog IDs, Jira field IDs, workflow post-function configuration, fixed option values, target-field catalog links, and copy-mode source field values;
• published catalog versions are used by Jira-facing picker, search, and workflow runtime behavior;
• draft catalog changes stay in the admin interface until an administrator publishes them;
• prepared SQL statements with bound parameters for database access;
• compact issue-property payloads that store only the search data needed for the app's JQL behavior.

No security measure is perfect. Customers should configure Jira permissions, workflow administration rights, and screen schemes according to their own security requirements.

10. Customer Portal Access

The Spreadsheet Lookup field can be used on Jira Service Management customer portal request forms. Those customers hold no Atlassian product licence, and they can include people outside the organisation running the service desk, so this access is granted by an administrator rather than assumed by the app.

• Portal access is off for every catalog by default, including every catalog created before this capability existed. No catalog became readable as a result of an app upgrade.
• An administrator shares a catalog explicitly, one catalog at a time, and the app states who gains read access before the change is saved.
• Sharing the picker options and sharing the selected row's extra detail columns are separate choices. Detail columns are removed on the server when they are not shared.
• Portal customers can read the options of a shared catalog and nothing else. Catalog administration requires Jira ADMINISTER, and writing the app's search-index issue property requires Jira EDIT_ISSUES.
• Removing sharing takes effect on the next read. Values already stored on existing requests are not changed.

11. Customer Controls and Rights

Customers can use Jira and app administration controls to:

• create, update, publish, and delete catalogs;
• discard unfinished import sessions;
• clear or change Spreadsheet Lookup field values on Jira issues;
• remove a Spreadsheet Lookup field from Jira screens;
• uninstall the app from the Jira site.

Requests about access, correction, deletion, export, or restriction of personal data should normally be directed first to the customer's Jira administrator. Customers may also contact the vendor using the privacy or support contact provided on the app's Atlassian Marketplace listing.

12. Sensitive Data

The app is designed for reference data used in Jira fields, such as services, departments, environments, applications, categories, and ownership lists.

The app does not require customers to enter special category personal data, payment card data, government identifiers, passwords, or secrets. Customers should not enter such data into catalogs unless they have determined that it is appropriate under their own policies and legal obligations.

The app is intended for business use in Jira Cloud. It is not directed to children.

13. Changes

The vendor may update this Privacy Policy when the app changes or when legal, security, or Marketplace requirements change. The published policy should show the effective date of the current version.

14. Contact

For privacy questions, security reports, and support requests, use the contact details provided on the app's Atlassian Marketplace listing or the public support portal at https://drinkits.atlassian.net/servicedesk/customer/portal/100.

For a shorter operational overview, see Trust and support. For product setup and administration, see the user and administrator guide.