Data Inventory
Status: Published · Last reviewed: 2026-04-16 · Next review: 2027-04-16 Regulatory reference: Article 30 GDPR.
This inventory lists the categories of personal data Syncflow processes. It is written at category level so that users can understand what we hold without exposing the underlying technical design. Specific fields within each category are handled in accordance with the controls summarised in the DPIA and the Tier Classification.
1. Account identity
What it is. Information that identifies the account holder: the email address used to sign in, and — where the user chooses to provide them — a display name, a country, and a profile picture.
Source. Provided by the user during sign-up or inherited from the identity provider the user chose to sign in with.
Why we hold it. To create the account, authenticate the user, communicate service messages, and personalise the interface.
2. Authentication credentials
What it is. The cryptographic and session material that proves the user's identity when they sign in. This includes:
- Third-party sign-in linkage where the user signs in through an identity provider (e.g. GitHub, Google);
- Active session artefacts created when the user signs in;
- Short-lived one-time tokens issued during email-based verification; and
- Passkey (WebAuthn) registrations where the user has enrolled one.
Source. Generated by Syncflow or by the identity provider at sign-in time; the user does not supply this data directly.
Why we hold it. To authenticate the user and keep them signed in.
3. Account preferences and configuration
What it is. The user's time-zone and working-hours preferences, their notification preferences, their onboarding state, and any optional answers given during onboarding.
Source. Provided by the user through the settings interface.
Why we hold it. To deliver the scheduling and reminder features, and to tailor the interface to the user.
4. Subscription and billing references
What it is. References that identify the user's account inside Syncflow's payment processor. Card details and full billing addresses are collected and stored directly by the payment processor — Syncflow never receives or stores them.
Source. Issued by the payment processor at the time of subscription.
Why we hold it. To check the user's subscription status and to support billing queries.
5. User-generated task content
What it is. The tasks, breakdowns ("crumbs"), reusable templates, export templates, comments, and tags that the user creates inside Syncflow. Free-text fields within this category are written entirely by the user.
Source. Supplied by the user; some crumb content is generated by the AI decomposition feature when the user asks for it.
Why we hold it. This is the core product; without it Syncflow cannot function.
6. Progress and scheduling telemetry
What it is. Information recorded automatically as the user works through their tasks: which crumbs have been started, completed, or skipped, and when; user-recorded actual vs. estimated effort; streak and progress counters.
Source. Generated by the Syncflow application as the user interacts with their own data.
Why we hold it. To surface progress back to the user, to keep streaks and reminders accurate, and to improve future effort estimates for the same user.
7. User-configured integrations
What it is. Optional integrations the user sets up themselves — for example, a user-supplied third-party AI-provider key. Credentials supplied by the user are held encrypted at rest.
Source. Provided by the user when they configure the integration.
Why we hold it. Only to operate the integration the user has requested. The user may revoke the integration at any time.
8. Support and correspondence
What it is. Messages the user sends to Syncflow through support channels, and our replies.
Source. Provided by the user.
Why we hold it. To answer the user's support request and to keep a record of what was agreed.
9. Operational metadata
What it is. Routine service metadata — authentication events, service-availability telemetry, error diagnostics. Request contents (including task content) are excluded from diagnostic telemetry by design.
Source. Generated by the service.
Why we hold it. To operate the service safely, diagnose faults, and respond to security incidents.
Categories of personal data that Syncflow does NOT process
- Special-category data (Art. 9 GDPR): racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic data, biometric data (other than the WebAuthn passkey mechanism, which uses cryptographic keys rather than biometric templates — raw biometrics never leave the user's device), health data, sex life, or sexual orientation.
- Children's data (Art. 8 GDPR): Syncflow is not directed at children and does not knowingly process data from users under 16.
- Criminal-offence data (Art. 10 GDPR): not processed.
- Location data: Syncflow does not collect precise device location.
- Marketing profiles: Syncflow does not build advertising or behavioural profiles of users.
A note on free-text fields
Free-text task and crumb content may, at the user's own volition, contain information that is personal to the user or to third parties. Users are asked in the Privacy Policy not to place special-category, confidential, or third-party-identifying information into task content. The risk arising from this is assessed in the DPIA.
Storage location
Personal data is stored within Syncflow's managed database and, for profile pictures only, within a managed object-storage service. See the Processor Data Flows for a summary of who receives what and where it is processed.