Your information, clearly explained.

Who is responsible for your data

The controller for this free beta is Sync4us, a project by Aitor Pérez Gutiérrez. You can write to hello@sync4us.com with any privacy questions or to exercise your rights.

Connecting to Jira Cloud

If you choose “Connect to Jira”, Atlassian shows the requested permissions and the site you will grant access to. Sync4us reads your account ID, display name, email when Atlassian provides it, and the ID and name of the selected site. The app uses this connection to retrieve issues, permissions, estimates and worklogs, and to log or change time only when you confirm the operation. Access is limited by your Jira account permissions.

In Sync4us 0.27.0 and later, after connecting Jira or completing migration, access and refresh tokens are stored encrypted in the Sync4us service (Supabase Vault), linked to your profile, installation, site and account. The app receives the access token only in the main process memory for a short period to query Jira directly. The Sync4us broker hosted on Cloudflare exchanges and refreshes tokens, schedules deletion of the state of each authorization attempt after ten minutes and blocks its use when that period expires. Functional queries for issues and time go directly from the app to Atlassian. The service verifies the site and account ID with Atlassian and retains that ID and the earliest recorded connection date to process Atlassian privacy notices.

Profiles connected to Jira in earlier versions, including 0.26.1, retain the refresh token encrypted with Windows secure storage. When you use Jira after updating, Sync4us attempts to move it to the service; only after confirming the transfer does it remove the token from the current local profile and its recoverable copy. If this fails, Jira is paused for a retry and the encrypted local token remains; in some cases you will need to authorize Jira again. Blocks, Jira references and details, and history remain in the local profile; this update does not move that content to the service.

If you use Team, the Sync4us service stores, per organization, a link between your profile and your Jira account ID, together with an identifier derived from the site and a verification status. Each person can view their own link; owners and administrators of the same team can view the links needed for the report. From their own computer, they can retrieve worklogs that their Jira account is allowed to see; results may be partial. Report hours and worklogs are not stored in the service or in the app browser’s persistent storage: they remain in memory during the session, including when switching sections. Only the last query’s filters and a technical context fingerprint are retained. On sign-out, or when the app detects that you have lost access to Team, those filters are also discarded.

You can disconnect Jira in the app and also revoke permission through the connected apps in your Atlassian account. Disconnecting removes the connection and tokens stored by Sync4us when the service confirms the operation. If it fails, the app keeps the connected state and offers a retry or revocation through Atlassian. If a local OAuth credential still exists, it is also removed when disconnecting. Disconnecting does not automatically delete the work history already stored on this computer.

If Atlassian notifies us of an update or deletion of a Jira account’s data, registered installations that receive the request pause the connection and show the cleanup when they reconnect. The app removes credentials, identifiers, details, links and receipts obtained from Jira from the computer. It retains blocks, dates, durations and verifiable historical totals; the breakdown and some historical data may change when Jira references are removed. After verifying the local cleanup, each installation separately sends a technical acknowledgment to the identity service. If it cannot complete verification, Jira remains paused and the request remains pending review.

On the first launch of the version that includes this cleanup, Sync4us also checks copies of earlier profiles found on the same computer and removes their Jira-derived data, including browser catalogs and receipts. If it detects a copy it cannot safely check, it stops startup and shows how to contact support without deleting blocks. Each computer must install and open the new version for this process to run; an installation that has not yet been updated retains its earlier local data.

What the app collects during updates

To check whether the update mechanism works, Sync4us may send a best-effort technical acknowledgment with the phase reached, the result, the source and target versions, and a failure code from a fixed list. The session validates that the request is legitimate, but the metric is stored in aggregate form and does not retain your identity.

This acknowledgment does not include email, user, installation, computer name, paths, URLs, credentials, Jira or Clockify data, or free-form traces. The random deduplication identifier is deleted after seven days and aggregated daily counts are retained for 30 days. If the acknowledgment fails, it does not block or change the update.

What the website collects

If you request access, we process your email, consent and security verification. The waiting list stores your email and the consent version and date; it does not reserve a place or activate campaigns or automatic notifications.

Hosting generates the usual technical records of a web request, such as IP address, date, URL, referrer and browser. Netlify Web Analytics uses these CDN records to display aggregate statistics on page views, estimated visitors, traffic sources and countries.

On public pages, including the guides, and on request confirmation, Umami Cloud anonymously measures page views, referrer, browser, device, country, UTM campaigns and clicks on access request buttons. It uses no cookies or browser storage. The IP address is used to determine approximate location and is not stored; this property’s data resides in Umami’s European region.

Purposes and legal bases

• Verify your email and automatically grant free access when places are available.
• Manage registration, an invitation, access and communications related to the trial.
• Understand, in aggregate, which pages receive visits and where visitors come from.
• Protect the website against fraud, abuse and technical incidents.

Your request is processed on the basis of your consent and the steps you request before accessing the beta. Security and strictly aggregate measurement are based on the legitimate interest in operating and improving the service.

Providers and limits

Netlify hosts the website and provides aggregate measurement based on the CDN. Umami provides anonymous measurement of public pages, campaigns and access buttons. Supabase provides account, session, license, registration and waiting list services. Cloudflare Turnstile protects the form against automated registrations. Resend is involved when transactional emails are sent. Atlassian provides Jira Cloud and manages OAuth consent. Cloudflare hosts the connection broker and may process technical request data to provide and protect it.

Account data, Jira links and, since 0.27.0, encrypted OAuth tokens that Sync4us retains in Supabase are hosted in Ireland. New registrations and the waiting list are stored in Supabase, in Ireland. Historical requests from the old form may remain in Netlify until deleted. Resend stores the data needed to send our emails in the United States. The Jira connection service processes authorization data on Cloudflare’s global network. Each authorization’s temporary state is stored in a Cloudflare storage component restricted to the European Union (Durable Object). Cloudflare may log that object’s technical identifier outside that jurisdiction. Netlify serves the website from a global network; requests and their technical records may be processed outside the European Economic Area. Sync4us work blocks and local history are stored on the Windows computer where you use the app.

Analytics receives no emails, form responses, invitation identifiers, credentials, hours, Jira keys, notes or Clockify content. The private registration, activation and download routes, as well as this privacy page, do not load analytics scripts.

Retention and your rights

The waiting list is retained for up to 91 days; cleanup runs daily. Abuse counters retain the email and a cryptographic digest of the IP address for a maximum of 48 hours. If you access the beta, we retain account data for as long as necessary to manage the relationship and applicable obligations. If the relationship does not continue, the data is deleted or anonymized when no longer needed. Netlify’s current analytics dashboard shows seven days of aggregate statistics. Umami’s Hobby plan retains its anonymous statistics for six months.

The Team link is retained for as long as necessary to display and verify the linked Jira account; you can revoke your link from the app. Those links are removed when Atlassian sends an update or deletion notice. For installations already registered, technical records are retained while they must receive the request and confirm cleanup. Installations that predate per-computer registration need to be updated to perform local cleanup; removing a link from the service does not prove that their local copies are clean. The technical fingerprint and report filters are discarded on sign-out or loss of Team access. Technical records per installation and their acknowledgment states currently have no automatic deletion period. You can request their review or deletion using the contact below.

You can request access, rectification, erasure, objection, restriction or portability by writing to hello@sync4us.com. You can also lodge a complaint with the relevant data protection authority.