Data and privacy | Documentation

This article explains what data Performance Blocks holds about your organization and the people in it, where that data is stored, how long it is kept, what rights individuals and administrators have over it, and how third parties (sub-processors) fit in.

It is intended for org admins, legal/privacy counsel, and IT/security teams reviewing the platform. It applies to both Team and Agentic plans except where a feature is specifically called out.

What data is stored

Performance Blocks stores three broad categories of customer data: identity and directory data, performance content, and operational metadata.

Identity and directory data

Created when a user is invited or signs up.

Field	Source	Notes
Email	Invite or signup	Used for sign-in, notifications, and recovery.
Display name	Invite, signup, SSO claim, or HRIS sync	Shown on profile, observations, conversations.
Avatar / photo	User upload or HRIS sync	Stored in encrypted object storage; served only to authenticated users.
Job title	Optional, set by user, SSO, or HRIS	Shown on profile.
Department	Optional	Used for org chart and filters.
Manager / reports	Set by admin or HRIS	Drives the org chart and visibility rules.
Roles	Set by admin or SSO claim	`employee`, `manager`, `org_admin`. Multi-valued.
Locale	User preference	Drives UI language and date format.

Sign-in metadata (last sign-in, last seen) is recorded for the directory view.

Performance content

The substance of the product. Created by users as they work.

Observations: short notes a user records about themselves, a peer, or a direct report.
Summaries: longer-form artifacts (drafts, finalized cycle summaries, AI-assisted summaries reviewed by a human).
Conversations: 1:1 agendas, talking points, and the structured back-and-forth between participants.
Objectives: goals set against employees, teams, or the organization, with progress, owners, and check-ins.
Feedback: peer or upward feedback responses, anonymous or attributed depending on the request type.
Attachments: files attached to any of the above (PDFs, images, slide decks). Stored in encrypted object storage.
Knowledge base entries (Agentic): documents and snippets the organization uploads to ground Henry's responses.
Henry conversations (Agentic): chat history between users and the Henry agent. Scoped to the user.

Each record is owned by an organization and has explicit visibility rules — see the relevant feature article for details.

Operational metadata

Audit log entries: actor, action, target, timestamp, IP, user agent. Immutable. See Audit logs.
Sign-in events: success and failure, used for rate limiting and the directory's "last seen" view.
Notification delivery records: which user got which notification, when, on which channel.
Integration sync state (Agentic): cursors and timestamps used to resume HRIS or chat-tool syncs.
Billing data: subscription tier, seat counts, payment status. Card numbers are not stored on Performance Blocks — they live with the payment processor (see Sub-processors).

Where data is stored

Performance Blocks runs as a cloud service. There is no on-premises option.

The primary infrastructure providers are:

Cloudflare — application runtime, edge network, key-value storage for session and cache, object storage for attachments.
Neon — managed PostgreSQL for the relational database.

Customer business data is held in those services. The application has no second copy of customer data outside this stack other than ephemeral logs.

Region availability

For specific region availability and data-residency commitments (for example, an EU-only deployment or a request for a single regional provider), contact your account team before purchasing. Region commitments are made contractually rather than via a self-serve setting.

Backups

Database backups are taken automatically by the managed database provider on a continuous basis. Backups are encrypted at rest and retained for the standard window of the provider. Backups are used for operational recovery only; they are not exported or shared with anyone outside the operations team.

If a customer requests deletion under Right to delete, the production records are deleted immediately and the data is purged from backups as the backup retention rolls over. This window is typically a few weeks; the team can confirm the current retention period on request.

Retention

Default retention

Data	Default retention
Identity and directory	For the lifetime of the user record. Deactivated users are retained for compliance.
Observations, summaries	For the lifetime of the organization unless deleted by the author or by an admin.
Conversations	For the lifetime of the organization. Either participant can delete their own messages.
Objectives	For the lifetime of the organization unless deleted.
Attachments	Same lifetime as the parent record. When the record is deleted, attachments are deleted too.
Audit log	Retained for the lifetime of the organization. Cannot be edited or shortened from the UI.
Sign-in events	12 months rolling.
Notification delivery records	90 days rolling.
Henry chat history (Agentic)	Retained per user; user can delete sessions. Org admin can delete on a member's behalf.
Knowledge base (Agentic)	Retained until the admin deletes the document.

Adjustable retention

Some retention windows are configurable by an org admin under Settings -> Privacy:

Auto-delete observations older than X months (off by default).
Auto-delete chat sessions older than X days (off by default).
Auto-delete read notifications older than X days.

Setting an auto-delete window applies going forward. It does not retroactively shorten history that exceeds the previous default unless you explicitly run the back-fill option presented at save time.

When the contract ends

If the contract is terminated or not renewed, customer data is retained for a 30-day grace period during which an admin can request a final export. After 30 days, all customer data is deleted from production systems and purged from backups as those backups age out.

Legal hold

If you need to preserve all data for a specific user beyond the normal retention rules (for example, in support of a legal matter), open a request with your account team. A legal hold suspends the auto-delete rules for the named user until the hold is released. The hold itself is recorded in the audit log so the chain of custody is auditable later.

A legal hold does not prevent the user from continuing to use the product; it only prevents data from being deleted by automated rules or by the user themselves.

Right to access and export

Self-serve export — individual user

Any user can download a copy of the data Performance Blocks holds about them.

Open Account settings -> Privacy -> Export my data.
Click Request export. The export is queued.
When ready, you receive an email with a one-time download link. The export is a zip containing JSON files for each entity type (observations, summaries, conversations, objectives, profile) and an attachments/ folder.

The export contains data the user authored, data shared with them, and the directory record about them. It does not include other users' private observations or content the user has not been granted access to.

Self-serve export — organization

An org admin can export the entire organization's data.

Open Settings -> Privacy -> Export organization data.
Click Request export. The export runs in the background and can take time for large organizations.
When ready, the admin receives a notification with a one-time download link. The export is a zip containing JSON files per entity type, plus the attachments/ folder.

The export captures everything that lives in the relational database for the organization plus the attachments object store. It does not include backups or audit logs from sub-processor systems.

If a member of your organization makes a formal subject access request, the org admin can fulfill it via the per-user export above. If you need a notarized export or a specific format that the self-serve flow does not produce, contact your account team.

Right to delete

Deactivation vs. deletion

Two distinct operations exist for removing a user. Choose carefully.

Operation	Effect	Use when
Deactivate	User can no longer sign in. Their data and references stay in place. Authored content remains visible.	Routine offboarding; you want history preserved.
Delete	User record is removed. Authored content is anonymized: the author becomes "Former member."	The user requests deletion under privacy law, or you have a legal obligation to remove identity.

Deactivation is the default for offboarding. It is reversible — an admin can reactivate the account, the user signs back in, and history continues unbroken.

Deletion is permanent. Records that referenced the user (observations they wrote about others, conversations they participated in) keep their content but the author attribution becomes "Former member." This preserves the integrity of the historical record (a peer review with a 1-star rating cannot be retroactively altered to look like it never happened) while removing the personal identifier.

What happens to specific record types when a user is deleted

Authored observations: kept; author becomes "Former member."
Observations about the user: kept; the subject reference is removed, replaced with "Former member."
Conversations: kept; participant name shown as "Former member" on past messages. The other participant retains the thread.
Objectives owned by the user: ownership is transferred to the user's last known manager, or to "Unassigned" if none.
Audit log entries: kept with the original user id. Audit entries are immutable; this is a deliberate compliance choice.
Email: removed from the user record; can be reused by a future invite.

How to delete a user

Go to Settings -> Members -> [user] -> Delete account.
Read the confirmation. You will be asked to type the user's email to confirm.
Confirm. The deletion is queued and runs within minutes.

Deleting your own account

A user without admin role cannot delete themselves directly because the operation has organizational consequences (objective ownership, audit references). Open Account settings -> Privacy -> Request account deletion. The request is sent to your org admin to fulfill.

Use of data for AI

Performance Blocks uses AI in several places: summary suggestions, observation cleanup, the Henry agent (Agentic), and intent classification for Henry routing. The platform's policy on customer data and AI is straightforward.

Performance Blocks does not use customer content to train base AI models. The relationship with the AI provider is configured to disallow training on customer data.
AI inference happens at request time. The relevant prompt and context are sent to the model provider, the response is returned, and the provider does not retain the prompt beyond standard short operational logging (typically up to 30 days for abuse monitoring; see the provider's own published policy).
The Henry agent and the knowledge base are scoped to the requesting user's organization. Henry cannot read another organization's documents, observations, or summaries. The vector store is partitioned by organization id and queries are filtered server-side.
AI-generated content is presented to a human for review before it becomes part of the record. Suggested summaries are drafts; the user (typically the manager) edits and saves them. AI does not autonomously publish performance content.
Customers on the Agentic plan can disable AI features for their organization at Settings -> AI -> Disable AI assistance. With AI disabled, Henry, AI summaries, and intent suggestions are turned off.

If your organization has a stricter requirement (for example, a no-third-party-AI policy), discuss it with your account team during evaluation. There are deployment options that route AI calls through a different provider stack.

Anonymization for product analytics

Aggregate usage statistics (which features are used, how often, by what role) are computed without joining back to identifiable users. The org-level dashboards in Settings -> Insights show your own organization's data only, identified by display name; cross-organization analytics used by the product team are anonymized at the source so individual users are not visible to that team.

Sub-processors

A sub-processor is a third-party service that Performance Blocks uses to deliver the product and that may process customer data on our behalf. The current categories are:

Cloud infrastructure: hosting the application, database, key-value, and object storage.
AI model provider: powers Henry, summary suggestions, and intent classification (Agentic).
Email delivery: transactional email (sign-in, notifications, exports).
Payment processor: subscription billing and card data.
Error monitoring: aggregates anonymized error events for the operations team.

The current named list of providers is published at the company website (look for the privacy or trust page). Customers are notified before a new sub-processor is added.

If your organization needs an authoritative copy of the list to attach to a procurement record, request it from your account team — they can send the dated PDF.

Data Processing Agreements (DPAs)

Performance Blocks offers a standard Data Processing Agreement that addresses the GDPR and similar regulations. It is available on request through your account team. The DPA covers:

Roles of the parties (Performance Blocks as data processor, customer as data controller).
Categories of data and data subjects.
Cross-border transfer mechanisms.
Sub-processor management and notification.
Breach notification timelines.
Audit rights and certifications relied upon.

To request the DPA, contact your account manager. The standard DPA is offered as-is for most customers; mutually negotiated DPAs are available at the enterprise tier.

Customer-controlled deletion

In addition to the per-user delete and the contract-end deletion described above, an org admin can delete specific record types in bulk at any time:

Bulk-delete observations older than a chosen date or matching a tag, from Settings -> Privacy -> Bulk delete.
Bulk-delete chat sessions older than a chosen date, from Settings -> AI -> Henry sessions.
Bulk-delete attachments orphaned from their parent records (rare, surfaces only after a partial delete) from Settings -> Privacy -> Storage.

Bulk deletes are recorded in the audit log with the count of affected records. They run asynchronously; the admin receives a notification when the job completes.

These tools exist so that an organization can satisfy a retention policy or a regulator's request without engaging support. If you need a deletion shape that is not covered (for example, "delete all observations referencing a specific term"), contact your account team — they can run a one-off operation under the same audit-logged process.

Reporting a privacy concern

If you believe Performance Blocks is processing data in a way that violates your organization's privacy policy or applicable law:

Open a ticket with your account team describing the concern. Include the affected feature, the data type, and your reasoning.
For incidents you believe involve a data breach, follow the security report channel described in Security overview — that path is monitored continuously.

The privacy team responds within five business days for non-incident concerns and immediately for suspected breaches.

Data minimization

Where the platform can avoid storing data, it does. A few examples of how this shows up:

The application collects only the user attributes it needs to operate the directory, the org chart, and notifications. It does not ask for date of birth, home address, or other personal data unrelated to performance management.
Drafts that the user starts but does not save are not persisted past the editing session.
Search queries entered by a user (for example into the directory search box) are not retained in a permanent search-history store.
For Henry conversations on the Agentic plan, the user can delete sessions individually or in bulk; deletion removes both the chat content and the associated vector embeddings.

If you identify a place where the platform appears to store more than is needed for the feature, raise it with your account team — data minimization is an ongoing commitment.

Telemetry and product analytics

Performance Blocks records limited usage telemetry to operate and improve the product. The categories are:

Server logs: HTTP request paths, response status, anonymized identifiers, and timing. Used for debugging and security monitoring. Retained on a short rolling window.
Error reports: when the application throws an unexpected error, a stack trace and minimal request context are captured. Personal content is scrubbed before submission.
Feature usage events: which features are used and how often (e.g. how many summaries are generated per week). Aggregated at the organization level and used to prioritize product investment.

Telemetry never includes the body of an observation, the text of a conversation, the contents of a knowledge base document, or any user-authored prose. It does include identifiers that allow the operations team to reproduce a bug and to scope an incident.

If your organization needs all telemetry disabled for compliance reasons, discuss with your account team — there is a reduced-telemetry option available at the enterprise tier.

Where to find published telemetry policies

The headline statements in this article are the customer-facing summary. For the full operational telemetry policy (categories, retention windows, who has access), the trust page on the company website maintains the authoritative version. Refer to it when answering questionnaire questions or when working with your data protection officer.

Cookies and tracking

Performance Blocks uses cookies for two purposes: the authenticated session and a small set of operational preferences (e.g. last-selected organization, sidebar collapsed state). The session cookie is HTTP-only, secure, and scoped to the application domain. None of the cookies are shared with third-party advertising networks.

The application does not embed third-party tracking pixels or social-media trackers. The only third-party scripts loaded are the ones strictly necessary to operate features the user has invoked (e.g. the rich-text editor's bundled fonts).

Children's data

Performance Blocks is built for workplace performance management. It is not directed at children and is not designed to be used by users under the age of 16. The terms of service prohibit creating accounts for children, and the platform does not knowingly collect data from anyone under that age. If you become aware of a children's account in your tenant, deactivate or delete it immediately and notify your account team.

International transfers

Customer data may be processed in regions different from where it was originally entered, depending on the deployment region of your tenant and on which sub-processor handles the request. International transfers are covered by the standard contractual clauses appended to the DPA, which the parties enter into when the DPA is signed.

If your jurisdiction has additional requirements (UK Addendum, Swiss Annex, etc.), they can be added to the DPA on request. EU customers who require an EU-only data path should request that explicitly during procurement; an EU-only deployment is available at the enterprise tier.

How to involve privacy in a procurement review

If your organization runs a privacy assessment as part of vendor onboarding, share this article and request the standard packet from your account team:

Standard DPA, ready for signature.
Current named sub-processor list with a date.
Description of cross-border transfer mechanisms relied upon.
Most recent third-party security audit summary (under NDA where relevant).
Standard responses to common privacy questionnaires.

Allow about a week of lead time for the packet to be assembled and shared.