People data and privacy

Flow Relay shows work, not workers. A plan tells a team what is done, what is late and what is next. It never tells a manager how busy, fast or good a person is. This page lists exactly what is visible and to whom, so an organization can explain it to the people who use it.

Every member can read the same list, applied to their own organizations, in Settings > Work visibility.

Everyone with access to a project sees, on the items of that project:

• who an item is assigned to, its status, dates, progress, comments and history;
• the activity linked to an item because it mentions the item key – a commit, branch, pull request, ticket or message (see Evidence linking);
• the name of whoever made a change, in the history of the item and in generated handoffs and insights;
• the author of linked activity, only through a linked account the person confirmed and, in organization projects, only while the Named authors on linked activity policy is on. Otherwise linked activity shows no author;
• the days a person is not available, as unavailable days without a reason, so plans do not count on them.

Some things Flow Relay notices are offered as suggestions instead of being applied:

• Suggested evidence – work that names no item key but looks related to an open item – is shown only to the person who did the work. When no linked account names that person, project managers see it instead. Chat, email and meetings are never suggested.
• Status suggestions (a pull request opened or merged, a deploy that shipped a linked commit) go to the person assigned to the item first. After three working days without a decision, project managers see them as a flag on the item.
• Quiet items – In progress with no linked activity for a while – nudge the assignee first and show as Quiet to project managers three working days later. It is a fact about the item, not about the person.
• New items from meeting action items carry the text of the action item and never an assignee.

Nothing is applied until someone accepts it.

These show how much work is planned for a person, so they are off in organization projects until an admin turns the matching policy on, with the notice described below.

• Workload (policy Workload for managers). Project managers see, for each member of their project, the hours of planned work that fall on each day against the time the member is available, and the items that make them up. Work the same person has in other projects shows as one number, never as items. The team view adds counts about the items assigned to each person – in progress, blocked, overdue, due within 7 days, finished in the last 14 days. Everything comes from the plan: none of it is activity. Without the policy each member sees only their own row, and every member can see their row exactly as their managers see it in Settings > Work visibility > How your project managers see you.
• Availability. A resource's availability (for example 50% for a part-time member) and working week are set by the organization admins and shown to project managers only. Days off are entered by the person, never with a reason, and appear to everyone in the project as unavailable days.
• Hours (policy Time tracking). Members log hours in a weekly timesheet. Project managers see the hours logged on their own projects and nowhere else; with Timesheet approval on, only the weeks that were submitted, and the admins who approve a week see all of it. A timer runs only in the member's own browser, and the suggestion that fills a timesheet from linked work is computed for the member and shown to nobody else.
• Costs. Hourly rates are personal data about pay, so they are visible to project managers only – or to the people whose custom role allows costs – set by organization admins, never shown on an item and never sent to an AI model. Cost reports total the hours people logged at their rate; nothing lists what one person cost. A plan review reads the totals and the indices of the plan, not who worked.
• Capacity across projects (policy Workload for managers). Organization admins see planned work against available hours by role and month. A role with fewer than 3 people is folded into a shared row and a pool of fewer than 3 people shows nothing, so the table never stands for one person. Work assigned to a placeholder counts as demand nobody holds yet.
• Flow and delivery metrics (policy Flow and delivery metrics for teams). Items finished per week, the time from start to finish, work in progress and its age, and from build, deploy and merge events how often the project deploys and how often it fails. They count items and events of the project, appear only when the project has at least five members and are never split per person; the oldest items are listed by key, not by who works on them. Forecasts and scenarios read the plan only: they use no activity and no person's data.
• AI summaries (policy Roles instead of names in AI summaries). Handoffs, insights and digests normally name who made a change. With this policy they name the person's project team instead.

In personal projects there is nobody else to see these: the owner always sees their own workload and hours.

• Activity that mentions no item key. It stays with the connection it came from, and at most becomes a suggestion as described above. Flow Relay has no view, API or report that lists what one person did.
• Online status or presence. Flow Relay does not track who is online, typing or looking at a plan.
• Your weekly review. The review of your week that My work writes on request is stored for you alone; it runs without a job that project members could see and is charged to your own plan.
• Who is slow. Late and slipping lists items, the burnup and the cumulative flow count items, and the risk register describes the work: none of them names the person behind a delay, and a plan review is instructed the same way.
• Project health. The verdict of a project comes from its plan and from build, deploy and incident counts; none of it is attributed to a person. Goals have an owner and check-ins with the name of who wrote them, as a goal does anywhere; there is no view of goals or health per person.
• Reasons for days off. Flow Relay never asks for one, and an imported calendar contributes dates only – no title, attendees or description.
• Scores. There are no activity counts, productivity scores, rankings or comparisons between people, and no field where one could be stored.
• AI judgements about people. Every AI generation carries an instruction to describe the work and never evaluate, rank or compare the people doing it. The plan summary the AI reads names no assignees, and no capacity, workload or hours of a person ever reach a prompt. A plan drafted by AI never assigns anyone.

Dates, progress, slack and the critical path are computed by a deterministic scheduler, not by a model.

To say who did a piece of work, Flow Relay needs to know which account in a tool belongs to which person. It never guesses that from a display name or an email address. A link exists only in one of three ways:

1. You connect your own account (GitHub, GitLab, Jira, Linear, Slack and the other tools with a user). The link is yours and confirmed at once.
2. An organization admin proposes a link in Member accounts on the organization page, and you confirm it.
3. You claim an account of a tool in Settings > Work visibility > Claim an account, and an admin confirms it.

Nobody can attribute activity to someone else alone. Every link is listed in Settings > Work visibility > Accounts linked to you, where you can dispute or remove it; the name then disappears from every item at once, because authors are resolved when a page is read and never copied into the items. A link stores the tool, the account id, the username and the display name the tool reports.

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, each mirrored item shows the assignee the tracker names – resolved to a Flow Relay member only through a linked account. Flow Relay reads the tracker and never writes to it.

• Automations act as the project manager who last saved the rule, are recorded in the history as an automation and never start another automation. They read the plan (status, dates, custom fields) and an event's source, type and title; they never read or write anyone's hours, availability or activity, never call an AI model and never spend credits. A rule can notify the assignees, the creator or the project managers of an item it acts on, the same people who would hear about a manual change.
• Webhooks send the item key, name, status, progress and dates and the project name to an address a project manager chose. They never carry a name, an email address or an assignee. The address and the signing secret are stored encrypted.
• A calendar link lists the items assigned to the person who created it. Anyone holding the link can read that list, so it works like a password: only a hash is stored and the person can remove it from Settings > Calendar feed at any time.
• Files, templates and saved views belong to the project (files, shared views), to the organization or the person (templates) or to the person (their own views). A template keeps names, notes, durations and links and never people, dates or progress.

See Governance and enterprise controls for how each of these works.

• Share links and guests show a read-only view of a plan – progress, milestones and the top of the outline with dates. It never shows people, comments, descriptions, linked activity or costs, links expire after at most 180 days, and a guest is a named person who signs in with the invited address and is not a member of the organization.
• Change requests show what is asked, by whom and who decided. They exist on organization projects, where a second person decides.
• Single sign-on and SCIM let an organization sign people in through its identity provider and keep its members and teams in step with its directory. Only addresses on a domain the organization proved it owns are provisioned.
• The change history export is for organization admins, covers the plans of the organization, cannot be filtered by person, and each export is itself recorded. A legal hold suspends every deletion of the history until it is released.

An organization admin can turn on features that let the project see more:

Roles instead of names in AI summaries works the other way – it makes AI summaries name teams instead of people – and follows the same notice.

Such a change:

1. is announced to every member in the app and by email, with the text the admin wrote;
2. takes effect at least 24 hours later;
3. stays in the history of the organization, visible to every member.

Turning a feature off takes effect at once. Every change of this kind appears in Settings > Work visibility, with its date and its notice.

Notifications about work land in the inbox. Push notifications and the email digest respect quiet hours, on by default from 19:00 to 08:00 and all weekend in your own time zone: they wait until the quiet hours end, the inbox still updates. Each person chooses the channels, the kinds of notification and the quiet hours in Settings > Notifications.

Deleting a project or an organization deletes its plan and its change history. Deleting an account keeps the changes the person made, attributed to a deleted user, renames their place in resource lists to "Former member" and deletes their linked accounts.

Flow Relay is a work tool: plans, tasks and their history are what the team uses to do the work. If your organization is subject to rules on the monitoring of workers – in Italy article 4 of the Workers' Statute and the guidance of the Garante, the information duties on AI systems of Law 132/2025, similar rules elsewhere in the EU – inform the people who use Flow Relay about what it records and how you use it, and do not use it to evaluate performance. The notices Flow Relay sends before a visibility change are a help for that, not a substitute.

A notice you can adapt

The text below is a starting point for the information you give your team. Adapt it to what you turned on, and have it reviewed by whoever advises you on employment and data protection.

We use Flow Relay to plan our projects. It records the work items of each project,
who they are assigned to, their status, dates, comments and change history. When
[Evidence linking] is on, commits, pull requests, tickets and messages that mention an
item key are linked to that item and are visible to the project; activity that
mentions no key is not shown to anyone else.
 
[If Workload for managers is on:] Project managers see how many hours of planned work
fall on each of us compared with the time we are available. They do not see activity,
and days off appear without a reason.
[If Time tracking is on:] We log our hours in a weekly timesheet. Project managers see
the hours logged on their own projects.
 
We do not use Flow Relay to evaluate, score or compare people. You can see what the
organization sees about your work in Settings > Work visibility, and you are told at
least 24 hours before any of this changes. Questions: [contact].

Impact assessment

If you run a data protection impact assessment, the points Flow Relay can answer are listed on this page: the data per feature (what the project sees, workload, hours and availability), who sees it, the retention, the safeguards (policies with advance notice, no scores, no per-person activity views, disputes of linked accounts) and where processing happens (the data residency of each project). The purposes, the legal basis and the balance with your team's interests are yours to set.

AI Act

Flow Relay's AI features – plan drafts, handoffs, insights, digests and the weekly review – describe work. They do not allocate tasks based on people's behaviour or traits, do not monitor or evaluate performance and never assign anyone: a drafted plan leaves every item unassigned. Scheduling, the critical path, capacity and leveling are fixed algorithms rather than AI systems, and the same inputs always give the same result. This is how Flow Relay is designed and how it assesses its own features against Annex III of the AI Act; your use of it is yours to assess.

This page describes how the product behaves. It is not legal advice.