Buzzy Documentation
  • Welcome to Buzzy
  • Getting Started with Buzzy
    • Getting Started Guide
      • 1. Starting with Buzzy AI
      • 2. The Buzzy Workspace
      • 3. Create a new app
      • 4. Preview and edit your app
      • 5. Manage your app
      • 6. Import your app to Figma
      • 7. Using Buzzy with Figma
      • 8. The Buzzy Figma plugin
      • 9. Creating a simple app
      • 10. Screens and navigation
      • 11. Forms, fields and data
      • 12. Data-driven menus & content
      • 13. Data edit and delete
      • 14. Search, sort and filter
      • 15. User login and registration
    • Buzzy AI or Figma first?
  • Working with Buzzy
    • Buzzy AI
      • About Buzzy AI
      • Kickstart with AI
      • Enhance with Figma
      • Extend with Code
      • Example prompts
      • Tips
      • Troubleshooting Buzzy AI
      • AI tokens and pricing
    • Buzzy for Figma
      • About Buzzy for Figma
      • Learning Figma
      • Creating a new app directly in Figma
        • Step by step version
      • Automarkup
      • Responsive layouts
      • Responsive layout checklist
      • Overflow and scrolling
      • Forms and fields
      • Logging users in to your app
      • Theming
      • Troubleshooting Buzzy for Figma
      • Plugin error messages
    • Buzzy Deployment & App Stores
      • Setting up your custom Buzzy app
      • Connecting your own server
      • Apple & Google App Stores
    • Buzzy Marketplace
      • Buzzy Accreditation
    • Buzzy Project Guide
    • Buzzy App Examples
      • Buzzy Templates
      • AI-Powered Chat App
      • AI-Powered Custom T-Shirt App
      • AI-Powered Strategy App
      • AI-Powered Stock Portfolio App
      • Golf Course Finder
      • Personal Finance App with Figma AI
    • FAQs
  • The building blocks
    • Datatables, Fields & Data
      • Introduction to Fields
      • Basic Fields
        • Text
        • Number
        • Date
        • Location
        • Toggle
        • Checkboxes
        • Checklist
        • Selectlist
        • Rating
        • Attachments
        • Images
        • Signature
        • Audio Recording
        • Embedded Link
      • Advanced Fields
        • Formula
        • Sub tables
        • Linked Table field
        • Button
        • Teams
        • Payment
        • Notification
        • Event
        • User Vote
      • Display Fields
        • Header
        • Display Text
        • Image
        • Divider
      • Metadata Fields
        • Author Name
        • Author Phone
        • Submitted
      • Filter Controls
        • Viewers
        • Tags
        • Condition
      • External Fields
        • IBM Connections File
        • Box File
      • Sort Fields
      • Formulas
      • Datatable to Datatable Relationships
      • Security and Access Control
      • Displaying a field based on the values of other fields
      • Hiding a field based on role using a display formula
      • Importing data from a text file
      • Importing data from a URL
      • Import data from Datatable
      • Export data using Chrome
      • Export data in Browser
      • Export data using Safari
      • Datatable Field Type - Cheat Sheet
      • Troubleshooting Fields & Data
    • Code widget (custom code)
      • Code Widget Fields - Advanced Guide
      • New Async API + React HTML Components
      • Examples
        • Image Galley Slideshow
        • Ratings Average and Distribution
        • Event Locations Map
    • Analytics
  • Troubleshooting
    • App Error Codes
      • Action Error
      • App Not Found
      • Component Missing
      • Component Not Set
      • Component Settings Error
      • Datatable Not Found
      • Datatable Not Set
      • Field Not Found
      • Field Not Set
      • No App Selected
      • No Context Name
      • No Screens Found
      • Runtime Exception
      • Screen Not Found
      • Screen Not Set
    • Troubleshooting Buzzy AI
    • Troubleshooting Figma
  • REST API
    • Buzzy REST API
      • Integrating 3rd party applications
      • REST API
        • login
        • createappwithprompt
        • MicroApp Data Operations
          • microappdata
          • microappdata/row
          • insertmicroapprow
          • updatemicroapprow
          • removemicroapprow
          • microappchild
        • User & Organization Operations
          • userid
          • insertteammembers
          • teammembers
          • insertorganization
          • insertteam
        • enforceteammembership
      • Node.js API Client
      • Datatable Rules
      • Datatabledata Tutorial
      • Integrating with Mailchimp
      • Python Access Datatable
  • Advanced Deployment Settings
    • Installation
      • Pre-installation Planning
      • Deployment
        • Introduction to deployment
        • Minikube install guide
        • AWS ECS Fargate install guide
        • HCL Connections install guide
        • Azure AKS install guide
        • Windows container install guide
      • Buzzy settings
      • Whitelabelling Buzzy
      • Certificates
      • Release Management
    • Performance and Reliability
    • Security
      • Platform
      • Users and Roles
      • Datatables
      • Audit Trail
Powered by GitBook
On this page
  • Application-Level Security
  • Application Privacy Settings
  • Application Roles
  • Authentication Methods
  • Organization and Team-Level Security
  • Organizations
  • Teams
  • Setting Up Organizations and Teams
  • Datatable-Level Security
  • Who Can View Settings
  • Who Can Submit Settings
  • Who Can Delete Settings
  • Viewers Field
  • TeamViewers Field
  • Field Interaction Controls
  • Hierarchical Security with Sub-tables
  • How Sub-table Security Works
  • Setting Up Sub-table Security
  • Sub-table Security Use Cases
  • Common Security Patterns
  • Personal Data Pattern
  • Anonymous Feedback Form
  • SaaS Application Pattern
  • High Compliance Pattern
  • Real-World Example: AI Strategy App
  • Security Best Practices
  • Troubleshooting Security Issues
  1. The building blocks
  2. Datatables, Fields & Data

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

  1. Create organizations in the Buzzy Workspace

  2. Create teams within each organization

  3. Add users to appropriate teams

  4. 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

  1. Create a parent datatable with appropriate security settings

  2. Create a child datatable as a sub-table of the parent

  3. 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

  1. Users can sign up and create organizations

  2. Organizations can have multiple team members

  3. Each organization can only see their own strategies

  4. 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:

  1. Default to Restrictive Access: Start with the most restrictive access model and gradually open up as needed

  2. Test Security Settings: Always test your security settings with different user accounts

  3. Combine Security Mechanisms: Use multiple security features together for robust protection

  4. Document Your Security Model: Keep track of how security is implemented in your application

  5. Regular Security Audits: Periodically review who has access to what data

  6. Use Sub-tables for Hierarchical Security: Leverage parent-child relationships for complex security models

  7. Implement Field-Level Security: Control access to sensitive fields within records

Troubleshooting Security Issues

Common security-related issues and how to resolve them:

  1. 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

  2. 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

  3. 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

PreviousDatatable to Datatable RelationshipsNextDisplaying a field based on the values of other fields

Last updated 22 hours ago

The demonstrates how to implement a secure multi-tenant application where:

AI Strategy App