Private Data
Private Data lets app builders mark fields that contain personal, sensitive, regulated, or confidential information. Buzzy then applies server-side output shaping so the value is masked, hidden, encrypted, or audited according to the field configuration.
Use Private Data when a field should be treated differently from normal operational data.
When to Use Private Data
Use Private Data for fields such as:
names, email addresses, phone numbers, and addresses
patient, employee, customer, or student identifiers
health, financial, government, legal, or employment information
confidential notes or internal assessments
private images or file attachments
Do not use Private Data for fields that must be searched, sorted, or reported in raw form. Keep safe operational metadata in separate non-private fields.
Deployment Considerations
Private Data controls how field values are shaped, encrypted, revealed, and audited by the Buzzy server. For compliance-sensitive apps, also consider where the Buzzy server and storage run.
Buzzy supports single-tenant Deployments with your own deployment URL, database cluster, storage, and service endpoints in an available region. For organizations that need deeper infrastructure control, Enterprise deployment can run Buzzy on your own cloud or on-premise infrastructure.
See the Buzzy pricing page for current deployment plan options. Deployment model, region, contracts, backup policy, and operational controls are part of the overall compliance design.
Classifications
Not Private Data
The field is returned normally, subject to row and field access.
Basic Private Data
The server masks or redacts the value before normal output.
Sensitive Private Data
The value is hidden by default. Authorized users can reveal it, and reveal attempts are audited.
Sensitive Private Data is encrypted at rest. Basic Private Data is intended for values that should be minimized in normal output but may not require the stronger hidden-by-default reveal workflow.
Configure a Private Data Field
Open the app in Buzzy Workspace.
Go to Data.
Open Data Model or Fields.
Select the datatable.
Open the field.
Set Private Data to Basic Private Data or Sensitive Private Data.
Configure Field view to control who can see the field after they can see the row.
Configure Field edit to control who can change the field.
For Sensitive Private Data, add a purpose that explains why the data is collected or used.
Save the data model.
Field edit cannot be broader than Field view. For example, if Field view is "Admins, Authors & Creators only", Field edit cannot be "Anyone".
Review Fields from the Fields Tab
The Fields tab gives builders a table view of field security across the selected datatable. It is useful when you want to review Private Data configuration without opening every table card in the Data Model diagram.
Use the Fields tab to check:
which datatable a field belongs to
the field type, such as Text, Email, Image, Password, or Rich Text
who can view the field
who can edit the field
whether the field is Not Private Data, Basic Private Data, or Sensitive Private Data
whether Sensitive Private Data has a clear purpose
whether encryption at rest applies
Select the datatable first, then review the fields for that table. This keeps the view focused when an app has multiple datatables such as Patient Note, User, Login, Attachments, or Audit records.
The Fields tab is a review and navigation surface. Use Edit data model or the field edit modal when you need to change a field's type, access, Private Data classification, purpose, or validation.
Field View and Field Edit
Private Data still starts with row access. A user must be allowed to see the row before field-level access is considered.
After row access is granted:
Field view decides whether the field can be seen.
Field edit decides whether the field can be changed.
Viewer-based policies can require selecting teams or organizations.
Edit must be the same as view or more restrictive.
Use Field view to narrow access to sensitive fields inside otherwise visible rows. Use Field edit to prevent users from changing protected values.
Field Access Settings
The field editor shows a Field access section with separate View and Edit cards.
View answers: "Who can see this field after row access is granted?"
Edit answers: "Who can change this field after row access is granted?"
Common options include:
Creators only
Only the row creator can see or edit the field.
Personal draft fields, submitter-owned records
Creators & Viewers only
The row creator and users assigned through the row's Viewers policy can access the field.
Case records assigned to named reviewers
Admins, Authors & Creators only
Workspace builders and the row creator can access the field.
Internal build/admin fields plus submitter visibility
Admins, Authors, Creators & Viewers only
Workspace builders, the creator, and selected viewer groups can access the field.
Review workflows with Legal, Compliance, HR, or Finance teams
All participants
Any authenticated app participant who can see the row can access the field.
Low-risk operational fields in private apps
Anyone
Any caller who can see the row can access the field, including anonymous users if the row policy allows anonymous access.
Public fields only
Parent Row only
Access follows the parent row.
Sub-table fields that should inherit parent row access
Field Edit must be the same as View or more restrictive. For example, if View is Admins, Authors & Creators only, Edit cannot be Anyone because that would let users change a field they may not be allowed to see.
Viewer Teams and Organizations
Some View or Edit options include Viewers. When you choose a viewer-related option, Buzzy shows a Viewer teams / organizations selector.
Use that selector to choose the teams or organizations that should be allowed through that field policy. If you do not select a team or organization, the viewer-related policy does not have a concrete group to apply.
Example setup:
Create a team called Legal Reviewers.
Add legal staff to that team.
Set a sensitive Legal notes field to Admins, Authors, Creators & Viewers only.
Select Legal Reviewers in Viewer teams / organizations.
Set Field edit to the same policy or a stricter Legal-only policy.
The user must still be allowed to see the row. The team or organization selection does not bypass row access; it narrows field access after row access has been granted.
Edit Cannot Be Broader Than View
Buzzy warns builders when Field edit is broader than Field view.
This prevents confusing policies such as "Admins, Authors & Creators can view, but Anyone can edit." If someone cannot see a field, they should not be able to change it.
Workflow Scenarios
Submitter can create a case but cannot read internal notes
Row access includes the submitter; internal fields use Field view for reviewers/admins only
Legal team reviews legal-risk fields
Create a Legal Reviewers team, then use a viewer-related Field view policy and select that team
Compliance team handles evidence and findings
Create a Compliance Reviewers team, mark findings/evidence as Sensitive Private Data, and select the Compliance team for Field view/edit
Manager approves outcome without seeing raw sensitive details
Use non-private status/outcome fields for managers; keep raw notes as Sensitive Private Data for reviewers
External partner sees only their assigned records
Use organizations or Team Viewers for row access, then Field view to hide internal-only fields
Secure Workflow Patterns
Field-level controls are most powerful when combined with viewer-related row permissions.
For example, a builder can create teams or organizations such as:
Legal Reviewers
Compliance Reviewers
Clinical Reviewers
HR Case Managers
Finance Approvers
Then the app can use row Viewers or Team Viewers to decide which records each group can open, and Field view or Field edit to decide which fields that group can see or change after row access has been granted.
This supports workflows where:
submitters can create a row but cannot see internal review notes
Legal Reviewers can see and edit legal fields only
Compliance Reviewers can see and edit compliance fields only
managers can see final decision fields without seeing every sensitive detail
admins can inspect configuration and audit evidence
See Secure and Compliant Workflow App for a complete example.
Runtime Behavior
Private Data is shaped by the server before the app receives it.
Not Private Data renders normally.
Basic Private Data is masked or redacted.
Sensitive Private Data shows a hidden placeholder and reveal control when the user has permission.
Denied users do not receive raw sensitive values.
Revealed values can be hidden again in the UI.
The reveal action returns only the requested field value, not the full row.
Audit Trail
Sensitive Private Data reveal attempts are audited. The audit trail records metadata such as the user, row, field, classification, purpose, outcome, and time. It does not store the revealed value.
To view audit entries for a row:
Go to Workspace > Data.
Open a row.
Expand Metadata.
Select Load audit trail.
Audit entries are fetched by server method. They are not published to the client automatically.
Admins can use the audit trail during access reviews, incident investigations, and compliance evidence collection. The audit trail helps answer questions such as:
who attempted to reveal a sensitive value
which row and field were involved
whether the reveal succeeded or failed
what purpose was supplied
when the event happened
Audit retention is controlled at deployment level. See Buzzy Settings.
Encryption and Repair
Sensitive Private Data is encrypted at rest. If you change Private Data classification or encryption settings after rows already exist, use datatable repair to align stored values with the current field definitions.
Repair is useful when:
a field is changed from Not Private Data to Sensitive Private Data
a field is changed from Sensitive Private Data back to Not Private Data
encryption settings change
existing sort/search metadata needs to be removed for Private Data fields
Search, Sort, and AI Context
Encrypted Private Data should not be used directly for search, sort, or vector search.
Recommended pattern:
Store sensitive raw values in Private Data fields.
Store safe operational metadata in non-private fields for filters and reports.
Use dates, statuses, categories, owners, or non-sensitive derived values for sorting.
Buzzy also shapes Private Data before it is used in AI prompt contexts, generated previews, exports, REST API responses, and MCP tools.
Files and Images
Private Data can be applied to image and file fields.
When access is denied:
file names and metadata that could expose the file are hidden
signed URLs are not returned
image previews and links are replaced with a hidden placeholder
When access is allowed, Buzzy can return the normal attachment metadata and signed URLs required to display the file or image.
V1 gates attachment metadata and signed URLs. File bytes are not separately encrypted by this feature, so deployment storage configuration and signed URL expiry remain important.
Examples
Healthcare Notes
Patient name
Basic Private Data
Care team
Date of birth
Sensitive Private Data
Care team
Consultation note
Sensitive Private Data
Clinicians only
Created date
Not Private Data
Anyone who can view the row
Customer Records
Customer email
Basic Private Data
Account team
Customer phone
Basic Private Data
Account team
Account status
Not Private Data
Support users
Internal risk note
Sensitive Private Data
Managers only
Employee Records
Employee name
Basic Private Data
HR and manager
Salary
Sensitive Private Data
HR only
Department
Not Private Data
App participants
Performance note
Sensitive Private Data
HR and manager
Private Images and Files
Use Private Data for fields such as:
clinical images
identity documents
signed agreements
financial statements
confidential attachments
Test file/image fields with both allowed and denied users, and verify REST API and MCP responses do not expose denied attachment URLs.
Checklist
Last updated