Privacy Policy

1. Data Controller

The data controller responsible for your personal data is:

• Flow Relay – operated by Adriano Sorbello (sole proprietor)
• Email: support@flowrelay.it
• Website: www.flowrelay.it

2. What we collect

Flow Relay collects work activity data from the integrations you explicitly connect. We only access data that is necessary to provide context synthesis features. Specifically:

• GitHub: Push events (commit messages, authors, file changes and code diffs), pull request events (titles, descriptions, reviewers, labels and code diffs), code reviews and their comments (including the reviewed file path and the surrounding diff hunk), issues and issue comments, published releases, repository discussions and their replies, completed workflow run results, deployment status events, Dependabot, code scanning and secret scanning alerts (the advisory, the rule or the secret TYPE with its severity and where it was found – never the leaked value itself, which is stripped before anything is stored) and GitHub Projects items with the field that changed. We access repository metadata and contents via read-only permissions. We do NOT modify your repositories, dismiss an alert or move a project item, and we never post comments, reviews or any other content back to them.
• GitLab: Push events (including code diffs), merge requests (including code diffs), issues, comments, pipelines, deployments, releases and tag pushes. We request the api and read_user scopes: GitLab offers no narrower scope that can register the project webhooks Flow Relay listens to, and that registration is the only write we make. We do NOT modify your repositories, issues or merge requests.
• Slack: Messages in channels where Flow Relay is explicitly added, including thread replies and reactions. We do NOT access private DMs unless you opt in, and the Slack connection never posts messages to your workspace. The only messages Flow Relay can post are the ones a project manager asks for by giving a project webhook a Slack incoming webhook address (see Webhooks and calendar links below).
• Linear: Issues, comments, projects, project updates, cycles, documents, labels and initiatives. We do NOT create or modify any issues or documents.
• Jira: Issues (creation, updates, deletions), comments, project events, sprints, versions and worklogs. We do NOT create or modify any issues.
• Notion: Page creation and update events. We retrieve page content via the Notion API to include in context summaries. We do NOT modify your pages.
• Discord: When you install our bot in a Discord server, we ingest message text, server (guild) IDs, channel IDs, and the author's Discord username and display name to generate AI-powered handoff summaries. Discord does not provide us with email addresses. Message content is stored securely in our database and processed temporarily by the LLM; it is not retained longer than necessary for summarization. When you explicitly request it (from the dashboard, the API, the MCP server or the VS Code extension), Flow Relay posts a message or a generated summary to a channel you select. We never post to your server on our own initiative.
• Azure DevOps: Push events (including code diffs), pull request events and pull request comments, completed build results and work items (titles, states, field changes and comments). We access repository data via a personal access token (PAT) you provide. We do NOT modify your repositories, work items or projects.
• Bitbucket: Push events (including code diffs), pull requests, approvals, PR comments and pipeline results (delivered as commit status events) via webhook and read-only API access. We do NOT modify your repositories.
• Figma: File update events, version publications and comment activity. Using your OAuth token we retrieve file metadata, comments and the file contents needed to build a textual description of your designs (pages, frames, layout, text layers and prototype flows). Design variables are read only if you opt in when connecting. When you explicitly select Figma as context for a generation, rendered images of a limited number of top-level frames may be sent to the AI model. We do NOT modify your files or post comments.
• Confluence: Page creation, page update, and comment events received via user-configured Atlassian Global Automation rules. When an event is received, we use your OAuth access token to fetch the full page content or comment text from the Confluence Cloud API (v2), along with metadata such as page titles, page IDs and space keys. The raw HTML is stripped to plain text before storage. This data processing is an essential functional component of the core service – it enables Flow Relay to include knowledge base context in handoff summaries. We do NOT modify your Confluence pages or comments.
• Microsoft Outlook: Email metadata and message content from your Outlook inbox and sent items, plus calendar entries (subject, organizer, attendees, start and end times and the agenda preview), fetched securely via the Microsoft Graph API using your OAuth token. Data is used exclusively for Just-In-Time (JIT) AI handoff generation and respects your organization's global policies. We do NOT send, modify or delete any emails, and we do NOT create, modify or cancel any meetings.
• Microsoft Teams: Chat messages and channel messages fetched securely via the Microsoft Graph API using your OAuth token. Data is used exclusively for Just-In-Time (JIT) AI handoff generation and respects your organization's global policies. Connecting may require Workspace Administrator approval (Admin Consent). We do NOT send, modify, or delete any messages.
• Sentry: Issue and error events received via signed webhooks, including the issue title, culprit, stack traces, breadcrumbs, tags and the project and organization slugs. We use this to surface error context in handoffs and insights. We do NOT modify your Sentry projects.
• Datadog: Monitor and event notifications delivered to a Flow Relay webhook, including the alert title, body, priority and tags you configure. We also read your active incidents and monitors via the Datadog API to include observability context in summaries. We do NOT create or modify any monitors or incidents.
• PagerDuty: Active incidents and on-call assignments read via the PagerDuty API using your read-only OAuth token, and – when a webhook subscription is configured – incident lifecycle events, including the incident title, service, urgency, priority and status. We use this to surface incident context in handoffs and insights. We do NOT create, modify or resolve any incidents.
• Asana: Task and comment events received via per-project webhooks. When an event arrives we use your OAuth access token to fetch the task or comment detail from the Asana API, including task names, notes, assignees, due dates, sections and project names. We also read open tasks per project to build a workspace baseline. We do NOT create, modify or complete any tasks.
• Buildkite: Finished-build events delivered to a Flow Relay webhook, including the pipeline name, build number, state, branch, commit message and the user who triggered the build. We also read your pipelines and recent builds via the Buildkite API using your read-only access token to include CI context in summaries. We do NOT create, retry or cancel any builds.
• CircleCI: Completed-workflow events delivered to a Flow Relay webhook, including the project name, workflow name, pipeline number, status, branch, commit message and the user who triggered the pipeline. We also read your projects and recent pipelines via the CircleCI API using your personal API token to include CI context in summaries. We do NOT create, retry or cancel any pipelines.
• Vercel: Deployment events delivered to a Flow Relay webhook, including the project name, deployment status, target environment, branch, commit message and the commit author. We also read your teams, projects and recent deployments via the Vercel API using your access token to include deployment context in summaries. We do NOT create, redeploy or delete any deployments.
• incident.io: Public incident events delivered to a Flow Relay webhook, including the incident name, reference, status, severity, incident type, lead and summary. We also read your recent incidents, severities and incident types via the incident.io API using your API key to include incident context in summaries. Private incidents deliver IDs only and are not ingested. We do NOT create, update or resolve any incidents.
• Netlify: Finished-deploy events delivered to a Flow Relay webhook, including the site name, deploy state, context, branch, commit message and the committer. We also read your sites and recent deploys via the Netlify API using your personal access token to include deployment context in summaries. We do NOT trigger, lock or delete any deploys.
• Render: Finished build and deploy events delivered to a Flow Relay webhook, including the service name and the outcome. We also read your services and recent deploys via the Render API using your API key to include deployment context in summaries. We do NOT create, redeploy, suspend or delete any services.
• Railway: Deployment events delivered to a Flow Relay webhook, including the project, service and environment names, the status, branch, commit message and the commit author. We also read your projects, services and recent deployments via the Railway API using your account token to include deployment context in summaries. We do NOT deploy, restart or remove anything.
• Cloudflare Pages: Deployment notifications delivered to a Flow Relay webhook, including the project name, environment, branch and deployment outcome. We also read your Pages projects and recent deployments via the Cloudflare API using your read-only API token to include deployment context in summaries. We do NOT create, retry or delete any deployments.
• ClickUp: Task and comment events received via webhooks on the workspaces you select. The event carries ids only, so we call the ClickUp API with your access token to fetch the task detail (name, description, status, priority, assignee, space and list) and the latest comment. We also read your workspaces, spaces and open tasks to include task context in summaries. We do NOT create, move, close or delete anything.
• monday.com: Item events received via webhooks on the boards you select – creation, column changes, updates, renames, archiving and deletion. The delivery is id-heavy, so we call the monday.com GraphQL API with your access token to fetch the item detail (name, board, group, state, column values) and the name of the person who acted. We also read your boards and their items to include board context in summaries. We do NOT create, move or delete anything.
• Shortcut: Story, epic and iteration events delivered to a Flow Relay webhook, including the entity name, the fields that changed and the link back to Shortcut. We call the Shortcut API with your API token to resolve the owning team and the name of the person who acted, and we read your teams and open stories to include story context in summaries. We do NOT create, move or close anything.
• Intercom: Customer conversation and ticket events delivered to a Flow Relay webhook: conversation created, user and admin replies, internal notes, assignment, close, reopen, snooze, rating and priority changes, plus ticket creation and state changes. The notification carries the conversation or ticket itself, so the message bodies are stored as text; we use your access token only to resolve the name of the team a conversation is assigned to. We do NOT reply to conversations, assign them or change their state.
• Zendesk: Ticket events delivered to a Flow Relay webhook: creation, status, priority, assignee, group and tag changes, and comments added. The delivery carries the ticket detail, including its subject, description and comment text. We use your API token to resolve the group behind a ticket and the name of the agent or requester who acted, and to read open tickets for the periodic snapshot. We do NOT create, update or solve tickets.
• Snyk: Project scan results delivered to a Flow Relay webhook: the monitored project, its organization, and the vulnerabilities opened or closed by the scan (title, severity, affected package and version, link back to Snyk). A scan that neither opened nor closed an issue is discarded. We use your API token to read your organizations and monitored projects for the periodic snapshot. We do NOT change project settings, ignore issues or trigger scans.
• Fireflies: Meeting transcripts. When a meeting finishes processing, Fireflies notifies a Flow Relay webhook and we call the Fireflies API with your API key to retrieve that meeting: its title, date, duration, organizer, participant list, the AI-generated summary and action items, and the full transcript text with speaker names and timestamps. A transcript can contain anything that was said in the meeting, including remarks about people who are not Flow Relay users, so no transcript reaches a project unless you add a rule on that project matching the meeting organizer or title. While a transcript is in scope for a project, generations for it never run on China-hosted models, whatever the project setting says. We do NOT start, edit or delete recordings.
• Zoom: Meeting transcripts. When a cloud recording finishes transcribing, Zoom notifies a Flow Relay webhook and we use your Zoom token to read that meeting: its topic, date, duration, host, share link and the transcript text with speaker names and timestamps. A transcript can contain anything that was said in the meeting, including remarks about people who are not Flow Relay users, so no transcript reaches a project unless you add a rule on that project matching the meeting organizer or title. While a transcript is in scope for a project, generations for it never run on China-hosted models, whatever the project setting says. We only ever read recordings that already exist – we do NOT start, join, record, edit or delete a meeting.
• Google Meet: Meeting transcripts. On a schedule we read, through the Meet REST API, the conferences you organized that ended since the last pass and, for each one whose transcript is ready, its participants and the transcript entries with speaker names and timestamps. We also read your primary calendar to name the meeting and list its attendees, because the Meet API carries neither. A transcript can contain anything that was said in the meeting, including remarks about people who are not Flow Relay users, so no transcript reaches a project unless you add a rule on that project matching the meeting organizer or title. While a transcript is in scope for a project, generations for it never run on China-hosted models, whatever the project setting says. We do NOT open the Google Docs transcript file in your Drive, and we do NOT create, join, record or change a meeting.
• Microsoft Teams meetings: Meeting transcripts. On a schedule we read, through Microsoft Graph, the Teams meetings on your calendar that ended since the last pass (the ones you organized and the ones you were invited to) and, for each one with a transcript, its text with speaker names and timestamps, plus the meeting subject, organizer and attendees. Access to transcripts is granted by your Microsoft 365 administrator and can be switched off tenant-wide at any time. A transcript can contain anything that was said in the meeting, including remarks about people who are not Flow Relay users, so no transcript reaches a project unless you add a rule on that project matching the meeting organizer or title. While a transcript is in scope for a project, generations for it never run on China-hosted models, whatever the project setting says. We do NOT read Teams chat through this connection, and we do NOT schedule, join, record or change a meeting.
• Fathom: Meeting transcripts. When a meeting you recorded finishes processing, Fathom delivers it to a Flow Relay webhook we register with your API key: its title, date, duration, recorder, calendar invitees, the AI-generated summary and action items plus the full transcript text with speaker names and timestamps. We use the same key to read a summary-only snapshot of your recent meetings. A transcript can contain anything that was said in the meeting, including remarks about people who are not Flow Relay users, so no transcript reaches a project unless you add a rule on that project matching the meeting organizer or title. While a transcript is in scope for a project, generations for it never run on China-hosted models, whatever the project setting says. We do NOT read other people's recordings, and we do NOT start, edit, share or delete a recording. Disconnecting removes the webhook.
• Grafana: Alerts delivered to a Flow Relay webhook by a contact point you configure: the rule name, its folder, the alert labels and annotations, the severity, when it started and when it resolved, and the links back to the rule and dashboard. We use your service account token to read your alert rules and their current state for the periodic snapshot. We do NOT read dashboards, query your metrics or log data, silence alerts or change any rule.
• Google Calendar: Events from the calendars you connect: title, start and end time, organizer, attendee list, location, the description or agenda and the event link. This tells Flow Relay the rhythm of a project – ceremonies, incident bridges and who was in the room. We use read-only access and do NOT create, edit, move, accept or delete anything on your calendar.
• Google Drive: Only the documents you hand us. Flow Relay holds the narrow drive.file permission, which grants access to individual files you select through the Google picker and to nothing else in your Drive – we cannot list, search or open any other file, and removing a document from the selection stops it being read from the next sync. For a selected document we read its text, name, last modified time and the person who last changed it. We do NOT create, edit, rename, share or delete files.
• LaunchDarkly: Feature-flag activity delivered to a Flow Relay webhook: the flag or segment that changed, the project and environment it lives in, the action taken, the person who took it, any comment they left and the link back to LaunchDarkly. We use your access token to read your projects and a summary of their flags for the periodic snapshot. We do NOT read user targeting data, evaluate flags for your end users, create a flag or change any targeting rule.
• HCP Terraform: Run outcomes delivered to a Flow Relay webhook by a notification you configure: the workspace and organization, the run status, its message, who triggered it and the link back to the run. We use your API token to read your organizations, workspaces and recent runs for the periodic snapshot. We do NOT read your state files, variables or outputs, and we never queue a plan or apply a run.
• SonarQube: Analysis results delivered to a Flow Relay webhook: the project and branch analysed, the quality gate verdict and the conditions that failed it, with their measured values and thresholds. We use your user token to read your projects and their current gate status for the periodic snapshot. We do NOT read your source code, and we never trigger an analysis or resolve an issue.
• Miro: The text on the boards your account can read: board name and description, the content of sticky notes, text, shapes, cards and frames, when the board was last changed and by whom. Images and drawings on a board are not read. We do NOT create, edit, move or delete anything on a board.
• New Relic: Alert activity delivered to a Flow Relay webhook by a workflow destination you configure: the issue title and state, its priority, the alert policy and conditions behind it, the impacted entities and the link back to New Relic. We use your user key to read your accounts, alert policies and open issues for the periodic snapshot. We do NOT query your telemetry, logs or traces, and we never create a policy or acknowledge an issue.
• Jira Service Management: Service desk activity delivered to a Flow Relay webhook: the request key and summary, its project, request type, status, priority, resolution, reporter and assignee, the text of the request and of its comments, and who raised or changed it. We use your Atlassian token to read your service desks and their open requests for the periodic snapshot. We do NOT read customer attachments, and we never raise, transition, comment on or close a request.
• PostHog: Your feature flags and their rollout state, your experiments and when they started or ended, and the annotations your team writes, with their author. We use your personal API key to read those for the periodic snapshot. We do NOT query your event data, read a session recording, look at any end-user profile, or change a flag or an experiment.
• HubSpot: Deal and ticket activity delivered to a Flow Relay webhook: the deal or ticket name, its pipeline and stage, the amount, close date and priority of a deal, the priority and description of a ticket, the property that changed and the owner it belongs to. We use your access token to read those objects and your pipelines. We do NOT read contacts, companies, marketing lists or email conversations, and we never create or edit a record.
• Salesforce: Opportunity and case activity read on a schedule: the opportunity name, stage, amount and close date, the case number, subject, status and priority, the account each belongs to and its owner. We do NOT read contacts, leads, campaigns, email or any custom object, and we never create or edit a record. Salesforce has no webhook we can register, so nothing is pushed to us: the connection is read-only and periodic.
• Heroku: Releases and failed builds delivered by the app webhooks Flow Relay registers on the apps you pick: the app name, release version and status, the release description (a deploy, a config var or add-on change), the commit it shipped and the email of the person who triggered it. We use your API key to read your apps and their recent releases for the periodic snapshot and to register or remove those webhooks. We do NOT read config var values, logs or dyno output, and we never deploy, restart, scale or change an app.
• Prometheus Alertmanager: Alerts delivered to a Flow Relay receiver you configure: the alert name, its labels and annotations, the severity, the receiver, when it started and when it resolved, and the links back to the source. Flow Relay holds no credential for your cluster and pulls nothing from it – only the alert groups you route to the receiver reach us. We do NOT silence, inhibit or change any rule.
• Pulumi Cloud: Stack updates, destroys, stack creation and deletion and policy violations delivered by the organization webhooks Flow Relay registers: the organization, project and stack name, the operation and its result, the resource change counts, the policy that was violated and the name of the person who ran it. We use your access token to read your organizations, stacks and latest update summaries for the periodic snapshot and to register or remove those webhooks. We do NOT read your stack state, outputs, secrets or config values, and we never run an update or touch a stack.
• Work management: The plans you and your team build in Flow Relay: work items (titles, descriptions, statuses, dates, durations, progress, dependencies and who they are assigned to), comments and the people they mention, your notification preferences (channels, kinds and quiet hours) and your time zone. A change history records who changed which field of a plan and when; for long texts it keeps only the length, never a copy. Saved baselines keep a copy of the plan dates at the moment they were saved, and custom fields hold the values your team enters.
• Plan imports: When you import an MS Project or CSV file, the file is stored privately until the import is applied or discarded, and for 7 days at most. The names and email addresses of the people listed in the file are used only to suggest which project member each one is, and are dropped with the import preview at the same time as the file.
• Evidence links: When evidence linking is on, activity from your connected integrations that mentions a work item key (a commit, branch, pull request, ticket or message) is linked to that item: the source, the kind, the reference (such as a commit hash), the title, the link, the time and the id the source tool gives to its author. Nothing new is collected for this: the link is made from activity the integrations already deliver. In organization projects it starts only after every member received a notice at least 24 hours in advance.
• Linked accounts: The accounts of connected tools that belong to you: the tool, the account id, the username and the display name the tool reports. A link is created when you connect your own account, when you confirm a link an organization admin proposed or when an admin confirms an account you claimed – never by matching names or email addresses. It is used only to show who did the work linked to a work item, and you can dispute or remove it at any time in Settings.
• Suggestions: When a project turns them on, activity that names no work item key is compared with the open items of the project through embeddings of their titles and descriptions, which stay inside Flow Relay, and a close match is suggested only to the person who did the work. Pull requests and deploys linked to an item can suggest a new status to its assignee, and the action items of Fathom and Fireflies meeting summaries can suggest new items. Nothing is applied until someone accepts it, and suggestions nobody decides expire after 30 days.
• Mirrored trackers: When a project mirrors a Jira project, a Linear team, GitHub or GitLab issues, Azure Boards work items, an Asana project, a ClickUp space, a monday.com board or a Shortcut team, the issues in scope are copied into the plan: title, description, status, dates, sprint or cycle, the assignee the tracker names and the link back. We only read the tracker and never create, edit or close an issue.
• AI plan drafts: The brief you write or the meeting transcript you pick is sent to an AI provider to draft a plan, which is kept only as an import preview until you apply or discard it. Drafts never assign anyone.
• Capacity and days off: The availability and working week an organization admin sets for each member, the skills and role label entered for them, and the days you are not available. Days off never carry a reason: you enter only dates, and importing from your own Google Calendar or Outlook keeps only the dates of out-of-office entries, never their titles, attendees or descriptions. Past days off are deleted 90 days after they end. Project managers use this to see planned work against available time; in organization projects only after the workload policy was announced to every member at least 24 hours in advance.
• Timesheets: When you or your organization use time tracking, the hours you log per day, project and work item, optional notes, the weekly status (draft, submitted, approved or sent back), the admin who reviewed it and their comment. Project managers see the hours logged on their own projects only. A running timer stays in your browser, and the suggestion that fills a week from your linked work is computed for you and never stored.
• Costs and rates: When an organization prices its plans, the hourly rate of each resource (with the date it applies from), the fixed costs and budgets of items and the currency. Rates are set by organization admins, are visible to project managers only and are never sent to an AI model. Cost reports and earned value are computed from the plan, the baselines and the hours logged, and show totals rather than the cost of one person.
• Forecasts, scenarios and flow metrics: Simulated finish dates of a plan (kept with their inputs so they can be checked later), what-if scenarios with the changes they try and the question that produced them, and – when the organization turned the policy on and the project has at least five members – counts of items finished per week, cycle times, deployment counts and recovery times derived from build, deploy and merge events. They describe a plan and a team and are never split per person. A what-if question is sent to an AI provider with the keys, titles, dates and durations of open items, and no member's name.
• Automations, recurring items, templates, saved views and files: The rules a project manager sets up (a trigger, conditions, actions and the manager they act as), a log of what each rule did kept for 30 days, recurring items and the dates they repeat on, templates (names, notes, durations and links – never people, dates or progress), the filters you save as a view, and the files you attach to an item, kept in private storage and opened through short-lived links. Automations never call an AI model and never spend credits.
• Webhooks and calendar links: When a project manager adds a webhook, Flow Relay sends the address they chose (an HTTPS address, a Slack incoming webhook or a Microsoft Teams workflow) a message when the plan changes: the item key, its name, status and dates and the project – never a person. The address and the signing secret are stored encrypted, and the deliveries are kept for 14 days. A calendar link you create in Settings lists the items assigned to you with their dates for your own calendar app; only a hash of the link is stored and you can remove it at any time.
• Portfolio: Programs that group an organization's projects, a nightly health verdict per project (computed from the plan – slip against the baseline, overdue items, scope added – and from counts of recent build, deploy and incident events) with the comment and the author of a verdict set by hand, links between items of different projects, project requests with their scores and decisions, and goals with their key results, links and check-ins. Capacity by role and month is shown to organization admins only when the organization turned workload on, and never for a role or a pool of fewer than three people. None of this is a measure of a person.
• Risk register: The risks, assumptions, issues, decisions and dependencies a project records: title, description, score, response, due date, owner and linked item. A plan review (an AI status report) reads the totals and indices of the plan and the last 14 days of linked activity, and never assigns or judges anyone.
• Weekly reviews: When you ask for one, your own work items and their linked activity of the week are sent to an AI provider to write a review that only you can read. It is kept for 180 days.
• Change requests, custom roles and restricted fields: A change request keeps its title, the note of the person who asked, a plain-language summary of the change, the operations to apply, who asked, who decided and when. A custom role names what its holders may see (costs, restricted fields) and whether they can decide requests; a restricted field's values are hidden from everyone whose role does not allow them, in the app and in exports.
• Sharing with stakeholders: A share link lists a read-only view of a plan – overall progress, milestones and the top of the outline with their dates – and never people, comments, descriptions, evidence or costs. Only a hash of the link is stored, with its label, its expiry and how many times it was opened and when last. A guest is a person a project manager invited by email: we keep the address, the access they were given and its dates, and the guest signs in with a Flow Relay account on that address. Both stop working at their expiry and are deleted 90 days later.
• Single sign-on and provisioning: An organization can prove it owns an email domain with a DNS record and let people on it sign in through its identity provider, which tells us the person's email address and name. With SCIM provisioning the identity provider creates, updates and deactivates the accounts of members and their teams: we keep the address it sends, an optional external id and whether the person is active, and only addresses on a verified domain are accepted. The provisioning tokens are stored as hashes.
• Change history export and legal hold: Organization admins can download the change history of their plans, and each download is itself recorded. An organization can set how long the history is kept (6 to 120 months) and place a legal hold with a written reason, which suspends every deletion of that history until it is released.
• Account data: Email address, name, and authentication tokens for connected services.

3. Legal basis for processing (GDPR Art. 6)

We process your personal data based on the following legal grounds:

• Contractual necessity (Art. 6(1)(b)): Processing your work activity data is necessary to deliver the core service you signed up for – generating context handoffs.
• Consent (Art. 6(1)(a)): You explicitly choose which integrations to connect and which data to share with Flow Relay. You can disconnect any integration at any time.
• Legitimate interest (Art. 6(1)(f)): For security monitoring and fraud prevention.

4. How we use your data

Your data is used exclusively to:

• Generate context summaries and handoff briefs.
• Create vector embeddings for semantic search within your own workspace.
• Improve the relevance of AI-generated summaries for your team.
• Schedule your plans, notify you about the work assigned to you, link activity that mentions a work item key to that item and suggest evidence, status changes and new items for a person to accept.
• Show planned work against available time, level overallocated plans and record the hours people log, with the deterministic algorithms of the scheduler – never an AI model.

We do not use work data to evaluate, score, rank or compare people. Flow Relay has no productivity score, no online status and no per-person list of activity, and every AI generation is instructed to describe the work rather than the people doing it.

We do not use your data to train AI models. Your work data is never shared with third parties for advertising or any purpose other than providing the service.

5. AI processing and data residency

We use third-party large language models to generate summaries and analyses. Which provider processes your data depends on the data residency you choose for each project:

• Default region: Google AI (Gemini), processed on Google's servers in the United States.
• EU residency: open-model endpoints hosted in the European Union – Qwen and Gemma, served by Scaleway in France, and Mistral models on Mistral AI's EU endpoint. The model weights may originate outside the EU, but the inference – and therefore the processing of your data – runs inside the EU. When you select EU residency for a project, its context is not sent to providers outside the EU.
• Chinese providers (opt-in only): DeepSeek, processed on servers in China, is used only if the project owner or an administrator explicitly enables Chinese providers for that project. It is off by default, and it is unavailable entirely while the project reads meeting transcripts.

In all cases:

• Only the minimum necessary context is sent – event metadata, descriptions, semantically retrieved code excerpts, code diffs (truncated to a maximum length) and, only when you select Figma as context, rendered images of a limited number of design frames – never your full repository contents or history.
• Data is transmitted via encrypted connections (TLS).
• Vector embeddings used for semantic search within your own workspace are computed by an open-model embedding endpoint hosted in the European Union, for all projects regardless of the selected residency.
• Each provider's API data-usage policy applies; data sent via their APIs is not used to train their models, and we do not use your data to train any model.

6. Third-party services and international data transfers

Your data may be processed by the following third-party services:

• Vercel: The application's serverless functions run in Vercel's Dublin, Ireland (eu-west-1) region. On our public pages we also use Vercel Speed Insights to collect anonymous, aggregated performance metrics (Core Web Vitals). It sets no cookies, collects no personal identifiers and does not track you across sites. Vercel complies with GDPR and offers a Data Processing Agreement (DPA).
• AI model providers: Depending on the data residency you choose (see section 5), text excerpts – and, when you explicitly select Figma as context for a generation, rendered images of design frames – are sent to Google AI / Gemini (United States, under Standard Contractual Clauses), to Scaleway in France (European Union), to Mistral AI on its EU endpoint (European Union), or – only if you explicitly opt in – to DeepSeek (China). Where the opt-in is enabled, this includes the Figma frame renders described above.
• Supabase: Your data is stored in a PostgreSQL database hosted by Supabase in Ireland (eu-west-1). Note that the data residency setting on a project controls which AI providers process its context (see section 5), not where the database itself is located. Supabase complies with GDPR and offers Data Processing Agreements (DPAs).
• Render: Our background worker – which processes queued jobs, generates AI summaries and runs the Discord bot – runs on Render in Frankfurt, Germany (EU Central). Render complies with GDPR and offers a Data Processing Agreement (DPA).
• Paddle: Paddle.com Market Ltd is our authorised reseller and Merchant of Record. It processes your payment data, billing details and tax information to handle subscriptions, invoices and refunds. We never receive or store your full card details. Paddle complies with GDPR.
• Upstash: Redis-based job queuing, rate limiting and short-lived deduplication keys (IP- or account-scoped) used to run and protect the Service, hosted in Ireland (eu-west-1). Rate-limit and dedup records are ephemeral and contain no message content.
• Sentry: Application error and performance data (used for our own monitoring) may include technical context such as stack traces and request metadata. Plan and quota errors are not forwarded.
• Brevo: Transactional emails (e.g., password resets, handoff notifications) are processed via Brevo's EU-based infrastructure.
• KIProtect (Klaro): Our cookie consent manager is loaded from KIProtect's CDN (Germany). Klaro does not collect or transmit any personal data – consent preferences are stored locally in your browser.

7. Data storage and security

• All data is stored in Supabase (PostgreSQL) with Row Level Security enabled.
• Integration access tokens are encrypted at rest.
• All connections use TLS encryption.
• Two-factor authentication (TOTP) is available for all accounts.
• API keys for the VS Code extension and MCP server are hashed before storage – we cannot see your raw key after creation.
• We do not store data longer than necessary – you can delete your data at any time.

8. Cookies and local storage

We use only essential cookies required for authentication. We do not use third-party tracking, advertising, or analytics cookies. We use Klaro as our consent management tool so you can review and manage your preferences at any time.

No data stored in localStorage is transmitted to any server. These values remain entirely in your browser.

9. Your rights (GDPR)

If you are in the EU/EEA, you have the right to:

• Access your personal data (Art. 15).
• Rectify inaccurate data (Art. 16).
• Erase your data – "right to be forgotten" (Art. 17).
• Restrict processing (Art. 18).
• Port your data to another service (Art. 20).
• Object to processing (Art. 21).
• Withdraw consent at any time without affecting the lawfulness of prior processing (Art. 7(3)).

To exercise these rights, contact us at support@flowrelay.it. We will respond within 30 days.

10. Supervisory authority

If you believe your data protection rights have been violated, you have the right to lodge a complaint with your local supervisory authority. In Italy, this is the Garante per la protezione dei dati personali.

11. Data retention

We retain your data for as long as your account is active. When you delete your account, all associated data (events, handoffs, embeddings and integration tokens) is permanently deleted within 30 days.

Within an active account, work management data has shorter limits: the change history of plans is deleted after 24 months (or the period an Enterprise organization sets, unless a legal hold is in place), deleted work items, dependencies, assignments and comments can be restored for 30 days and are then deleted, read notifications are deleted after 90 days and unread ones after 180 days. Deleting a project or an organization deletes its plans and their change history.

12. Children's privacy

Flow Relay is not intended for use by anyone under the age of 18. We do not knowingly collect personal data from children.

13. Changes to this policy

We will notify you of material changes via email or in-app notification at least 30 days before they take effect. Continued use of the service after that period constitutes acceptance of the updated policy.