Privacy policy

facets.team is operated by GasBuggy Media LLC.

There are two distinct relationships here, and which one applies to you changes your rights:

If you created an account — a team lead, facilitator, or leader — we handle your account data as the party that decides why and how it is used.

If you were invited to answer a survey, the organization that invited you decided to collect that feedback and chose who to include. We process it on their instructions. Requests about ratings you gave or received are usually best directed to whoever invited you, but you can contact us either way and we will help.

If you are that organization, the terms on which we process this data for you are set out in the data processing agreement. It is offered as standard, it needs no signature, and it is already in force from the moment an account is created.

Account data. Email address, and the organization and team names you enter. There is no password: you sign in by emailed link, with a Google account or a passkey if you choose to, or through your organization’s single sign-on where we have set it up with them. If you sign in with Google, Google sends us the email address, name and profile picture link on that Google account, which our authentication provider keeps with your account; we use only the address. When you accept the terms we record which version you accepted and when, and, if you accepted on this site, the IP address and browser details the acceptance came from, as evidence that it was given. That record is kept for as long as the account exists and is deleted with it.

Roster data. The names and email addresses you enter for the people you invite. An organization may instead have its own HR system or identity provider send us the roster for its engagement surveys, and that system remains the organization’s own processor, not ours: we keep from it each person’s name, work email address, manager, department, whether they are active and their end date, with the identifiers it uses for them, and send nothing back to it.

Survey responses. Ratings of colleagues, ratings of the team, nominations, self-assessments, and any free-text comments. The self-assessment includes questions about how being on the team is going for you, including whether your workload is sustainable and whether you expect to still be on the team in a year; these are reported only as part of a team aggregate.

Manager records. Where a customer uses the manager tools, a manager records information about people who report to them: name and optional email address, role and scope, what they are accountable for, strengths and development areas, goals and targets, quarterly progress and a performance band, notes from one-to-one meetings, follow-up actions, and written quarterly or annual assessments. This is a performance record, it is written by their employer, and it is the most sensitive category of personal data in the service. Where the manager turns it on, the person may also add topics for their one-to-ones through a personal link, without an account. Those topics are their own words, kept with the manager records and read by that manager with the person’s name on them; no model is given them. A topic the person withdraws before its one-to-one is held is deleted, and so are the topics no one-to-one has covered when the person moves to another manager. Where your manager notes the hours a week you work, that figure is held on their list of people and seen by them and by you, and sent to Microsoft Power BI if they connect it.

Invitations to a one-to-one. Where a manager keeps a regular one-to-one with someone on their list and has entered that person’s email address, the manager can send them one email inviting them to it. It carries the person’s name and address, the manager’s name and the meeting times, as a calendar invitation, and nothing the manager has written about them. Nothing further is sent because of it unless the manager sends another invitation, and we record when the last one was sent and to which address. Where the manager has let the person add topics for their one-to-ones, that email also carries the person’s own link for adding them, which the calendar invitation itself never carries. The link is sent in an email of its own when the manager turns it on or sends it again, to the same address, or, where there is no address, shown to the manager to pass on; we record when and to which address it was last sent, and keep only a one-way hash of the link.

Colleague input on an assessment. Where a manager requests it, the name and email address of each colleague asked, and their written answers — held with their name attached. Whether someone declined is recorded; no reason is collected, and a declined request’s draft text is discarded.

The People guide tools. Where they are enabled, a manager can ask Anthropic’s model for a conversation guide, a one-to-one agenda, follow-up actions from their notes, measurable wording for a goal or a draft assessment, for someone who reports to them; clause 5 says what each is sent. A manager can also ask it to adapt the guide for a growth or stay conversation to the person; clause 5 says what that is sent. The request leaves the same usage record, and where the manager saves the conversation with its adapted guide our audit log notes that a conversation was saved, without the usage record’s reference. Each guide, agenda, extraction, sharpening or draft the model is asked for leaves a usage record — who asked, which tool, the credits reserved and charged, the model, how it ended, the token counts and when — that holds none of the text and does not itself say who it was about. Where a guide, an agenda or a draft assessment is saved to a person’s record, our audit log notes that it was, as it notes any significant action, and that note carries the usage record’s reference; clause 6 says how long the usage record is kept.

Ideas on a board. Where a manager runs an idea board for their team, the name and email address of everyone they add to it, and what those people post: ideas, comments, votes and reactions. Whether a name is attached to an idea or a comment follows the board’s names setting, which is fixed before anybody posts; on the setting that hides names from everyone, who posted what is held where neither the manager nor an administrator can read it. Who voted and who reacted is never shown to anyone, the manager included — only the counts are. What people post is deleted within 90 days of the organization leaving the service, on the same clock as the answers in clause 6; what stays is the manager’s own record that the board happened: its title, the question it asked, and its counts.

What is drawn on a board’s canvas. A board may also be a whiteboard. The words on a sticky note are an idea like any other and are covered by the paragraph above; what is additionally held is where each thing was placed on the canvas — position, size, color and the order things are drawn in — together with which member drew a shape, a frame or a picture, which is held where neither the manager nor an administrator can read it. Where the manager has switched on live cursors, which is offered only on a board that shows every name, a pointer position and the name beside it are held for as long as somebody is on the page and are deleted nightly. All of it is deleted with the board’s words on the same 90-day clock; what stays is what the manager themselves drew.

Pictures uploaded to a board. Where the canvas is on, the manager or anyone on the board can upload an image. Every upload is re-encoded before it is stored, so no camera, location or editing metadata survives, and the longest edge is reduced; what the re-encode cannot remove is what is in the picture, which is why the board says before anybody uploads one that a picture can show a face or a name and that the choice is theirs. Images are held in a private store on the same Supabase project as everything else in this service, so this adds no new provider to clause 5 and no new sub-processor to the data processing agreement. They are readable only through a link to the board that holds them, and both the files and their records are deleted with the board’s words on the same 90-day clock.

Theme suggestions on a board. A manager can open a board with theme suggestions switched on. The board’s promise page and its invitation say so before anybody posts, and the setting is fixed from that moment, like the names setting. On such a board the manager can ask Anthropic’s model to suggest themes that group the ideas. For each suggestion, up to sixty of the ideas everyone on the board can see are sent to Anthropic, numbered: the title of each and the words under it, up to a fixed length, as they were written, so a name somebody typed into an idea goes with it. Who wrote an idea is never sent, on any names setting, and neither are comments, votes, reactions, the manager’s answers and private notes, dates, or the names and email addresses of the people on the board. On a board where each person sees only their own ideas — an inbox, or a board before its reveal — nothing is sent. What comes back is up to six themes, each a short title, a summary and the ideas it groups; they are shown to the manager alone, they move nothing on the board, a new suggestion replaces the last, and they are deleted with the board’s words on the same 90-day clock. Each request leaves a usage record — who asked, for which board, the model involved, whether it worked, how many tokens it took and when — that holds none of the text; clause 6 says how long it is kept.

Projects. Where a manager runs a project, the name and email address of everyone they add to it, and the work itself: task titles and descriptions, status, priority, dates, checklists, who a task is assigned to and who created it, comments, and a log of who moved what and when. A project shows names to everyone on it and there is no setting that changes that — the first screen says so before anybody writes anything, and it says that anyone wanting to raise something without their name on it should use an idea board instead. An owner or administrator of the organization can open a project to read it; that is recorded and shown to the manager who runs it. Nothing anyone writes on a project is part of any performance record; the hours a manager notes or plans for a person they track, and the weekly load built from them, are described in this notice. The manager may note the days each person on the project is away, and each person may note their own; the manager and that person see them, and nobody else on the project does. A day off is deleted once it has passed. If the manager turns on planning around each person’s weekly capacity, the dates a schedule then sets can reflect how many days a week each person works, and those dates are seen wherever the project’s dates are seen. Within 90 days of the organization leaving the service, the comments, the log of who moved what, and the member records — the names and addresses — are deleted, and the names come off the tasks with them; what stays is the tasks themselves, as the manager’s own record that the work happened. Where a manager plans work in Facets, the hours planned for you on a project or on work tracked elsewhere are held by the address your manager holds for you and seen by the manager who planned them, by you, and by a manager who tracks you in Facets, with the name of the project and who planned it; where a manager tracks you, they may also see the hours of open work you hold on other projects in the workspace, as hours per week. Where a manager connects Power BI, the figures they see leave Facets for their organization’s own Microsoft tenant under a key the manager holds; Microsoft is then your organization’s processor, not ours. If the manager asks the AI assist to draft a plan for the project, what they typed, the project’s title and description, and the titles of its sections and tasks, up to a fixed length, are sent to Anthropic to draft suggestions; if they ask it to break down a task, what is sent is what they typed, the project’s title, and that task’s title, description and section, with the titles of its subtasks and the steps on its checklist. If they ask it to draft an update about how the project is going, what is sent is what they typed, the project’s title, the status they picked, how many of its tasks were done since the last update and how many are overdue and blocked, the title and due date of the next task due, and the last update’s words, up to a fixed length. If they ask it to estimate how long tasks will take, what is sent is the project’s title and, for each task being estimated, its title, description and section, its parent task’s title and the titles of its subtasks and checklist steps, up to a fixed length, and never a task’s status, its dates or the time already estimated for it; the number of working days it suggests for each changes no task unless the manager applies a schedule. These go as they were written, whoever wrote them, so a name somebody typed into a title goes with it. The names and email addresses of the people on the project and of anyone its updates are sent to, who a task is assigned to or was created by, comments, the log of who moved what and any figure about one person are not sent, a draft never assigns anyone, and nothing drafted is added to the project unless the manager applies it or saves it as an update. Each request leaves a usage record — who asked, for which project and task, the credits and the model involved, whether it worked, how many tokens it took and when — that holds none of the text; clause 6 says how long it is kept. If a manager plans a new project with the AI assist, what they type — the goal, timeframe, team size and constraints, and their answers to its questions — is sent to Anthropic, with the questions themselves, to suggest questions and draft the project, up to a fixed length and as it was written, so a name typed into it goes with it. Nothing from any existing project is sent, nothing is created unless the manager creates it, and each round of questions and each draft leaves the same kind of usage record.

Links and pictures on a task. On a project, anyone who can change a task can attach a web address, with a title if they give one, or upload a picture of up to 2 MB, and everyone on the project and the manager can see both. Every picture is re-encoded before it is stored, so no camera, location or editing metadata survives, and the longest edge is reduced; what the re-encode cannot remove is what is in the picture, which is why the project says before anybody uploads one that a picture can show a face or a name and that the choice is theirs. A picture can be deleted by the person who uploaded it and by the manager, and deleting a project deletes every picture on it. Pictures are held in a private store on the same Supabase project as everything else in this service, so this adds no new provider to clause 5 and no new sub-processor to the data processing agreement. They are readable only through the project’s own pages; an owner or administrator who opens the project is told how many there are and is not shown them. Within 90 days of the organization leaving the service, the pictures teammates uploaded are deleted with their comments, file first; the manager’s own pictures and every link stay with the task, as its description does.

Updates about a project. A manager who runs a project can write updates about how it is going and send them by email to people outside the project whom they name, typing a name and an email address for each. Only that manager can see the addresses; everyone on the project sees the names. An update is the manager’s own words with counts and dates taken from the project, never a comment, the log of who moved what, or a figure about one person, and every update email carries a link that stops them. A manager can also switch on a read-only link, of which only a one-way hash is stored: anyone holding it reads the project’s updates, its milestones, and the title, status and due date of each open task, and nothing else. Within 90 days of the organization leaving the service, the names and addresses of the people updates are sent to are deleted with the project’s member records; the updates stay with the tasks, as the manager’s own record.

Slack and Teams. A manager can connect a Slack or Microsoft Teams channel of their own to a project or an idea board, and what is posted there is what everyone on the project or board can already see: an update, a daily list of tasks done, due and overdue with their owners, a board’s opening and closing, and ideas without names, and never a comment, a vote, an estimate or a figure about one person. A manager can also connect a channel of their own for reminders: how many check-ins are due, and that their group’s survey results are ready or a commitment’s check is due, with no figure and no name. An organization can connect a channel to a survey cycle, told that the survey is open or closing and nothing about who answered. What a channel receives is a copy in the organization’s own Slack or Teams, and the deletion within 90 days of the organization leaving the service, described in clause 6, does not reach it.

Direct messages. An organization can have a survey’s, a pulse’s or a Leadership 360’s invitations and reminders delivered as direct messages through its own Slack app or Microsoft Teams flow, each carrying the person’s own link and nothing about anyone else. Anyone the service cannot find, or cannot reach, is sent the email instead, and a person invited through Teams is sent the email as well. We look the person up by their work email address at the moment of sending and keep no Slack or Teams identity for them, only whether their invitation went by direct message or by email. What an administrator of that Slack or Teams can read of a direct message is governed by that service and the organization’s plan with it, and the owner of a Teams flow can read its run history, the messages included, for as long as Microsoft keeps it. A direct message is a copy in the organization’s own service, and the deletion described in clause 6 does not reach it. Every direct message that carries a person’s own link also carries a link that stops that organization’s direct messages to them, after which they are sent only the email. A direct message is sent at the time its email would be, or within minutes after; a large cycle takes longer, at the pace Slack or Teams allows, and anyone not reached within six hours is sent the email instead. No model writes a direct message, and no model reads anything sent or received through Slack or Teams. If a workspace removes our app from its Slack, or revokes its access, we learn of it at once and stop every direct message from that workspace from then on; its owners and admins are told by email, and invitations go by email until it is reconnected.

Calendar links. A signed-in user can make a personal calendar link, so that a calendar application they choose fetches their own dates and titles, including the names of the people they manage. Only a one-way hash of the link is stored, and getting a new link or turning it off ends the old one at once. What the calendar application has fetched is a copy in that application, and the deletion described in clause 6 does not reach it.

The iPhone app. Facets on an iPhone shows each person what the website shows them, and keeps what they do there with their account, in the same place. The app collects these, each to make it work, and never to track you or to show you advertising:

• Your email address, to sign you in, as the website does.
• The phone’s push token, if you allow notifications: an identifier for that one phone, which Apple’s push service needs to deliver a notification to it. It is kept with your account and deleted with it, and signing out of the app on that phone asks us to delete it.
• What you write, such as tasks, comments, ideas, answers and notes, kept with your account as it is when you write on the website.
• The pictures you attach to a task, chosen with the iPhone’s photo picker and kept with the task, as a picture uploaded on the website is.

That is all it collects. The app has no analytics and no crash reporter of its own, and sends us no usage statistics and no crash reports. On a board with GIFs switched on, it loads each GIF from GIPHY directly, as a browser does (clause 5), with no cookies and no referrer.

Kept on the phone. So that it can show your day before it reaches the network, the app keeps a copy of your Today, your projects and their tasks, and your calendar on the phone, where the iPhone protects it: it cannot be read while the phone is locked. For the home-screen widget and the iPhone’s search, the titles and due days of your running projects and open tasks are kept too. The app keeps nothing from People or Surveys on the phone: those screens are read when you open them, held only in the app’s memory, and sit behind the app’s Face ID lock, which is on unless you turn it off. While they are locked, and whenever the app is not the one in front, even with the lock off, those screens are covered, so the picture the iPhone keeps of the app for its app switcher never shows them. Signing out of the app deletes everything it kept on the phone. A notification you allow is shown and kept by the iPhone, as any app’s is, until you clear it; it says what kind of thing is waiting, and never a score, a survey answer or a comment.

Generated results. Computed scores and the written reports produced from them.

Operational records. An audit log of report accesses and significant actions, and standard server logs.

Requests from the public site. If you ask for the instrument specification or the research brief, the name, organization and email address you give, which of the two you asked for, and whether you left ticked the boxes asking for occasional notes from us or for a follow-up conversation. Notes are sent only after you open the emailed link, which confirms the address; every note carries an unsubscribe link that works in one click. A follow-up request is one conversation, initiated by us, and nothing more.

The only tracking on this site is Google’s measurement on its public pages, described in clause 5 and in the cookie table in clause 9. It never runs in the app or on any page where somebody answers a question.

To run the assessment and produce results; to send invitations, reminders, and notifications that results are ready; to authenticate account holders; to keep the service secure and diagnose faults; and to comply with legal obligations.

We also compute aggregated, de-identified statistics across many teams to improve the instrument, and intend in future to publish research from them. Nothing published this way will identify a person, team, or organization. A workspace owner can opt out of this use by emailing privacy@facets.team — clause 6 of the terms says what to include and what happens next.

We do not sell personal data, use ratings or comments to train machine-learning models, or use your data to advertise to you.

The access rules are enforced in the database, not by policy, and they differ between the two halves of the service.

Feedback surveys. Survey responses are confidential, not anonymous. Facets links each response to the person who gave it, so they can finish later and answer only once. No signed-in account can read another person’s ratings or comments as written, including the team lead’s. Leads see participation counts and released team reports. Individuals see their own note. The workspace’s owners and admins see the same counts and released team reports for every team, and where an owner turns the program report on, the owners and a practitioner the organization has engaged also read numbers pooled across at least three teams, with each team named only for who took part and what it decided, and only from surveys whose people were told before they answered. From a leadership 360 opened while the program report is on, they read its numbers only pooled with other leaders’ in cohorts of five, once a cohort is complete, never naming whose numbers are whose. A leadership 360's follow-up, which its subject may send once to the people who answered, is held as the review's answers are: the subject reads only combined answers, from at least three people, and nobody reads one person's.

The facilitator. A facilitator exists only where an owner or admin has named one for the team, by email address; a manager or an admin can be named, and an owner or admin can name themselves. A facilitator can read every member’s note, before and after a survey is released, for as long as they hold the role. They also see a view that names raters beside patterns in how they rated (for example, giving everyone the same score) and notes where one person rates another unusually. That view never shows ratings or comments as written. If the facilitator was named before anyone agreed to take part, it includes a paraphrase of each written comment, without the writer’s name. No other account can read an individual note or the facilitator view: managing a person, leading the team or administering the workspace does not give access, and being named facilitator does.

Minimum numbers. Results appear only when enough people have answered. The minimum depends on the survey and the kind of result; the table headed “The minimums” below gives each one.

Manager records. Readable by the manager who created them. An owner or admin of the manager’s workspace can open a record to read it; each open is logged with their name and the date, and the log is shown to the manager. Nobody can change a manager’s record but the manager, and when a manager leaves, their records are reassigned to another manager or archived, never deleted. Topics a person adds for their own one-to-ones, where their manager has turned that on, are not the manager’s record but the person’s own words: the manager reads them and cannot change them, and an owner’s or admin’s open does not show them. The ones no one-to-one has covered are deleted when the person moves to another manager. There is no minimum number of respondents here: a single colleague’s answer is used, and is presented to the manager as one person’s view rather than as a pattern. This half is not anonymous and does not claim to be.

Idea boards and projects. Neither is a manager record or part of the feedback surveys. Who on a board or a project can see whose name is set out with each in clause 2. An owner or admin of the manager’s workspace can open either to read it; each open is logged and shown to the manager.

Survey feedback and performance records. Facets does not add survey feedback to performance records. The one route is the leader’s own choice: after a Leadership 360, the person it is about can send a summary (the headline, plus the strengths and growth areas they pick) to someone they choose. One table records that share, and no access rule reads through it into the review, its raters or its responses. If the recipient attaches the summary to that person’s record, it is used when drafting their assessment, as clause 5 describes; attaching it is a manual act.

Small teams. On a three-person team each person has exactly two peers, so someone who knows their own rating can infer the other. The product withholds per-dimension peer scores at that size for this reason, and raters are told so before they answer. We do not promise anonymity that the arithmetic cannot deliver.

The minimums, and who can move them.

Counts are completed responses, not team size. An engagement cycle also hides a group whose answers could be worked out from the groups around it. These are limits built into the product, not settings your employer configured, and an owner, an admin and a manager are all equally unable to switch them off. So are we, with the one exception clause 7 sets out. The engagement floor is 5 unless your organization raises it; the organization can raise that figure but cannot lower it. At its written request we can set a lower floor on a single engagement cycle, below 5, before the cycle opens; that cycle’s own page then says so to everyone who can read its results, and everyone invited to that cycle sees the floor in force before answering. They are stated here, in the binding document, so that a change to them is a change to this policy.

When we would break confidentiality. There are two situations where we may look at, or disclose, something a rater wrote believing it would not be traced back: where there is a credible indication that someone is at risk of serious harm, and where a court order, subpoena or equivalent legal demand compels us. Nothing else qualifies — not a manager’s curiosity, not an internal investigation, not a customer asking, however senior. Where the law allows it we will tell the person affected before we act. If it does not, we will tell them afterwards.

Your employers do not see each other. If you are rated in more than one organization — a consultant, a contractor, someone who changed jobs — nothing you did in one is visible in the other, and no report joins them.

The following receive data from us — or, in GIPHY’s case and for a Google sign-in, from your own browser — and only as needed to run the service:

Supabase — database, authentication and file storage (United States).

Vercel — application hosting (United States).

Cloudflare — bot protection on the sign-in form and on the public contact and access forms. Receives the IP address and the browser and TLS characteristics of anyone who opens one of those forms, and nothing else: not what is typed into them. It never sees survey answers, and it is not used on any page where someone answers questions. Cloudflare runs the check on our instructions and, separately and on its own account, uses those signals to improve its bot detection.

Resend — transactional email delivery. Receives recipient addresses and message contents, including invitation links.

Anthropic — where enabled, generates the narrative sections of a report, follow-up questions to raters, and, when a manager asks, a conversation guide, a one-to-one agenda, follow-up actions from their notes, measurable wording for a goal or a draft assessment for someone who reports to them, and, when the manager who runs a project asks, a draft plan for the project or a breakdown of one of its tasks, or a draft of an update about how the project is going, or an estimate of how many working days its tasks will take, and, when a manager asks, the plan for a new project and the questions that lead to it, and, when the manager who runs an idea board opened with theme suggestions on asks, themes that group the board’s ideas, and, when a manager asks, the guide to a growth or stay conversation adapted to someone on their list, and, when a report is built, the options suggested beneath a cycle’s written summary, and, after a cycle closes, the options suggested for a manager’s group, and, when an owner or admin asks, the wording suggested for what an organization will try. For a team pack’s narrative it receives team-level aggregates only, and never anyone’s written answers. A team survey’s comments go to it in a separate step, only for a survey opened while model-written output was on: it receives them as they were written, without the name of the person who wrote them, of the person they are about or of the team, so a name somebody typed into a comment goes with it, and writes themes for the whole team and a paraphrase of each comment for the team’s facilitator; nothing it writes quotes them. For a leadership brief it receives aggregated evidence — never individual ratings — together with raters’ written comments with the writer’s identity removed, and never the confidential note to a facilitator. For a follow-up question it receives one rater’s own ratings and comments and nothing from anyone else. For a conversation guide or a one-to-one agenda it receives what that manager has recorded about the person: their name, their role title and the shape of their work, what they are accountable for, the strengths, development areas and support needs noted for them, the year’s goals other than dropped ones with the results recorded against them, the year’s check-ins and their open follow-up actions, together with what the manager chose or typed for that conversation or meeting. For a draft assessment it receives the same record, the manager’s answers to the assessment’s questions and what they ticked beside them, what the colleagues the manager asked wrote, with their names already removed, and how many of them replied, and the summary of feedback the person chose to share with their manager, if there is one. For follow-up actions it receives the person’s name and the notes the manager asks it to read; for measurable wording for a goal, the draft goal, the person’s role title, what they are accountable for and the shape of their work, and not their name. For the guide to a growth or stay conversation it receives the person’s role title, the name of the kind of work they are filed under and what they said in the last conversation of the same kind, and never a check-in, a band, a goal, a result, an assessment or anything a colleague wrote. Each tool sends these up to a fixed length, and never an email address — the data structure sent has no field for one — or anything from the feedback surveys but a summary the person chose to share; the text it does receive goes as it was written, whoever wrote it — the manager, a colleague the manager asked, or the person in a summary they shared — so a name somebody typed into a note goes with it. For a project plan or a task breakdown it receives what the manager typed and the project’s title; for a plan, also the project’s description and the titles of its sections and tasks, up to a fixed length; for a breakdown, that task’s title, description and section and the titles of its subtasks and checklist steps. For either it never receives the names or email addresses of the people on the project, the manager’s included, who a task is assigned to or was created by, a task’s status or dates, a comment, the log of who moved what, the workspace’s name, or anything from a manager record or a survey; the text it does receive goes as it was written, so a name somebody typed into a title goes with it. For the draft of an update about a project it receives what the manager typed, the project’s title, the status the manager picked, how many of its tasks were done since the last update and how many are overdue and blocked, the title and due date of the next task due, and the last update’s words, up to a fixed length, and never the names or email addresses of the people on the project, the manager’s included, or of anyone its updates are sent to, who a task is assigned to or was created by, a comment, the log of who moved what, a figure about one person, the workspace’s name, or anything from a manager record or a survey; the words it does receive go as they were written, so a name or a figure somebody typed into them goes with them. For an estimate of how long a project’s tasks will take it receives the project’s title and, for each task being estimated, its title, description and section, its parent task’s title and the titles of its subtasks and checklist steps, up to a fixed length, and never the names or email addresses of the people on the project, the manager’s included, who a task is assigned to or was created by, a task’s status, its dates or the time already estimated for it, a figure about one person, a comment, the log of who moved what, the workspace’s name, or anything from a manager record or a survey; the text it does receive goes as it was written, so a name somebody typed into a title goes with it. For a new project’s plan, and the questions it asks before drafting one, it receives what the manager typed — the goal and any timeframe, team size and constraints — and, from each earlier round, the questions it asked and the manager’s answers, up to a fixed length, and never anything from an existing project, the name or email address of anyone in the workspace, the manager’s included, the workspace’s name, or anything from a manager record or a survey; the text it does receive goes as it was written, so a name somebody typed into it goes with it. For theme suggestions on an idea board it receives up to sixty of the ideas everyone on the board can see, numbered, each with its title and the words under it up to a fixed length, and never who wrote an idea, on any names setting, a comment, a vote or a reaction, the manager’s answers or private notes, a date, the board’s title or question, or the names and email addresses of the people on the board; the ideas go as they were written, so a name somebody typed into one goes with it, and the themes it suggests are shown to that manager alone and move nothing on the board. When a manager asks Drafts for a message to send themselves — an email, a text or a chat message — or for a check of how a message’s tone reads, it receives what that manager typed for it (an idea, their own draft or what they want to say back), the message they are answering, if there is one, who the message is to, as a kind of recipient — one of the people who report to them, their team, their own manager, a peer, or someone outside the company, with any description the manager gives — and, for one of their people, that person’s first name, the tone and the other choices the manager made, the name they sign off with and anything else they ask for, and, for another version, the version before it, up to a fixed length. Only while the manager has that person’s notes switched on for the draft does it also receive, from the manager’s record of them, the agenda and notes of their latest one-to-one and what was written in their latest check-in, up to a fixed length. It is never given an email address from the workspace or anyone’s record, the workspace’s name, anything else from a manager record, or anything from a survey; the text it does receive goes as it was written, so a name or an email address somebody typed or pasted into it goes with it. A tone check reads a message without rewriting it, and is sent no more than a draft is. Facets sends no message: a draft leaves only when the manager sends it from their own email or messaging app, and Facets does not tell the person it is written to. Anthropic’s commercial terms state that it may not train models on customer content from the services. Nothing written in Facets trains a model.

GIPHY — GIFs on an idea board, and only on a board whose manager has switched them on. GIPHY, Inc. is not a provider acting on our instructions here, and we send it nothing: the rules it publishes for using its API require the search and the image load to happen in the browser. The browser of the person using the picker sends GIPHY the words they type, and the browser of anyone whose page shows a GIF — teammates on the board, and the manager on their own page — looks that GIF up and loads it from GIPHY directly. So GIPHY receives that browser’s IP address and the ordinary browser details that come with any request, such as the user agent, together with the words typed into the picker and the ids of the GIFs looked up. It never receives a name, an email address, an account or board identifier, or the address of the page: every request to GIPHY is sent with no referrer and no cookies. Searches and the GIFs shown are limited to GIPHY’s own G rating, which leaves out anything rated higher. GIPHY offers a way for an application to report back which GIFs were searched for and chosen, and we do not use it. A GIF on a board is a reference to an item in GIPHY’s library that we hold — never an upload, and never a stored copy of the image: when the words on an idea are deleted or expire, the reference goes with them. GIPHY handles what it receives under its own terms and privacy policy.

Stripe — payments, once billing begins. Stripe acts as merchant of record for the purchase: it takes the card details, which we never see or store, and it calculates, collects and remits any tax due. Because it decides on its own account what that requires, it is a separate controller of the payment rather than a provider acting on our instructions, and your receipt comes from it rather than from us.

Google — sign-in, for anyone who chooses to sign in with a Google account. Your browser goes to Google to sign in, and Google sends us the email address, name and profile picture link on that account, as clause 2 says. We send Google nothing about you or your workspace, and the button is not on any page where somebody answers a question. Google handles your sign-in under its own terms and privacy policy.

Google — measurement on the public pages of this site: how many people arrive, which pages they read, and where they came from. It receives the page address and the usual browser and network details, and it is not present on the app or on any page where somebody answers a question. We buy advertising on Google; we do not show advertising here, and we do not build audiences from visitors.

Where this runs. The database and the application are both in the United States — Supabase in AWS us-east-1, Vercel in its US regions. A dedicated instance can be created in another region, and the region is fixed when it is created. Email, payment processing, bot protection and the model provider are reached as services rather than hosted by us, and each keeps its own regions. Each of these providers uses sub-processors of its own; the list above is the set of companies we hand data to, and each of them publishes its own.

When this list changes. These are the only parties we share data with, and this page is the current list. If we add one, we will update this page and email every workspace owner at least thirty days before the new provider begins handling any data. Within those thirty days you may object on reasonable data-protection grounds by writing to privacy@facets.team. We will make a good-faith effort to offer you a way to keep using Facets without that provider; if we cannot, you may end the affected part of your subscription without penalty, and we will refund what you have paid for time you have not used. If a provider has to be replaced at short notice to keep the service secure or running, we will tell you as soon as we reasonably can rather than thirty days ahead.

We may one day be acquired, merged into another company, or sold with our assets. If that happens the data described here goes with the business, because a company cannot be bought without the thing it operates.

That is not the same event as selling your data. Section 10 says we have never sold anyone’s personal information and never will, and that stays true: a change of ownership is a different thing, and the state privacy laws that define the word “sale” treat it as a different thing too.

What we commit to is this. We will tell you. The version of this notice in force at the time keeps applying to everything already collected, and a successor that wants to use it differently has to say so in advance rather than change the rules behind you. That last part is not only our preference — a material change applied backwards is prohibited under the same laws.

Survey responses and results are kept while the account that owns them exists, so that a team can compare its results from one survey to the next.

Raw answers are deleted within 90 days of the team or organization leaving the service. This is the commitment already made to every participant on the consent screen before they answer, and it is repeated here so the two cannot drift apart.

The same deletion reaches the reports we keep. Comments that a report carried forward word for word, and notes written to a facilitator, are emptied from it, while its scores and counts stay. Survey links, invitations and the roster kept for the next engagement cycle are deleted, so a link somebody was sent to their own results stops working, and the email addresses of the people the kept reports still name — team members, raters, respondents, facilitators and managers — are removed. The names stay, because those reports print them.

A person marked inactive on an engagement survey’s roster, whether by hand or by the organization’s HR system or identity provider, is deleted from that roster 90 days later, and what such a system sent us about a person is deleted 90 days after it removes them.

Manager records are kept while the account that owns them exists, and are deleted with it. A manager can export any person’s record and any assessment at any time. Idea boards and projects follow the 90-day clock above; clause 2 sets out what of each is deleted on it and what is kept. Each usage record the project assist or theme suggestions leave for a request holds none of the text, and is deleted after 400 days, or within 90 days of the organization leaving the service if that comes first. The usage record each guide, agenda, extraction, sharpening or draft from the People guide tools leaves likewise holds none of the text and does not itself say who it was about, and is deleted after 400 days, or within 90 days of the organization leaving the service if that comes first. Each of these records, a theme suggestion’s included, also holds its request’s credits: a manager’s seat comes with one allowance of AI credits, over a rolling 30 days, that the project assist, theme suggestions and the People guide tools all draw on, and it is counted from these records.

Drafts, the manager tools’ message drafter, keeps no draft on the website: what a manager writes in it and the drafts that come back exist only on the page they have open, and are gone when they leave it. Each draft or tone check leaves a usage record of the same kind as the People guide tools’, which likewise holds none of the text and does not itself say who the message was to, holds its request’s credits from the same allowance, and is deleted after 400 days, or within 90 days of the organization leaving the service if that comes first. When a draft was written with a person’s one-to-one and check-in notes, our audit log notes that it was, identifying that person and the dates of the notes used and never their words, and that entry, like every audit-log entry, is kept with no end date. When a manager drafts or checks a message’s tone in the iPhone and iPad app, the finished draft or tone check is held on our servers, encrypted, for 24 hours so that the app can collect it, together with the choices it was asked for, which identify the person when it is to one of the manager’s people, and is deleted at the first daily clean-up after those 24 hours.

A request from the public site is kept so that the link keeps working and so we know what was sent to whom; unsubscribing keeps the address on file as unsubscribed so it is not written to again. If the emailed link is never opened, the request and the address are deleted once twelve months pass with nothing more happening to either. Ask at the address below to have it deleted outright.

Deletion requests are honored for teams, reviews, or whole accounts, including the underlying ratings.

Deleted data survives in infrastructure backups for up to seven days. Our database provider takes automatic daily backups on a rolling seven-day window, so a backup taken before a deletion holds those rows until it ages out — ninety-seven days end to end for a departing team, against the ninety-day promise for the answers themselves.

Audit-log entries do survive. An entry recording that something existed is not deleted when the thing itself is, because a log that could be erased by the same action it exists to record would not be a log. Those entries hold what happened and when, not the ratings or the comments. No entry holds an email address: where an address matters, an entry keeps only its domain and a keyed fingerprint that lets us find entries about an address we already know, and from which the address cannot be read back. No part of the service, and no key it holds, can edit or delete an entry, and entries are kept with no end date. Records of errors the service runs into, which we keep to diagnose faults, are deleted ninety days after the error last occurred.

An account nobody uses does not keep data forever. After twenty-four months with no activity we email the account holder at the address on the account, and if nothing happens we close the workspace and the ninety-day deletion above follows. This exists because the promise above starts running when a team leaves the service, and an account nobody ever closes never leaves — without this paragraph, answers given in one year would still be here in the next decade, which is not something anybody agreed to.

Depending on where you live you may have rights to access, correct, delete, or port your personal data, and to object to or restrict certain processing.

Access requests that reach ratings and comments. A right of access may reach ratings and comments about the person making the request. Those were given by colleagues who were told their individual answers would not be shown. A promise we made to a rater cannot switch off a right the law gives you, so the question is not whether we answer but how much we can answer while keeping it. The line is drawn below.

Your results, freely. The scores, themes and reports the product shows. You do not need a request for these: an owner or admin can export everything at workspace level at any time, and a manager can export any person’s record from that person’s own page.

The substance of what was written about you, in paraphrase. That is the only form written answers exist in for reporting. Nobody is shown them verbatim, and that includes you and includes your employer.

Individual ratings tied to the person who gave them: no. Who said what: never. Article 15(4) says a right to a copy must not adversely affect the rights and freedoms of others, and a rater’s answer is also the rater’s own personal data, given on an assurance we published before they answered. That is the balance the law asks us to strike and this is where we have struck it. The same law is clear that the balance cannot become a refusal to tell you anything, which is why the two tiers above are deliberately generous rather than grudging.

We will not ask your colleagues to consent to disclosure. It is the textbook mechanism and it is the wrong one here. Asking a rater whether you may see what they wrote tells them they have been identified as a rater and puts them under exactly the pressure the design exists to remove — and if they decline and we told you that somebody declined, that would be information about them too. So we do not ask, and no answer of ours should be read as implying that we did.

What no rule can fix. On a small team, content identifies the writer whatever we do with the wording — one person has the Tuesday one-to-ones. Where paraphrase would still point at somebody, you get a description of the theme rather than the text, and we will tell you that is what we have done rather than let you think you received everything.

Where the law requires more, the law wins. This is our default, not a rule we would defend against a regulator, a court, or a specific legal duty in your jurisdiction. Where one of those requires more, we disclose more, and we tell you we have.

This is a property of the product, not a decision we make about you. Your employer is the controller and answers your request; we hold the data on their instructions. What they cannot do is get past the same architecture you cannot. Individual peer ratings have no read access for any signed-in account, and the reporting floors cannot be lowered by your employer, by a manager, or by anyone with an account.

There is one exception. At the organization’s written request, we can lower the floor on a single engagement cycle, below 5, for example for a small pilot. It is per cycle, never a default, and the cycle’s own page says so in plain sight to everyone who can read the results, so it cannot be done quietly. Everyone invited to that cycle sees the floor in force before answering. It can only be set before the cycle opens: from then on the cycle’s floor is fixed, and the database refuses any change to it. If it was done on a cycle you answered, you were able to see that before you answered.

Correcting and deleting are different problems. An opinion cannot be made accurate by correcting it. If you think a rating or a comment about you is wrong, what can be corrected is the record — that the view was expressed, by whom in aggregate, and when — and you may have a statement of your own recorded alongside it. Erasing individual answers about you is a different matter again: they are part of an aggregate that other people’s results depend on, so removing them changes what your colleagues were told. Ask us and we will tell you which of these we can do in your case and why, rather than answering with a form.

Which of us to ask. If a manager recorded information about you, a colleague was asked for input about you, or you took part in a manager’s idea board or project, their employer decided to collect it and we hold it on their instructions — so that request is usually best made to them. Ask us either way and we will help, and we will tell you which of us can act on it.

No decisions are made about you by a machine. Every score in the product is arithmetic that a person could do by hand — no model decides a number, a threshold, or whether a result is shown to anyone. Where a model writes, it writes narrative from figures already computed, prepares for a manager to review a conversation guide, a one-to-one agenda, follow-up actions from their notes, measurable wording for a goal or a draft assessment, drafts a project plan, a task breakdown or an update about a project for a manager to review, drafts the plan for a new project from what a manager describes, estimates for a project’s manager how long its tasks might take, or suggests themes that group an idea board’s ideas for its manager to read, or adapts for a manager the guide to a growth or stay conversation from the person’s role, the kind of work they do and what they said last time. So there is no automated decision-making with legal or similarly significant effects within the meaning of Article 22.

Profiling is a broader word, and we do not claim to be outside it. The definition covers automated processing used to evaluate personal aspects of somebody, and the first example it gives is performance at work. Computing a score about how a person works, from ratings other people gave, is that. What Article 22 restricts is a decision taken solely on that basis with a legal or similarly significant effect, and there is none here — but saying “no profiling” would have been a word we had not earned.

What we cannot promise is what your employer does next. They may take a report into a promotion, a pay review or a performance conversation, and that decision is theirs and is made by people. If you want to know how it was used, they are the ones who can tell you — and the reporting floors in section 4 exist precisely because a number built from too few people should not be carrying that weight.

If we get it wrong. In the EU, the EEA, the UK and Switzerland you may complain to your national data protection authority, and you do not have to come to us first. In the US, see section 10 for the appeal we offer and for your state attorney general. We would rather you told us — but the right does not depend on that.

To exercise a right, contact us using the details in section 12.

Data is encrypted in transit and at rest by our infrastructure providers. Access links are random tokens of which only a one-way hash is stored, so an existing link cannot be looked up or read back by anyone, including us. Administrative access to production is limited to a small number of named operator accounts, controlled by an allowlist in our deployment configuration together with a roster we can revoke at any time, and each of those accounts must additionally pass a one-time code from an authenticator app before the operator console will open. Report accesses are logged.

The one exception is a shared open link: the single link that can be switched on for an idea board, a project or a leadership review so that a whole team can join by it. While it is switched on it may be stored as the link itself, not only as a hash, so that the person who switched it on can copy it again later. That copy is encrypted, as the next paragraph describes. The service shows it only to that person, and deletes it when it is switched off or replaced, when a review’s link reaches its limit, or when the board, project or review it belongs to closes. Personal links are never stored this way.

Beyond the encryption our infrastructure providers apply, the service itself encrypts the most sensitive free text before it is stored, with keys that are kept outside the database. That covers what a manager records about the people who report to them — notes, check-ins, results against goals, one-to-one notes and agendas, the topics a person adds for their own one-to-ones, follow-up actions, conversation guides and assessments, what colleagues wrote when asked, and handover notes — and the written answers people give in team surveys, 360 reviews and engagement surveys, with the comments and the notes to a facilitator that reports keep. Shared open links and the addresses of connected Slack and Teams channels are encrypted the same way. A value stored this way cannot be read from a copy of the database or of a backup without the keys. Names, email addresses, job titles, goals, ratings, idea boards and projects are not encrypted this way, only at rest as above. It does not protect against someone who takes over the running service, which holds the keys in order to show the text to the people allowed to read it, and the keys are ours: we do not offer keys held by you.

If something goes wrong. No system is perfectly secure. If personal data is breached in a way that presents a real risk of harm to the people it is about, we will tell the affected organization without undue delay and in any case within seventy-two hours of becoming aware — first with whatever we know at the time, which may be very little, and then in writing with the full account once we have it. We will not wait until the picture is complete to make the first call. Where the law requires us to notify individuals or a regulator directly, we will.

Every cookie below is listed by name. Three of them are needed for the site to work at all and are set whatever you choose; the rest are not, and are only set if you say so.

Nothing in the analytics or advertising column ever runs on a page where somebody answers a question. The measurement tag loads on the public pages of this site and nowhere else — not in the app, and not on any survey, rating or feedback link. Those pages carry a token in the address, and a measurement tag reports the address it was loaded on. Rather than stripping that out, we do not put the tag there.

How we ask. If you are in the EU, the EEA, the UK or Switzerland, nothing beyond the first five rows is set until you say yes, and declining is one click in the same place as accepting. Elsewhere the measurement cookies are set by default. On the tracking choices page you can stop sharing with Google for advertising, in this browser on this device, for 12 months. That button leaves analytics measurement on; a Global Privacy Control signal turns off both.

Global Privacy Control. If your browser sends a Global Privacy Control signal we treat it as a refusal of both analytics and advertising, on every page, automatically. It overrides an earlier acceptance, because a signal you turned on later is you changing your mind.

We do not use session recording, heat mapping, or any tool that replays what you did on a page.

California, Colorado, Connecticut, Texas, Virginia and a growing list of other states give their residents rights over personal information. Where those laws apply to us, the rights below are yours. Ask by writing to privacy@facets.team — you do not need an account, and an authorized agent may ask on your behalf.

We have never sold anyone’s personal information, and we never will. Not survey answers, not ratings, not email addresses, not anything. That is a promise about how we run this company, and it holds for as long as we run it — if the business itself is ever sold, section 5A says what happens and what you are told.

We do not share it either. Those laws use that word for using what you did on one site to decide what you are shown on another. We buy advertising on Google to bring people here, and we measure which of those ads worked — but we do not build audiences from visitors, we do not add anyone to a remarketing list, and no advertising is shown on this site. Every page we send to Google carries an instruction not to use it for personalized advertising, so this is enforced in the code rather than left to a setting.

The categories we hold are: identifiers (name, work email, the organization you belong to); professional or employment information (role, team, manager, start and end dates); the content you write in the product (ratings, comments, goals, notes); commercial information for customers who pay us (plan, invoices — card numbers go to Stripe and never reach us); and internet activity limited to what is described in the cookie table above. We ask for none of the categories those laws call sensitive — no government identifiers, no financial account numbers, no health data, no precise location, no biometrics — and if you put them in a comment box we would rather you did not.

Your rights are to know what we hold, to get a copy, to correct it, to have it deleted, to opt out of sharing, and to be treated no differently for asking. We will not degrade the service, change the price, or refuse to deal with you because you exercised any of them.

If we say no, you can appeal. Colorado, Connecticut and Virginia require it and we offer it to everyone: reply to our refusal and a different person will look at it again, and tell you the outcome and the reasoning within a reasonable time. If you are still unhappy you can complain to your state attorney general, and we will tell you how.

Note which of us to ask. For anything you did as a customer of ours, ask us. For survey answers, ratings and rosters, your employer decides — see section 1 — and we will pass your request to them and tell you we have done it.

The service is for workplace teams and is not directed at anyone under 18. Account holders confirm they are 18 or over when they accept the terms, and we do not knowingly collect data about anyone younger.

We cannot verify it, so we are telling you how it actually works. Rosters and survey invitations are uploaded by the employer, as names, work email addresses and reporting lines — none of which say anything about age. Sixteen- and seventeen-year-olds hold real jobs in retail, hospitality and food service, so “nobody under 18 is in here” is a fact only the employer is in a position to know. Clause 4 of the terms therefore makes it their obligation not to include anyone under 18, rather than leaving it as something we quietly assume.

If someone under 18 was included anyway, tell us at privacy@facets.team and we will delete what we hold about them and confirm that we have. You do not need an account to use that address.

facets.team is operated by GasBuggy Media LLC, gasbuggymedia.com.

For anything in this policy — access, correction, deletion, portability, or an objection — write to privacy@facets.team. You do not need an account to use that address, and you do not need to explain why you are asking.

If you were invited to answer a survey or asked for input about a colleague and would rather not go through whoever invited you, that address reaches us directly. We will tell you which of us can act on the request.

Formal legal notices go to legal@facets.team; general questions to support@facets.team.

Where to write to us. GasBuggy Media LLC, 1209 Mountain Road Pl NE, Ste N, Albuquerque, NM 87110-7825, United States.

EU and UK representative. No participant in the EU or the UK has used the service to date, so no representative has been appointed under Article 27 of the GDPR or its UK equivalent. Before we take one, we will appoint a representative and name them here. If you are about to run a cycle that includes people in either place, tell us first — that is the event that triggers this, and we would rather hear it from you than find out afterwards.

If we make material changes we will notify account holders by email and update the date at the top of this page.

Participants are not account holders, so two things stand in place of an email to them. The date at the top of this page always names the version you are reading. And if you answered a survey and want to see the version that was in force on the day you answered, ask at the address in section 12 and we will send you that version within thirty days.

A change does not reach backwards. Answers already given stay under the version of this notice that was in force when they were given. If we ever want a change to apply to data we already hold, we will ask rather than assume — which is the same rule we set ourselves for the research opt-out in the terms.