FAQ - Security

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.

3. 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.

4. 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 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.

5. Google integrations and the data accessed

The App offers read-only integrations that retrieve Google data after a user grants the relevant permissions through Google OAuth. The data accessed depends on 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.

6. 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.

Google OAuth access and refresh tokens are managed by Atlassian Forge’s external authentication service. They are not exposed directly to the App or stored by the App in its own storage. Authenticated Google API requests are made through Forge using the connected user’s authorization.

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. It does not send Google table contents to the usage analytics service described below. 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.