# Security and Access Control Buzzy security is layered. A secure app usually combines application privacy, user roles, row-level access, field-level access, Private Data controls, API/MCP governance, and audit logging. This page is the canonical guide for app builders who need to decide who can see or change data in a Buzzy app. {% hint style="info" %} Security-sensitive data should be protected by server-side Buzzy access controls. Display rules and hidden UI components are useful for user experience, but they are not security boundaries. {% endhint %} ## Security Layers | Layer | What it controls | Where to configure it | | ------------ | ---------------------------------------------------------------------- | --------------------------------------- | | App privacy | Whether the app is private, unlisted, or public | Workspace > Settings | | App roles | Who can administer, author, or participate in the app | Workspace > People | | Row access | Which rows a user can fetch from the server | Workspace > Data > datatable settings | | Field access | Which fields a row-visible user can view or edit | Workspace > Data > Data Model or Fields | | Private Data | Redaction, reveal, encryption, and audit behavior for sensitive fields | Workspace > Data > Data Model or Fields | | API and MCP | What authenticated external callers can receive | REST API and MCP integrations | | Audit trail | Evidence of Private Data reveal attempts | Workspace > Data > row Metadata | ## Server-Side Enforcement Buzzy enforces row, field, and Private Data rules on the server before data is returned to the browser, REST API, MCP tools, exports, or AI prompt contexts. Use this rule of thumb: * Use row and field permissions when the user should not receive the data. * Use display rules when the user may receive the data, but the UI should hide or simplify it. * Use Private Data when the field contains personal, sensitive, regulated, or confidential information that needs masking, hiding, reveal controls, encryption, or audit evidence. Do not rely on client-side hiding to protect confidential data. If a value should not be available to a user, configure row access, field access, or Private Data. ## Deployment Context Private Data, row access, and field access are application-layer controls. Compliance-sensitive apps also need the right deployment boundary for database, file storage, backups, logging, identity, and network controls. Buzzy supports: * **Single-tenant Deployments** with your own Buzzy deployment URL, database cluster, storage, and service endpoints in an available region. See [Create and manage Deployments](/working-with-buzzy/buzzy-deployment-and-app-stores/create-and-manage-deployments.md). * **Enterprise deployments** where Buzzy can run on your own infrastructure, including your own cloud environment or on-premise infrastructure. See [Introduction to deployment](/advanced-deployment-settings/installation/deployment/introduction-to-deployment.md). Use the [Buzzy pricing page](https://www.buzzy.buzz/pricing#deployment) to review available deployment plans. Deployment choice should be considered alongside Private Data classification, audit retention, API/MCP access, backup policy, and organizational compliance requirements. ## Application-Level Security Application privacy is configured in Workspace > Settings. * **Private**: Only invited users can access the app. * **Unlisted**: Anyone with the link can access the app. * **Public**: The app can be searched and accessed by anyone. For private apps, some screens can still be public, such as landing, login, registration, or password reset screens. Keep data screens and actions behind authentication when they expose protected information. Application roles are configured in Workspace > People. * **Admin**: Full app access, including management and deletion. * **Author**: Can build and manage most of the app, but cannot delete it. * **Audience**: Runtime app access only. Authentication can use Buzzy email/password, passwordless login, or configured external authentication providers. ## Row-Level Access Datatable settings control who can fetch rows from a table. Common "Who can view" options include: * **Creators only**: Users see rows they created. * **Creators & Viewers only**: Creators and users in the row's Viewers field can see the row. * **Admins, Authors & Creators only**: Admins and Authors see all rows; creators see their own rows. * **Admins, Authors, Creators & Viewers only**: Admins and Authors see all rows; creators and viewers see assigned rows. * **All participants**: Authenticated app participants can see rows. * **Anyone**: Anonymous users can see rows. * **Parent Row only**: Child rows inherit access from the parent row. Viewers and Team Viewers fields are the usual row-level tools for multi-user and multi-tenant apps. * **Viewers** grants access to specific users. * **Team Viewers** grants access to users in selected teams or organizations. * **Parent Row only** is useful for sub-tables where child data should follow parent row access. ## Field-Level Access Field access controls apply after the user is allowed to see the row. Use **Field view** to control who can see a field value. Use **Field edit** to control who can change a field value. Field access options include creator-based, viewer-based, Admin/Author-based, participant-based, and anonymous access policies. Viewer-based options can require selecting teams or organizations. Field edit cannot be broader than field view. For example, if Field view is "Admins, Authors & Creators only", Field edit cannot be "Anyone". Choose the same policy or a more restrictive edit policy. Use **Workspace > Data > Fields** to review field type, Field view, Field edit, Private Data classification, and purpose in one table for the selected datatable. The Fields tab is the fastest way to audit whether the data model matches the intended security design. ### Field Access Options | Option | What it means | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | **Creators only** | Only the row creator can access the field after row access is granted. | | **Creators & Viewers only** | The row creator and users included through row viewer policies can access the field. | | **Admins, Authors & Creators only** | Workspace Admins, Authors, and the row creator can access the field. | | **Admins, Authors, Creators & Viewers only** | Workspace Admins, Authors, the row creator, and selected viewer groups can access the field. | | **All participants** | Any authenticated app participant who can see the row can access the field. | | **Anyone** | Any caller who can see the row can access the field, including anonymous users when the row policy allows it. | | **Parent Row only** | For child/sub-table contexts, field access follows the parent row. | When an option includes **Viewers**, the field editor can require **Viewer teams / organizations**. Select the teams or organizations that should be allowed through that field policy, such as Legal Reviewers, Compliance Reviewers, HR Case Managers, or a customer organization. The selected team or organization does not bypass row access. The user must still be able to see the row first. Use field access for data such as: * internal notes visible only to staff * approval or review status editable only by owners * operational fields that should not be changed by customers * Private Data fields that only some row viewers should see ### Combining Field Security with Viewer Policies Viewer-related row policies and field-level policies are designed to work together. Use row **Viewers** and **Team Viewers** to decide who can open the record. Then use **Field view** and **Field edit** to decide which parts of that record each permitted group can see or change. This pattern supports secure review workflows such as: * Legal Reviewers can open assigned cases and see legal notes. * Compliance Reviewers can open assigned cases and see compliance findings. * Submitters can see their own request status but not internal review notes. * Managers can see decision fields without seeing every sensitive attachment. The usual build pattern is: 1. Create teams or organizations for the real-world review groups. 2. Add Viewers or Team Viewers fields to the datatable. 3. Configure workflow actions to assign rows to the right viewer groups. 4. Configure Field view and Field edit for each protected field. 5. Mark sensitive fields as Basic or Sensitive Private Data when masking, reveal, encryption, or audit evidence is needed. See [Secure and Compliant Workflow App](/the-ultimate-guide-for-vibe-coding-an-application-with-ai/building-examples/secure-compliance-workflow.md) for a full example. ## Private Data Private Data is used for fields containing personal, sensitive, regulated, or confidential information. Private Data is configured at field level in Workspace > Data > Data Model or Workspace > Data > Fields. | Classification | Default output behavior | Typical use | | -------------------------- | ------------------------------------------------------------ | ----------------------------------------------------------------------- | | **Not Private Data** | Returned normally, subject to row and field access | Public or operational data | | **Basic Private Data** | Masked or redacted by the server before output | names, email addresses, phone numbers, customer identifiers | | **Sensitive Private Data** | Hidden by default; reveal requires permission and is audited | health data, financial data, government identifiers, confidential notes | Private Data is enforced before values are returned to: * runtime screens * workspace data views * REST API responses * MCP tools * exports and generated previews * AI prompt/context builders ### Reveal and Audit Sensitive Private Data is hidden by default. Users with the required row and field access can reveal a specific field value. Reveal attempts are written to the Private Data audit trail. Audit entries record metadata such as: * user * row * field * classification * purpose * outcome * time The revealed value is not stored in the audit entry. In Workspace > Data, open a row and expand Metadata to query the row's Private Data audit trail. The audit trail is fetched by server method, not by client publication. Admins can use the row audit trail to review reveal activity for a specific record. This is useful for access reviews, incident response, and compliance evidence because the trail records access metadata without storing the revealed value. Audit retention is configured at deployment level with `privateData.auditLogRetentionDays` or `PRIVATE_DATA_AUDIT_LOG_RETENTION_DAYS`. See [Buzzy Settings](/advanced-deployment-settings/installation/buzzy-settings.md#private-data-audit-retention). ### Encryption at Rest Sensitive Private Data is encrypted at rest. Fields can also be configured for encryption where supported. Encrypted fields are not suitable for normal search, sort, or vector search because the server cannot safely index the raw value in the usual way. Design apps so searchable or sortable values are non-private derived values, status fields, dates, or other safe metadata. ### Files and Images Private Data can also apply to file and image fields. For denied users, Buzzy hides file metadata and signed URLs so images or files are not exposed through previews, REST API, MCP, or generated contexts. 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 controls. ### Repair When you change Private Data classification or encryption settings after data already exists, use the datatable repair function to align stored data with the current field definitions. Repair can update encrypted field storage and remove unsafe sort/search metadata for Private Data fields. ## API, MCP, and External Access REST API and MCP callers authenticate as a Buzzy user. Their responses follow the same row, field, and Private Data rules as the app runtime. * If the caller can view a Private Data value, the API or MCP response can include it where the endpoint is designed to return accessible values. * If the caller cannot view it, Basic Private Data is masked or redacted and Sensitive Private Data is hidden. * Attachment URLs are only returned when the caller has the required access. This is important for compliance-oriented apps: external integrations should receive only what the authenticated caller is allowed to receive. ## Compliance-Oriented Patterns ### Healthcare or Clinical Notes * Mark patient identifiers as Basic Private Data. * Mark clinical notes and health details as Sensitive Private Data. * Restrict Field view to the care team or authorized staff. * Require purpose text for sensitive reveals. * Review the audit trail for access evidence. ### Customer Support or CRM * Mark customer contact details as Basic Private Data. * Keep operational status and assigned team fields non-private so they can be searched and sorted. * Use Team Viewers to restrict rows by account, region, or support queue. ### Employee Records * Mark personal contact details as Basic Private Data. * Mark salary, performance, and medical leave details as Sensitive Private Data. * Use Field edit to restrict updates to HR or managers. ### Multi-Tenant SaaS * Use Organizations and Team Viewers to separate customer data. * Use sub-tables with Parent Row only when child data belongs to a tenant parent row. * Use Private Data for tenant-specific personal or confidential fields. ## Best Practices 1. Start restrictive, then open access deliberately. 2. Treat display rules as UX, not security. 3. Use row access for tenancy and ownership. 4. Use field access for least privilege within a visible row. 5. Use Private Data for personal, sensitive, regulated, or confidential fields. 6. Keep searchable and sortable values separate from encrypted Private Data. 7. Test with at least two users: one who should have access and one who should not. 8. Review audit logs for Sensitive Private Data reveal activity. 9. Document which fields are Private Data and why. 10. Re-run repair after changing Private Data or encryption settings on existing tables. ## Troubleshooting ### Users cannot see rows they should see * Check the datatable "Who can view" setting. * Confirm Viewers or Team Viewers values on the row. * Confirm team or organization membership. * If using sub-tables, confirm the user can access the parent row. ### Users can see rows they should not see * Tighten the datatable "Who can view" setting. * Check whether "Anyone" or "All participants" is too broad. * Review Viewers and Team Viewers fields. * Confirm public screens are not exposing protected data. ### Users see hidden or redacted field values * Check the field's Private Data classification. * Check Field view access. * For Sensitive Private Data, use the reveal control if the user has permission. * Run datatable repair if field settings changed after data was created. ### Private Data is not searchable or sortable This is expected for encrypted Private Data. Use non-private metadata fields, status fields, dates, or safe derived values for filtering, sorting, and reporting. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.buzzy.buzz/the-building-blocks/datatables-fields-and-data/security-and-access-control.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.