Privacy and Data Collection Policy

The App creates tables from sources configured in Confluence macros. Depending on the source, the data can include personal or confidential information. When a table is rendered, the App retrieves the configured data, processes it through the Forge backend, and displays it in the Confluence macro. People who can view the relevant Confluence page may see the table, subject to the App’s source authentication and the applicable Confluence and external-service permissions. Choose source data and page permissions accordingly.

Macro configuration, such as source URLs, attachment references, resource identifiers, display settings, and authentication settings where applicable, is retained as part of the Confluence page or the App’s configuration so the table can be rendered again. This is different from storing the retrieved table contents.

Live Table from CSV and Live Table from JSON

The Live Table from CSV macro displays data from CSV or TSV sources. The Live Table from JSON macro displays data from JSON sources. Each macro can read a Confluence attachment or fetch data from a URL entered by a user.

For attachments, the App reads the configured file from Confluence to produce the table. The attachment remains subject to Confluence’s storage and access settings.

For URLs, the Forge backend requests the configured endpoint, with or without authentication according to the macro settings, and processes the response to render the table. The destination service receives the request, including the requested URL and any configured request headers or authentication information. Its handling of the request and any data supplied to it is governed by that service’s practices.

The URL can contain placeholders for the current Confluence page ID and the current user’s email address. If a user configures such a placeholder, its value is included in requests to the chosen endpoint. A configured URL, including its query parameters, may itself contain sensitive information; take care when setting it on a page.

For authenticated URL sources, a login and password or custom authentication header is encrypted using AES-256 with a secret key unique to the Confluence installation and saved in the page’s macro parameters. The key is held in encrypted Forge storage and rotated yearly. The encrypted authentication information is bound to the installation and the configured URL, excluding query parameters. Administrators can enable the Live Table from CSV & JSON: Prevent macro copy with credentials option in the Administration console so that users must re-enter credentials when a macro is copied to another page.

Live Table from Salesforce

The Live Table from Salesforce macro displays data from a connected Salesforce organization as a Confluence table. A Confluence administrator configures the Salesforce OAuth client ID and client secret, along with the organization's login, token refresh, and API domains. The administrator also approves the Salesforce domains that the App may contact using Forge customer-managed data egress.

Each user connects their own Salesforce account through OAuth. The App implements this OAuth flow itself because its Salesforce endpoints vary by customer; it does not use Atlassian Forge's external OAuth provider for Salesforce. Salesforce authentication information, including the OAuth client secret and per-user authorization credentials, is stored in Forge secret storage. The App also accesses basic Salesforce account profile information to identify the connected account. The App uses the user's Salesforce authorization to request the data selected in the macro: a preset, report, custom object, or the results of a custom SOQL query.

The selected Salesforce data is retrieved into the Atlassian Forge backend and processed there to render the table in Confluence. The App does not store or cache the retrieved Salesforce records, and it does not transfer those records to any service outside Atlassian. Depending on the selected objects, report, or query, the results may include personal or confidential information about contacts, customers, employees, or other people. The App retains the connection and macro configuration needed to request the selected data again; this configuration is distinct from the retrieved records. Users who can view the Confluence page may see the table when it renders, subject to the App's per-user Salesforce authentication and applicable Confluence and Salesforce permissions.

Live Table from SharePoint and OneDrive

The App provides a single macro for displaying data from an Excel, CSV, TSV, or JSON file stored in SharePoint or OneDrive. A user configures the macro by pasting the file's URL. The App uses Microsoft Graph to retrieve that file and displays its contents as a read-only table in Confluence.

Access uses per-user Microsoft OAuth managed by Atlassian Forge. The App requests the delegated Files.Read.All permission to read files available to the connected Microsoft account. Although this permission can allow access to other files that the account can read, the App uses it to retrieve the file whose URL was configured in the macro; it does not browse, search, or crawl unrelated SharePoint or OneDrive files. A page viewer uses their own Microsoft connection to retrieve the configured file and must have permission to access it.

When the macro renders, file metadata and contents needed to produce the table are retrieved through Microsoft Graph, processed transiently through the Forge backend, and returned to the macro for display. The App does not store or cache the retrieved file contents in its own storage. The file URL or identifier and other macro settings are retained as Confluence page configuration so the table can be rendered again. Retrieved file contents are not transferred to services outside Atlassian to provide this feature. The App does not create, modify, or delete files through this integration.

Microsoft OAuth access and refresh tokens are managed by Forge's external authentication service. They are not exposed directly to the App or stored in the App's own storage. The table shown to a viewer depends on that viewer's Microsoft authorization and access to the configured file, as well as the Confluence page permissions.

Live Table from GitHub

The Live Table from GitHub macro displays an Excel, CSV, TSV, or JSON file from a GitHub repository as a table in Confluence. A user pastes the file URL into the macro configuration. The configured file may be in a public or private repository.

Each viewer connects their own GitHub account through a GitHub OAuth App using OAuth managed by Atlassian Forge. The App requests GitHub's repo scope, which can grant read and write access to public and private repositories available to the connected account. The macro uses that authorization only to read the file identified by the URL configured on the Confluence page. It does not list, search, or crawl unrelated repositories or files, and it does not create, modify, or delete GitHub content. A viewer must have GitHub access to the configured file to render the table with their connection.

When the macro renders, the file contents and metadata needed to produce the table are retrieved from GitHub, processed transiently through the Forge backend, and returned to the macro for display. The App does not store or cache the retrieved file contents in its own storage or transfer them to services outside Atlassian. The configured file URL and other macro settings remain in Confluence page configuration so the file can be retrieved again. GitHub OAuth credentials are managed by Forge's external authentication service and are not exposed directly to the App or stored in the App's own storage.

Live Table from GitLab

The Live Table from GitLab macro displays an Excel, CSV, TSV, or JSON file from a GitLab repository as a table in Confluence. A user pastes the file URL into the macro configuration. The file may be in a public or private project.

Each viewer connects their own GitLab account using OAuth managed by Atlassian Forge. The App requests GitLab's read_repository scope, which permits read access to repositories available to the connected user, including private projects they can access. The macro uses that authorization only to retrieve the file identified by the URL configured on the Confluence page. It does not list, search, or crawl unrelated projects or files, or create, modify, or delete GitLab content. A viewer must have GitLab access to the configured file to render the table with their connection.

When the macro renders, the file contents and metadata needed to produce the table are retrieved from GitLab, processed transiently through the Forge backend, and returned to the macro for display. The App does not store or cache the retrieved file contents in its own storage or transfer them to services outside Atlassian. The configured file URL and other macro settings remain in Confluence page configuration so the file can be retrieved again. GitLab OAuth credentials are managed by Forge's external authentication service and are not exposed directly to the App or stored in the App's own storage.

Live Table from Dropbox

The Live Table from Dropbox macro displays an Excel, CSV, TSV, or JSON file from Dropbox as a table in Confluence. A user pastes a Dropbox file URL into the macro configuration. The file may be accessible only to authorized Dropbox users.

Each viewer connects their own Dropbox account using OAuth managed by Atlassian Forge. The App requests the sharing.read and files.content.read scopes to read the configured file's sharing information and contents. The macro uses these permissions only to retrieve the file identified by the URL configured on the Confluence page. It does not list, search, or crawl unrelated Dropbox files, or create, modify, or delete files or their sharing settings. A viewer must have Dropbox access to the configured file to render the table with their connection.

When the macro renders, the file contents and metadata needed to produce the table are retrieved from Dropbox, processed transiently through the Forge backend, and returned to the macro for display. The App does not store or cache the retrieved file contents in its own storage or transfer them to services outside Atlassian. The configured file URL and other macro settings remain in Confluence page configuration so the file can be retrieved again. Dropbox OAuth credentials are managed by Forge's external authentication service and are not exposed directly to the App or stored in the App's own storage.

Google integrations and the data accessed

The App offers read-only integrations with Google Calendar, Google Sheets, Google Drive, Google Analytics 4, and Google Forms. A Confluence administrator creates and configures their organization’s Google OAuth application in Google Cloud Console and provides its OAuth client ID and client secret in the Live Tables administration settings.

The App implements Google OAuth itself; it does not use Atlassian Forge’s external OAuth provider for Google integrations. Each user authorizes access through their own Google account using the administrator-configured OAuth application. The data accessed depends on the permissions granted, the macro, and the Google resource configured by the user:

The App uses this data to provide the table or configuration feature requested by the user. It does not use these integrations to create, modify, or delete Google resources or responses.

For the Google Drive macro, a user supplies a file URL. Although the authorized Drive permission allows broader read access to files available to the connected Google account, the App uses it to retrieve the file configured in the macro; it does not list, search, or crawl unrelated Drive files. Access to a configured Google resource depends on the Google account used for the request having permission to read it.

Processing, storage, and sharing of Google data

When a Google-backed macro renders, the App retrieves the required data from the relevant Google API, transfers it through the Atlassian Forge backend, and returns the table result to the Confluence macro for display. The App does not store or cache the contents retrieved from Google Calendar, Sheets, Drive, Analytics, or Forms in its own storage. A subsequent render can cause another request to the relevant Google API.

The App does retain configuration needed to request the data again, such as a calendar ID and date range, spreadsheet or file URL or ID, Analytics property and report settings, or form URL or ID. Those identifiers and settings are distinct from the retrieved events, cells, file contents, report results, and form responses. Users who can view a page may see data presented in a rendered table according to the page and source permissions described above.

The administrator-provided Google OAuth client secret and per-user OAuth credentials, including access and refresh tokens, are stored in Forge secret storage. The App’s OAuth implementation accesses these credentials within the Forge backend to exchange authorization codes, refresh tokens, and make authenticated Google API requests on behalf of the connected user.

These credentials are stored in Forge secret storage and used by the Forge backend to communicate with Google’s OAuth and API endpoints. They are not sent to a Stiltsoft-hosted backend or unrelated third parties. OAuth credentials are retained separately from the Google content retrieved to render tables. Each page viewer uses their own Google authorization and must have permission to access the configured Google resource.

The App does not sell Google user data, send it to data brokers, use it for advertising or credit decisions, or use it to train generalized artificial intelligence or machine learning models. The App does not send Google table contents to analytics services. Stiltsoft personnel do not access Google user data except with the user’s affirmative agreement for support concerning specific data, when necessary for security, or when required by law.

The App’s use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including its Limited Use requirements and the Google Workspace user data and developer policy where applicable.