Security and Access Control
Implementing proper security and access control is crucial when building applications with Buzzy. This comprehensive guide explains Buzzy's security model from the application level down to individual fields, helping you create secure applications where users can only access the data they're authorized to see.
Application-Level Security
Application Privacy Settings
Accessible via the Buzzy Workspace -> Your App -> Settings
At the highest level, Buzzy applications have three privacy settings:
Private: Only accessible to invited users
Unlisted: Accessible to anyone with the link
Public: Can be searched and accessed by anyone
For private applications, you can make specific screens public (such as landing pages, login screens, and registration forms) while keeping the rest of the application secure.
Application Roles
Accessible via the Buzzy Workspace -> Your App -> People
Buzzy applications have three primary roles:
Admin: Full access rights, including the ability to delete the application
Author: Similar to Admin but cannot delete the application
Audience: Viewing access only, cannot access Buzzy via Workspace
Authentication Methods
Users can authenticate to Buzzy applications using:
Passwordless Authentication: Users receive a secure token via email
Email/Password Authentication: Traditional username and password login
Single Sign-On (SSO): Integration with external authentication providers (requires additional setup)
Organization and Team-Level Security
Accessible via the Buzzy Workspace -> Organizations
Organizations
Organizations in Buzzy represent companies or departments that use your application. They provide a way to group users and control access at a high level.
Organizations are treated as Audience members in the application
Each organization can have multiple teams and users
Organizations can be managed through the Buzzy Workspace or programmatically via the REST API
Teams
Teams provide group-based access control within organizations:
Teams are groups of users with similar access needs
Teams can be assigned specific access rights to datatables and records
Teams are useful for departmental or project-based access control
The default team "AllMembers" includes all users in an organization
Setting Up Organizations and Teams
Create organizations in the Buzzy Workspace
Create teams within each organization
Add users to appropriate teams
Use Teams fields in datatables to control access
Datatable-Level Security
Accessible via the Buzzy Workspace -> Your App -> Data -> Properties.
Datatables are the core data storage mechanism in Buzzy. Each datatable has security settings that control who can perform various operations.
Who Can View Settings
Accessible via the Buzzy Workspace -> Your App -> Data -> Properties -> Results
The "Who Can View" setting determines which users can see records in a datatable:
Creators Only: Only the users who created the records can see them
Creators and Viewers Only: Only the creators and explicitly designated viewers can see the records.
Admins, Authors & Creators Only: Record creators see only their own content, while Admins and Authors see all records
Admins, Authors, Creators & Viewers Only: Record creators and viewers see content they have been added to, while Admins and Authors see all records
All Participants: Anyone who has successfully logged into the app and has access to it
Anyone: Anonymous access, anyone can see the data
Parent Row Only: Inherits access from the parent record (for sub-tables)
See below for adding Viewers & Team Viewers to a row. Best practices is to use these security settings as when a user open their application it only fetches data from the server that they have access to, so the server secures the data.
Who Can Submit Settings
Accessible via the Buzzy Workspace -> Your App -> Data -> Properties -> Submit
The "Who Can Submit" setting controls who can add new records to a datatable:
Admins & Authors Only: Only specific users who have those roles can add records
All Participants: Any authenticated user with access to the app can add records
Anyone: Anonymous users can submit records (useful for public forms)
Who Can Delete Settings
Accessible via the Buzzy Workspace -> Your App -> Data -> Properties -> Results
The "Who Can Delete" setting determines who can remove records from a datatable:
Admins and Authors Only: Only application admins and authors can delete records
Creators Only: Only the users who created the records can delete them
App Participants: Any authenticated user with access to the app can delete records
As part of the general role based Who Can VIew, you can grant individuals, teams and organizations access to a specific row. For example, in a multi-tenant application, that may house multiple organizations data and then groups sub-table data under the parent rows, use the Viewers and Team Viewers fields to grant access to that specific row. So ACME Inc only see ACME Inc content, while another entity only sees their content.
Viewers Field
The Viewers field restricts which users can see specific records:
Users specified in the Viewers field can see the record
Admins and Authors of the application can see all records by default
The record creator can always see their own records
TeamViewers Field
The TeamViewers field combines team-based and user-based access control:
Allows specific teams to view records
Can be combined with the Viewers field for more complex access patterns
Field Interaction Controls
You can control who can interact with (edit) specific fields within a record:
Set field-specific permissions for editing
Hide fields based on user roles using display formulas
Control field visibility based on other field values
Hierarchical Security with Sub-tables
Sub-tables allow you to create parent-child relationships between datatables, which can be leveraged for sophisticated security implementation.
How Sub-table Security Works
Sub-tables can inherit security settings from their parent tables, using the Parent Row Only - it's only available if you have access to the parent. Warning, this means if you have heirarchical content - when accessing via the Buzzy Workspace you have to open the parent row and drill down, as they gives access the the child data, you will not be able to see the content in the child datatables, if this setting is on.
This creates a hierarchical security model where access to child records depends on access to parent records
The "Parent Row Only" setting simplifies access control for sub-tables
Setting Up Sub-table Security
Create a parent datatable with appropriate security settings
Create a child datatable as a sub-table of the parent
Set the "Who Can View" setting to "Parent Row Only" to inherit security from the parent
Sub-table Security Use Cases
Multi-tenant Applications: Organization → Teams → Team Members
Project Management: Projects → Tasks → Task Comments
E-commerce: Products → Orders → Order Items
Common Security Patterns
Personal Data Pattern
For applications where users should only see their own data:
Set "Who Can View" to "Creators Only" or "Admins, Authors & Creators Only"
Use the Viewers field to allow sharing with specific users when needed
Anonymous Feedback Form
For collecting feedback without requiring authentication:
Set "Who Can Add" to "Anyone"
Set "Who Can View" to "Admins & Authors Only"
Set "Who Can Delete" to "Admins & Authors Only"
SaaS Application Pattern
For multi-tenant SaaS applications:
Create an Organization datatable with "Who Can View" set to "Admins, Authors, Creators & Viewers"
Use sub-tables for organization-specific data
The organization admin is the "Creator" and manages team membership
Team members are added as "Viewers"
High Compliance Pattern
For applications with strict compliance requirements:
Use "Creators Only" or "Creators and Viewers Only" to prevent even Admins and Authors from seeing sensitive data
Implement field-level security for sensitive information
Use audit trails to track all data access and modifications
Real-World Example: AI Strategy App
The AI Strategy App demonstrates how to implement a secure multi-tenant application where:
Users can sign up and create organizations
Organizations can have multiple team members
Each organization can only see their own strategies
Team members can only access their organization's data
This is achieved through a combination of:
Organization datatable with Teams field
Strategy datatable as a sub-table of Organization
Viewers field to control access to specific strategies
Security Best Practices
When implementing security in your Buzzy applications:
Default to Restrictive Access: Start with the most restrictive access model and gradually open up as needed
Test Security Settings: Always test your security settings with different user accounts
Combine Security Mechanisms: Use multiple security features together for robust protection
Document Your Security Model: Keep track of how security is implemented in your application
Regular Security Audits: Periodically review who has access to what data
Use Sub-tables for Hierarchical Security: Leverage parent-child relationships for complex security models
Implement Field-Level Security: Control access to sensitive fields within records
Troubleshooting Security Issues
Common security-related issues and how to resolve them:
Users can't see records they should have access to
Check if they're properly added to the Viewers field
Verify team/orginization membership if using Team Viewers field
Ensure parent record access if using sub-tables
Confirm the user has the correct role in the application
Users can see records they shouldn't have access to
Review "Who Can View" settings for the datatable
Check role-based permissions
Verify security inheritance settings for sub-tables
Ensure Viewers and Team Viewers fields are properly configured
Changes to security settings not taking effect
Refresh the application
Clear browser cache
Verify changes were properly saved
Check for conflicting security settings at different levels
Last updated