Tidy Find & Replace privacy policy

Effective 1 November 2026. Provided by Pro Softwares ("we").

This policy describes what the Tidy Find & Replace app for Confluence Cloud (version 1) stores, where, for how long and who can see it, and what the app reports to Atlassian and erases about people. It describes how the app works. It is not a certification and not a statement of compliance with any privacy law or standard.

Page content

The app reads page content to find matches and writes the edited page back to Confluence. It never stores page content, titles or excerpts. What it does store is listed in full below, under "What Tidy Find & Replace stores". In short: the text you asked to find and replace, with each job's options and filters (a label, title words, an advanced CQL query); where each job works, by page and space identifiers and space keys (the key of a personal space contains its owner's account ID); page identifiers, version numbers, the matches you unticked, counts, warnings, result codes, statuses and times; the Atlassian account IDs of the person who started each job and of the person running it; the two settings of the Settings tab; its records of reporting account IDs to Atlassian; and a request from Rovo that waits for its person (its texts, options and space, with that person's account ID). A job, with everything stored for it, is kept for at most 90 days; a request from Rovo for up to 24 hours. For the migration scan and its fixes it also stores your site's own address; the names of the macros it found (for an app's Forge macro, also the app's ID and the macro's key); the old server names you confirm, with the new host of a renamed one; the host names it found that look like old servers, before you confirm them; and, for a fix, a one-way hash of each old address it looks up, made with a secret kept in the job, with the page or space it resolves to or why it needs a manual edit. A scan is kept for at most 90 days, like a job.

Page content, titles and the excerpts shown in the preview are read and changed in memory only, at the moment they are needed, for the person using the app. They are never stored. To run jobs, the app also keeps the records listed below.

What Tidy Find & Replace stores

In Atlassian's Forge storage for your site only:

job records: the pairs of find text and replacement that were typed, the options (match case, whole words, regular expression, and whether titles, link addresses and code are changed), where the job works (the whole site, chosen spaces, a space, or a page tree or page with its start page ID; spaces by ID and key), the filters typed (a label, title words, the content types, whether personal spaces are included and, for Confluence admins, an advanced CQL query), who started it (their Atlassian account ID), when, its status, and progress and result counts. While a job is reading pages, it also holds its place in Confluence's lists, which can contain the job's search; that place is cleared when the reading ends. While a job waits for Confluence's hourly allowance, it holds the time it continues;
for each page or blog post a job plans to change: its content ID, whether it is a page or a blog post, the version number read, counts of matches by kind of place, and yes-or-no flags (for example "a title would change");
the pages and single matches the person unticked in the preview, by number;
for each page the job went through: a result code, the version numbers before and after, counts of matches replaced and skipped, and notes (for example "title kept");
the job's preview: totals, counts and warnings, with no titles and no page text;
while a job is reading pages: the content IDs of the pages it has already planned, so that no page is planned twice;
a pause or cancel request, while it is being carried out;
working notes that stop two things happening at once. The note of a job, for the whole site or for a space, holds the job ID, the account ID of the person running it, the time of its last activity and, while it waits for Confluence's hourly allowance, the time it continues. The notes of single steps hold only a time;
the two switches of the Settings tab;
a request from Rovo that waits for its person (when Confluence asked that person to allow the app before the agent could act for them): the account ID of the person who asked, and for a find and replace the texts, the options and the space key it named, or for a migration scan the space key only, and when it was made. One a person, replaced by their next one;
the app's own records of its personal data reporting (see below): for each person, their account ID with the time of the last report, a mark while the erasure for a closed account is unfinished, and a mark when Atlassian refuses to take an ID; and one record, with no account ID in it, that remembers when Atlassian last accepted accounts.
A migration scan is kept as a job record of its own kind: where it reads (the whole site, chosen spaces or a space, and whether personal spaces are included), who started it (their account ID), when, its status and progress, and what it counted: your site's own address; the host names it found that look like old servers (at most 50 by name, the rest only counted) and the old server names you confirm, each with what to do with it (resolve its paths, or move its addresses to a new host, whose name it keeps) and its counts of links by pattern; the names of the macros from apps it found (at most 200; for a Forge macro also its app's ID and the macro's key), each with how many pages hold it and one page ID; the spaces that hold such links, by ID (with the keys of the spaces you chose), with their counts; and the content IDs of the 20 pages that hold the most.
For each page that holds addresses on those hosts (at most 10,000 pages): its content ID, whether it is a page or a blog post, the version number read, its space ID, and counts of its links by host and pattern, with marks for the places it names those hosts.
Report-only lists: the content IDs of up to 2,000 pages in each list (pages with macros from apps, pages with legacy content, and pages the app could not read).
While a scan reads: the content IDs of pages counted beyond the stored pages, so that no page is counted twice; deleted when the scan finishes.
A fix job is a find and replace job whose request names the scan, the confirmed hosts and their rules, the chosen spaces and your site's address, instead of pairs; for each old address it looks up, it keeps a one-way hash of the address, made with a secret kept in the job, and what the address resolves to: a page or blog post ID with its space key, a space key, or why it needs a manual edit.
The scan never stores page titles, link text, link addresses (old or new) or the hosts of other links. The examples the screen shows (up to ten) are worked out when they are shown, for the person viewing them, and are not stored.

What it does not store

Page or blog post content, titles, excerpts, comments, attachments, email addresses, names or profile pictures. Where a name appears on screen (for example in Activity), Atlassian shows it from the account ID. The app stores nothing in your browser.

Personal data

The app stores Atlassian account IDs (the identifier Atlassian gives each user):

the person who started each job;
the owner of a personal space that a job works in. The key of a personal space is ~ followed by an identifier of its owner, and a job stores the keys of its spaces, so it names that person even if they never used the app;
the person running a job, in the note of the job;
the person whose request from Rovo waits for them;
the app's own reporting records that name a person, listed above.

The find texts, replacements, label and title filters, advanced CQL and the keys of ordinary spaces are typed or chosen by your people and can contain personal information. They are your content: the app can't tell what they contain, so it neither reports nor erases them. They expire with the job, or with the request from Rovo that holds them.

Where it lives

Inside Atlassian's cloud, in Forge storage that is scoped to your site ("Runs on Atlassian" hosting). The app has no servers or databases of its own and makes no calls outside Atlassian. None of the data described here is sent to us or to anyone other than Atlassian, who hosts it. The only thing that reaches us from the app is its log lines (see "Who can see it"). Once an hour a scheduled job of the app calls Atlassian's personal data reporting API, which is an Atlassian service. According to Atlassian's documentation, an admin can control where Forge storage data is held (Atlassian's data residency controls), and the data is encrypted and stored under Atlassian's cloud policies.

How long

Job records and everything stored with them (planned pages, ticks, results, the preview, pause and cancel requests) are marked to expire 90 days after the job was created. A job that is discarded, or that finds nothing to change, is deleted at once.
When a new job (or an undo job) is created, the app also trims the history to the newest 500 jobs, oldest first. It keeps a running job, the original of an undo job that isn't finished, and a job that another window is working on at that moment (the next trim tries again).
The app's reporting records: the record of the last report expires 30 days after it was written (the app writes it again at each report, about every 7 days). The mark about a refused ID expires after 30 days. The record of when Atlassian last accepted accounts expires after 7 days. The mark about a closed account stays until its erasure is finished, and is then deleted.
Working notes. The note of a single step is deleted when the step ends, and one that a stopped step left behind is deleted by the hourly job once it is an hour old. The note of a job has no expiry date of its own. The app deletes it when the job finishes or is cancelled and when the history trim removes the job, and a later job takes it over once it has been idle for 15 minutes. The hourly job also deletes a note that has been idle for 15 minutes and whose job is finished or gone. The note of a paused or abandoned job stays for as long as the job is kept, at most 90 days, and holds an account ID until then. It goes earlier when the person it names is reported closed, and when the app is uninstalled.
The two switches of the Settings tab are kept while the app is installed.
A request from Rovo that waits is kept for up to 24 hours, and deleted earlier when the person uses or dismisses it, or makes another. It is reported and erased like the person who started a job.
According to Atlassian's documentation, Atlassian's storage can take up to 48 hours to remove an expired item. The app stops showing a job once its 90 days are up.
If you uninstall Tidy Find & Replace, Atlassian deletes the app's stored data for your site under its own retention rules. We keep no copy. Atlassian may keep backups under its own policies.

Your pages' history

Every page the app changes gets a new version in Confluence, made by the person who ran the job, with the message "Tidy Find & Replace job" and the job's ID. The find text is never put in the message. These versions belong to your Confluence site, not to the app: they stay after a job expires or the app is uninstalled, and older versions still hold the text from before the change.

Reporting to Atlassian and erasure

The app uses Atlassian's personal data reporting API, as Atlassian asks of apps that store personal data. A scheduled job of the app runs every hour, as the app and with no user. It reads and writes only Forge storage and calls only Atlassian's reporting API. It never calls Confluence, and it runs whether or not the subscription is active.

What is sent, and to whom. For each account ID the app stores, it sends Atlassian the account ID and one time: the earliest time the app stored that person's data. Nothing else is sent: no names, email addresses, page titles, find texts or job contents. It goes to Atlassian only.
How often. Each account is sent at most once every 7 days (Atlassian's default cycle), up to 90 accounts in one call. A run works for a limited time and carries on at the next run. If Atlassian is busy or a call fails, the app tries again at the next run.
When Atlassian says an account is closed. The app learns this when it next reports that account, so within about a week. It then erases, in that run or in the next ones:
- the link to the person in every job they started. The job stays in the history, so admins can still open and undo it, but Activity shows "Deleted user";
- the key of that person's personal space in every job that works there, whoever started the job. Activity then says "a deleted user's personal space". A job that is still reading pages keeps the key until the reading ends;
- the note of a job that names the person, once it has been idle for 15 minutes. A running or paused job that held it is marked Interrupted and can be resumed;
- a request from Rovo that waits for that person;
- last, the app's own records about that person.
When Atlassian says "updated". Nothing changes, because the app stores no name, email address or profile picture.
An ID that Atlassian refuses. The account IDs Atlassian gave the app are reported first; the owners of personal spaces, whose IDs the app reads out of the space key, after them. Atlassian may refuse a key that holds something other than an account ID. The app then finds the refused ID, reports the others, skips the refused one for 30 days and tries it again. While an ID is skipped nothing is erased early for it: its jobs expire after 90 days as usual.
What stays. Erasure removes account IDs, not the work. The find texts, replacements, filters, content IDs, results and counts of each job stay until the job expires after 90 days.

Who can see it

Only people using the app on your site, through its screens, and only what their Confluence permissions allow.

Confluence admins see every job on the site in Activity, with its find texts and replacements.
Space admins see the jobs in their space, including page-tree jobs there.
Someone using "Find & replace in this page tree" sees their own jobs for that page.
A job's preview and report show only the pages and blog posts the viewer can open in Confluence right now, with their current titles. Pages the viewer can't open are only counted. Excerpts are made for that viewer when they open a page's matches.
If another job is blocking yours, the screen shows who started it.

We can't read your stored data. According to Atlassian's documentation, only the app itself can read and write it, and this app makes no calls outside Atlassian. The only thing that reaches us from the app is its log lines. A log line holds the event name, job IDs, positions inside a job (chunk and item numbers), the kind of place it ran in, status and result codes, yes-or-no flags, counts, the name of the app function that failed unexpectedly, the class name of an error (never its message) and HTTP status codes. A log line never holds an account ID, a page title, page text, a find text or replacement, a link address or a space key. The hourly reporting job writes one line per run with counts only.

Analytics and tracking

None. The app has no analytics, tracking or advertising code.

What we receive outside the app

The emails you send to support@prosoftwares.dev, and the licensing and purchase details that Atlassian shares with Marketplace vendors under its own Marketplace terms.

Your rights and contact

Questions or requests about the data the app holds: support@prosoftwares.dev. We have no way to look up or delete single records in your site's storage. The app erases a person's account ID by itself when Atlassian reports that person's account closed (see above). Otherwise job data expires on its own after 90 days, and a Confluence admin can remove all of the app's stored data by uninstalling it.