Privacy Policy — Page Sharing for Confluence
This policy explains what the Page Sharing for Confluence app does with data when it runs inside your Confluence Cloud site. Unlike a purely client-side app, this app stores some data, writes pages into subscribing sites, and deliberately moves selected page content between Confluence sites, so this policy describes those flows in detail. The wording reflects the permissions the app actually requests, the data it actually stores, and the way content travels between a sharing site and a subscribing site.
Summary
Page Sharing for Confluence lets one Confluence site (the "producer") deliberately share specific pages with named partner sites (the "consumers"), and gives each partner site a synced, read-only copy of every shared page as a real page in a space its subscriber chooses. The app runs entirely on Atlassian's Forge platform, within Atlassian's hosted environment; it does not send data to any CloudScript.io server, because CloudScript.io operates no server for this app, and it uses no analytics, cookies, or trackers. The app does, however, store operational records in Atlassian's own storage on each site (including the Atlassian account identifiers of the administrators and users who operate it), it creates and maintains pages on subscribing sites, and it copies the title and text of pages you choose to share into the partner sites you choose to share them with. Because the app stores personal data and moves content between sites, our Atlassian Marketplace declaration records that the app does store personal data.
What the app is
The app ships as a single Forge app that performs two roles, under a two-tier governance model. On a producer site, a Confluence (organisation) administrator decides which spaces may share content externally at all, maintains an allow-list of the partner Confluence sites permitted to subscribe (identified by each site's Atlassian
cloudId, a stable tenant identifier), approves or denies subscription requests from sites not yet on that list, and can revoke links and subscriptions; within an enabled space, that space's administrators (or an organisation administrator) approve individual pages for sharing, issue subscription links, and can stop sharing at any time. On a consumer site, any user who is permitted to create a page in their chosen space can subscribe to an approved page using an unguessable "magic link" provided by the producer; the app then receives the page's content and maintains it as a synced page in that space. The producer is in control throughout: a consumer only ever receives content the producer has both approved for the page and allow-listed (or expressly approved) for that consumer's site, and content flows only while the page's space remains enabled for sharing.
Where processing happens
All processing happens inside Atlassian's Forge environment. The producer reads the chosen page's body, reduces it to native content (described below), and sends it directly to the subscribing site's Forge endpoint; the consumer writes that content into a page within its own Confluence site. The only external destination the app is permitted to contact is its own Atlassian-hosted Forge web-trigger host,
e0dc6603-9fc0-4811-ac03-a102e9206634.hello.atlassian-dev.net, which every installation of this app shares and which is how one Confluence site's installation talks to another's. The app declares no other external destination, and on Forge an app can only contact destinations declared in advance, so the app cannot transmit content to CloudScript.io or to any unrelated third party. Calls the app makes to Atlassian's own platform interfaces (including the personal data reporting API described below) take place within that environment and involve no destination other than Atlassian. As an additional check, the app validates that any subscriber endpoint it is asked to push to sits on the Atlassian Forge web-trigger host family before it will store or call it.
What the app can access
The app requests nine permissions, each tied to a specific function.
-
read:page:confluencelets the producer read the body of a page that an administrator has approved for sharing. -
read:confluence-content.summaryis required by the page-update event that triggers a push when a shared page changes. -
read:space:confluencelets the app read a space's permission assignments so it can verify, server-side, that the person sharing a page administers that space and that a subscriber can create a page in their chosen space, lets the organisation administrator's space-enablement switchboard list the site's spaces, and resolves the space a subscriber nominates to its identifier when they subscribe. -
read:confluence-useris used to check whether the person performing a privileged action belongs to an administrator group (the check is used at the moment of the action and its result is not stored) and to resolve stored account identifiers to display names when an administrator views the app's management and audit screens (resolved on demand and likewise not stored). -
storage:appholds the operational records described in the next section. -
report:personal-datais used solely to report the Atlassian account identifiers held in those records to Atlassian's personal data reporting API, as part of the user-privacy compliance flow described in the next section: what is sent is each stored identifier together with the time it was last recorded, nothing more, and it involves no destination other than Atlassian. On the consumer side, -
write:page:confluenceis used to create and update the synced page that holds the shared content, -
delete:page:confluenceis used to move that synced page to the site's trash when sharing ends, and -
write:confluence-contentis used to mark the synced page as a replica and to apply an edit restriction to it. The app never modifies or deletes a page that you or your users authored: the write and delete permissions are exercised solely on the synced pages the app itself creates on a subscribing site, and no content ever flows from a consumer site back to a producer site.
What data the app stores
The app stores operational records in Atlassian's Forge key-value storage, separately on each site and only within that site's own storage namespace. The shared content itself is not held in app storage on the consumer side; it lives in the synced Confluence page described below, inside the customer's own Confluence site.
On a producer site the app stores: for each space, whether an organisation administrator has enabled or disabled it for external sharing, recording which administrator acted and when; for each shared page, the sharing state and page title together with the account identifier of the administrator who approved it (and, where sharing has been stopped, who stopped it and when); the allow-list of permitted partner sites, each recorded as a
cloudId with an optional human-readable site label and the account identifier of the administrator who added it; each subscription link that has been issued, with the account identifier of the administrator who created it, a count of how often it has been used, when it was last used, and (where revoked) who revoked it and when; for each subscription, the partner site's
cloudId and site URL, its receive endpoint, a per-subscription secret used to authenticate pushes, the time of the last successful push, and (where the subscription has ended) when and by whom it was ended; and, for each subscription request awaiting approval, the requesting site's
cloudId and URL, its endpoint and proposed secret, and the page requested. Pending requests are automatically deleted after 14 days if not actioned, and each link is capped at 25 outstanding requests.
On a consumer site the app stores, for each subscription: the producer endpoint it enrolled with, the source page's title, the matching per-subscription secret, the space (and optional parent page) the subscriber chose, the account identifier of the user who subscribed and when, the identity and location of the synced page once created, and lifecycle audit fields recording whether and why the subscription ended (unsubscribed here, or cancelled by the publisher), when, and by whom. Where a push cannot be applied because the target space already contains a page with the same title, the app records that blocked state, including the colliding page's title, until it resolves.
Subscription records on both sides are retained after a subscription ends: they are the audit trail the app's management screens show (who shared or subscribed to what, when, and how it ended). The records themselves persist until the app is uninstalled from that site, but the account identifiers within them do not necessarily persist that long. On a daily cycle (well within Atlassian's default reporting interval), the app reports each account identifier it stores to Atlassian's personal data reporting API, and where Atlassian indicates that an account has been closed, the app replaces every occurrence of that identifier in its records with a non-identifying marker (shown to administrators as "Account removed"), so that the audit record of the historical action is retained without continuing to identify the individual. This is the mechanism by which a closed account's identifier leaves the audit trail. Because the app stores account identifiers only (display names are resolved on demand when an administrator views a screen, and are never stored), a notification from Atlassian that an account's profile has been updated requires no action.
Cross-site content sharing and your responsibilities
The core function of this app is to copy the title and text of a page from a producer site to one or more consumer sites that the producer has chosen. When a page is shared and a partner site subscribes, and whenever the page is subsequently updated, the producer reads the page body and reduces it to a fixed allow-list of standard Confluence content before it leaves the site: what survives is text, headings, bullet and numbered lists, block quotes, code blocks, tables, dividers, emoji, status lozenges, dates, basic text formatting, and ordinary web and email links, together with the page title and its title emoji. Everything else — images and attachments, macros and app content, @-mentions, expands, panels, task and decision lists, and page layouts — is removed before transmission and does not appear in the copy, not even as a placeholder. The receiving site independently re-applies the same allow-list to everything it accepts before writing it, and rejects content it cannot parse, so nothing embedded or executable crosses the instance boundary in either direction of the check. Because the producing organisation decides which pages to share and with which partner sites, that organisation is the controller of the page content and is responsible for ensuring it is appropriate to share that content (including any personal data it contains) with the recipient sites; CloudScript.io processes that content only as the mechanism the producer uses to share it, and does not select, inspect, or retain it on any CloudScript.io system.
The synced page on a subscribing site
On the consumer site, the shared content is materialised as a real Confluence page in the space the subscriber chose, marked as a synced replica (a badge on the page identifies it and explains that local edits will be overwritten). Each push updates that page through Confluence's ordinary versioning, so the page accumulates version history like any other page. The app attempts to restrict editing of the synced page when it creates it, so that ordinary users cannot modify it; that restriction depends on the Confluence plan (content restrictions are not available on Confluence Free) and site administrators can always override it, so on some sites the practical guarantee is that the source overwrites any local edit on the next sync rather than that edits are impossible. The synced page is otherwise governed by the subscribing site's own Confluence arrangements, like any page in that site.
How sharing is withdrawn, and what happens to stored copies
When a producer administrator stops sharing a page, disables a space, removes a partner site from the allow-list, or revokes a subscription, the producer sends a delete instruction to each affected subscriber, and the subscribing site moves its synced page to that site's trash. That delete instruction is sent once, on a best-effort basis: if a subscribing site is unreachable at that moment, the instruction is not queued for retry, though no further content is pushed to that subscriber because the producer re-checks authorisation before every push. A subscriber can always end things from their own side: unsubscribing on the consumer site withdraws the subscription with the producer and moves the local synced page to trash regardless of whether the producer is reachable. A trashed page is handled by the subscribing site's normal Confluence trash arrangements (it can be restored or permanently deleted by that site's administrators) rather than being permanently erased by the app. Uninstalling the app from a site discards the operational records the app held in that site's Forge storage (Atlassian removes uninstalled apps' storage in line with its own platform data-retention policy, and a later reinstall starts with empty storage); synced pages that were already created remain in the site as ordinary pages, in the page tree or trash, under that site's control. There is no separate CloudScript.io system from which anything would need to be deleted.
Personal data
The personal data the app itself stores consists of Atlassian account identifiers, recorded so the app's management screens can show who took each governance action and so its audit trail is meaningful: the organisation administrators who enable or disable spaces, manage the allow-list, approve requests, and revoke links or subscriptions; the space administrators who approve pages for sharing and issue links; and the users on subscribing sites who subscribe to or unsubscribe from a page. Display names are looked up from these identifiers only when an administrator views the relevant screen, and are not stored. The identifiers of closed Atlassian accounts are removed from the app's records automatically, through the daily reporting and erasure flow described above. Separately, the page content a producer chooses to share may contain personal data within the text of the page, and where it does, that content is copied to the subscribing sites the producer has chosen and held there as a synced page until sharing is withdrawn. CloudScript.io does not collect names, email addresses, or other directory information into any CloudScript.io system, and operates no database, profile, or analytics store of its own for this app. Requests from individuals to access, correct, or delete personal data contained in shared page content should be directed to the organisation that operates the relevant Confluence site, since that organisation controls the page and decides what to share; CloudScript.io will assist a customer with such a request to the extent the app's controls allow (for example, by a producer withdrawing sharing so the synced copies are trashed).
Where data resides and overseas disclosure
All data the app stores resides in Atlassian's Forge infrastructure, in the storage associated with each customer's own Confluence site; Atlassian's hosting and data-residency arrangements determine its physical location. When a producer shares a page with a partner site, the content travels to wherever that partner site is hosted, which may be in a different country from the producer: choosing which partner sites to share with, including the jurisdictions they sit in, is the producing organisation's decision, made through the allow-list and approval controls described above. CloudScript.io, an Australian sole trader, does not itself receive, host, or transfer the data in any country.
How content and links are kept secure
Privileged actions are authorised server-side against the role they require, and the checks fail closed: an action proceeds only when the app can positively confirm the person holds the necessary role (organisation administrator for instance-trust and space policy, space administrator for sharing pages within an enabled space, page-creation permission for subscribing). Subscribing to a page requires possession of an unguessable magic link, which is the deliberately shared capability that lets a partner site enrol; links are revocable and their use is counted. A subscription is granted immediately only when the requesting site is both on the allow-list and able to prove its identity: the subscribing installation signs its own platform-provided site identifier with an app-wide secret (an HMAC-based attestation carrying no personal data), and the producer verifies that signature before trusting the claimed identity; any request that is not both allow-listed and validly attested is held for administrator approval instead, and the queue of such requests is bounded and expires. The producer re-checks, before every push, that the page is still shared, that its space is still enabled, that the recipient site is still allow-listed, and that the subscription is still valid, skipping any recipient that fails. Each push is authenticated by a per-subscription secret, compared in constant time, and a consumer accepts a push only when it matches a subscription it created, so a site cannot be made to store content for a subscription it did not establish. Page content is reduced to the native-content allow-list before it leaves the producer and re-validated against the same allow-list before it is written on the consumer, as a deliberate double check that no active or unexpected content is carried across.
What the app does not do
The app does not send your content to CloudScript.io or to any external service other than its own Atlassian-hosted endpoints on the partner sites a producer has chosen, it stores no data on any CloudScript.io system because there is none, and it includes no analytics, advertising, cookies of its own, or third-party tracking code. It does not transmit macros, attachments, images, or other embedded media, and it does not substitute placeholders for them; it never modifies or deletes pages you authored (its write and delete permissions operate only on the synced pages it creates on subscribing sites); and it provides no path for a consumer site to write content back to a producer site.
Atlassian Forge and the underlying platform
Because the app runs on Atlassian Forge, the platform itself is operated by Atlassian, and Atlassian's infrastructure, security model, and data residency arrangements govern how the app executes and where the data it stores in Forge storage resides. For information about how Atlassian handles data on Forge and within Confluence Cloud, including data residency, refer to Atlassian's own privacy and trust documentation. Your agreement with Atlassian governs the page content held within each Confluence site, including the synced copies this app maintains on a subscribing site.
Access, correction and complaints
If you believe CloudScript.io holds personal data about you in connection with this app (in practice, limited to support correspondence, since the app's operational records live in each customer's own Confluence site), or you wish to access or correct it, contact us at support@cloudscript.io and we will respond within a reasonable period. Complaints about our handling of personal data can be made to the same address; if you are not satisfied with our response, you may complain to the Office of the Australian Information Commissioner (oaic.gov.au), or to your local data protection authority if you are outside Australia. For personal data contained in shared page content or in the app's records within a Confluence site, your request is best directed to the organisation operating that site, as described above, and we will assist that organisation as needed.
Support
If you contact us for support at support@cloudscript.io, we receive the email address and any information you choose to include in your message, and we use it only to respond to and resolve your request. Support is handled by email; there is no support form that collects data on this website.
Changes to this policy
If a future version of the app changes what it accesses, stores, or transmits (for example, if a later release shares additional content types, introduces a CloudScript.io-hosted service, or adds analytics), this policy will be updated to describe that behaviour before that version is released, and the effective date above will change accordingly.