CloudScript.io NikoNiko Calendar Privacy Policy

Effective 7 August 2026.

Who we are

CloudScript.io NikoNiko Calendar is provided by Cloudscript Pty Ltd (ABN 14 700 662 362). If you have questions about this policy or the app's handling of data, contact us at support@cloudscript.io.

This policy describes the app as built on Atlassian Forge: the wording reflects the permissions it actually requests and the data it actually stores. It does not describe the earlier version of the app, which ran on the Atlassian Connect platform and has since been retired.

Summary

CloudScript.io NikoNiko Calendar places a macro on a Confluence page that shows a calendar grid. Each person a page author lists in the macro's configuration can record an entry, a value on a three- or five-point scale, for a given day, by selecting their own cell; the calendar shows the recorded entries to anyone who can view the page, together with an optional row summarising the team's trend over time. The app runs entirely on Atlassian's Forge platform, inside Atlassian's own hosted environment. Its manifest declares no permission to contact any destination outside Atlassian, so the app makes no request to any Cloudscript server or third-party service, and it uses no analytics, cookies or trackers of its own. It stores one record per person per calendar per day, holding an Atlassian account identifier, a date, the scale value entered, the time the entry was written and a reference to the calendar the entry was recorded on, in Atlassian's own Forge storage on your site.

What data CloudScript.io NikoNiko Calendar collects

The app stores exactly five values per entry: the Atlassian account identifier of the person the entry belongs to, the date it applies to, the scale value entered (a single character from '0' to '5', where '0' means no entry has been recorded for that day), the time the entry was last written, and a reference to the calendar it was recorded on (the page and macro instance, derived by the app itself and never shown to any viewer). The calendar reference records that an account participates in a particular calendar on a particular page — a fact the page's own content already expresses through the macro's people list — and exists so that an entry is only ever shown on the calendar it was recorded on. No note or free-text comment, no display name, no email address, and no derived or inferred field is stored.

A calendar's optional label (the question the calendar asks) is not stored by the app at all: it is a macro parameter held in the Confluence page's own content, controlled and edited like any other page content. Because changing a label is a page edit, the previous wording is recoverable from the page's version history, although Confluence's version-history view does not display it; the history is auditable by your organisation rather than tamper-proof, and no surface of the app can connect a stored entry to the label that was in force when the entry was written.

The app requests four permissions, and nothing beyond them. read:content-details:confluence lets the app search Confluence users and resolve account identifiers to display names and avatars, so the configuration panel can offer a people picker and the calendar can label its rows with names rather than raw identifiers, and also carries the check that confirms a caller of the app's administration screen is a site administrator. These lookups happen live, each time a screen is drawn, and the resulting names and avatars are not stored anywhere. read:content.permission:confluence lets the app ask Confluence, before it serves or records an entry, whether the person invoking the calendar can view the page it sits on; it reads permission metadata only. storage:app holds the entry records described above. report:personal-data is used solely for the account-closure reporting process described under "Egress destinations and sub-processors" below. The app requests no permission to read, write or delete Confluence page content, and no permission to send data anywhere outside Atlassian.

Where data is stored and processed

All entry records are held in Atlassian's Forge Custom Entity Store, within the storage partition Atlassian allocates to this app on your own Confluence site. Each installation's records sit in their own partition; one customer's records are not readable by another customer's installation. Cloudscript operates no database or backend of its own for this app, and holds no separate copy of the records on any system it runs.

Reading and writing entries happens inside a resolver function that also runs on Forge, within Atlassian's hosted environment. The macro itself runs in a sandboxed iframe on your Confluence site.

Egress destinations and sub-processors

The app's manifest declares no permissions.external block and no remotes entry of any kind. On Forge, an app can only contact a destination it has declared in advance, so the app cannot transmit anything to Cloudscript or to any third party.

The one call the app makes beyond its own storage goes to Atlassian itself, not to an external destination. On a recurring seven-day cycle, the app reports each account identifier it holds to Atlassian's personal data reporting API, as required of Forge apps that store account-linked data, so that Atlassian can tell the app when an account has been closed (see "Uninstall, revocation and deletion" below). This call uses a platform-internal transport rather than an outbound network request, so it does not appear in the app's egress declarations, and it sends nothing beyond the stored account identifier and the time its entry was last written.

Atlassian is disclosed as a sub-processor for hosting and platform services under the app's Data Processing Addendum, available at https://cloudscript.io/apps/nikoniko/dpa, which incorporates the Forge Data Processing Addendum's terms. No other sub-processor is used, because no other destination exists for this app's data to reach. Any transfer of entry data outside the European Economic Area is governed by that same Forge Data Processing Addendum and the Standard Contractual Clauses it incorporates, not by any separate arrangement of ours.

We do not sell or share entry data, and we do not aggregate it across customers, produce reports about individuals from it, or use it to train any model. We use it only as the mechanism by which the app works, on the instructions of the organisation operating your Confluence site.

Retention

No fixed retention period is coded into the app, and the app never deletes entries on a schedule of its own. An entry persists until it is overwritten by a later entry for the same person, calendar and date, until the person who recorded it deletes it, until a site administrator deletes it, until the app is uninstalled from the site, or until the account it belongs to is closed, whichever happens first (each path is described under "Uninstall, revocation and deletion" below).

Data residency

The entry records this app stores exist only in Forge hosted storage associated with your own Confluence site. Cloudscript operates no infrastructure of its own for this app and declares no external network egress, so the physical location of that storage is determined by your organisation's own arrangements with Atlassian, not by anything Cloudscript provides or can vary. For how Atlassian itself handles data residency for Forge and Confluence Cloud, refer to Atlassian's own documentation.

Uninstall, revocation and deletion

Five distinct paths remove entry records from the app, and only five: three in-app controls, and two platform events.

Deleting your own entry for a day. A person who records entries can permanently delete their own entry for a day through the calendar itself. This removes the stored record for that date on that calendar only; entries the same person holds on other calendars are untouched. Deletion is immediate; nothing is kept in its place, and there is no undo.

Deleting your entire history. From the same place, a person can permanently delete their entire entry history — every entry of theirs, on every calendar on the site, including calendars on pages they can no longer view. This path deliberately requires no page permission: losing access to a page does not lock a person out of deleting what they recorded there.

Administrator deletion. Confluence site administrators have an administration screen for the app that lists the accounts for which entries are stored. The listing is drawn from the app's own storage rather than from the site's user directory, so it includes accounts that have been deactivated or have left the organisation. From that screen an administrator can permanently delete every entry for a named account, or run a site-wide deletion of entries older than a date the administrator chooses, which reports its progress and completion as it runs. Each operation runs only on the administrator's confirmation, operates across every calendar (deletion is never limited to one calendar), and the app refuses these operations server-side for any caller who is not a site administrator.

Uninstalling the app. The app declares no custom uninstall or deletion hook of its own. On uninstall, the app's stored entries are removed by Atlassian in line with the Forge hosted storage data lifecycle, described in Atlassian's own documentation at https://developer.atlassian.com/platform/forge/storage-reference/hosted-storage-data-lifecycle/. This policy does not assert a specific retention window for that default, because the window is Atlassian's to set and may change with the platform.

Account closure. This path is automatic and code-driven. On the seven-day reporting cycle described above, where Atlassian's personal data reporting API indicates that an account has been closed, the app erases every entry it holds for that account identifier within that cycle.

Removing the macro from a page, or removing a person from a macro's configuration, stops the calendar from displaying that person's entries but does not by itself delete the underlying records; likewise, copying a page copies the calendar but none of its entries, and deleting a page does not delete the entries recorded on it. The five paths above are the only ways a record is removed.

Who can see an entry

An entry recorded through the macro is visible to everyone who can view the Confluence page it was recorded on, for as long as that page shows a window covering the relevant date — and only there: an entry never appears on a calendar it was not recorded on, and a copied page starts with an empty calendar. The app verifies the viewer's permission on the page server-side before serving entries, and refuses when it cannot confirm it. The audience for a person's entry history is set by the Confluence page permissions your organisation applies to the page the macro is placed on, and by which people a page author lists in the macro's configuration. Choosing where to place the calendar, who to list on it, and who can see the page is your organisation's own decision.

Where the app's optional team-trend row is enabled, it is derived at render time from the same entries already displayed on the grid; the app stores, fetches or transmits nothing further to produce it.

Access, correction and complaints

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 act as controller of that correspondence: we use it only to respond to and resolve your request. If you believe we hold personal data about you in that correspondence, or wish to access or correct it, contact us at the same address 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.

This is separate from the entry records described above. Requests to access, correct or delete an entry, or a complaint about how entries are visible or used, should be directed to the organisation operating the Confluence site on which the calendar appears, as described in "Your rights" below.

Your rights

The organisation operating your Confluence site controls what the calendar records: it decides whether to use the app, which individuals are listed on a calendar, who can see the resulting page, and what it does with what the calendar shows. That organisation is the controller of the entry records for the purposes of the GDPR, and the business (or equivalent) for the purposes of the CCPA/CPRA and comparable regimes, where those frameworks apply. Cloudscript acts as a processor (or service provider) with respect to those records, under the terms of the Data Processing Addendum referenced above.

Requests to access, correct, export or delete an entry, and any privacy right you wish to exercise over it, should therefore be directed to the organisation operating the relevant Confluence site, which controls that content and is able to act on the request. An individual can also act directly: you can overwrite any of your own entries at any time through the calendar itself, and you can permanently delete your own entry for a day, or your entire entry history, in the same place. The organisation's site administrators can act on requests concerning any person's entries, including a person who has left the organisation, through the app's administration screen described under "Uninstall, revocation and deletion" above.

Where Cloudscript receives such a request directly, we will refer it to the operating organisation. Referral is not only our role under the Data Processing Addendum; it is the extent of what we can do. Cloudscript operates no system that holds the entries and has no administrative access to any customer's Confluence site: the deletion and correction tools described above run inside the customer's own site, under the control of its users and site administrators. If we were legally compelled to produce or delete entry records, we could comply only to the extent of what we actually hold, and for entry records that is nothing.

Security

For how we secure the platform this app runs on, manage vulnerabilities and respond to security incidents, see our Security page, which applies across our apps. If you believe you have found a security vulnerability in this app, email support@cloudscript.io.

Changes to this policy

If a future version of the app changes what it accesses, stores or transmits, this policy will be updated to describe that behaviour before that version is released, and the effective date above will change accordingly.

Contact

Cloudscript Pty Ltd (ABN 14 700 662 362)
Support: support@cloudscript.io