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.
10. Autopilot automation data
What it is. Data created by Autopilot, the feature that lets a user write rules ("when a crumb is due today, draft it") and have Syncflow act on their own tasks for them. It has six parts:
- Rule sets. The rules the user built: the conditions, the actions, the limits they set, and the plain-English explanation of the rule. This is user configuration, not content about the user.
- The run ledger. One row for every decision Autopilot made, whether or not it acted. Each row records which rule fired, on which task or crumb, what was decided, why it was skipped or downgraded, which AI provider and model were used, and how many tokens the request cost. It also stores a snapshot of the facts the decision was based on, so that the question "why did my rule do this" has an answer later. Those facts include the user's own task and crumb text as it stood at that moment.
- Artifacts. The output an action produced: research notes, a plan, a draft, a result from the user's own machine. This is AI-generated content derived from the user's task text, held separately from the task so that nothing the user wrote is ever overwritten.
- Assignments. Work briefs queued for a local executor (see Processor Data Flows §2.7). A brief holds the task and crumb text, the acceptance criteria, and the user's instructions, and nothing else.
- Executor registrations. A record of each local client the user has connected: a client identifier generated on that machine, a name the user gave it, its kind, its declared capabilities, and the time it last checked in. No content.
- The automation profile and limits. The role and self-declared areas of expertise the user entered so that rules can be written about them, their daily capacity, their guardrail settings, and their pause switch. Self-declared expertise is an occupational preference, not special-category data within the meaning of Art. 9.
Autopilot also records crumb expansions: when a crumb is split into smaller ones, a snapshot of the crumb as it was before the split is kept so that the resulting items can still be explained.
Source. Rule sets, the profile and the limits are provided by the user. The ledger, artifacts, assignments and executor registrations are generated by the service while carrying out the rules the user configured.
Why we hold it. To run the automation the user asked for, to show the user what was done on their behalf and why, and to keep that record long enough to investigate a complaint or a security incident.
Tier and retention. The same tier as the task content it is derived from. Retention is not open-ended: see the Tier Classification.
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. Where Autopilot is used, that same text is copied into the fact snapshot on a run and into any artifact or brief derived from it, so it exists in more than one place until the retention period for those records expires. 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.