Bubble Docs
  • Introduction
  • New? Start Here
  • What is Bubble?
  • The Glossary
  • User manual
    • Getting started
      • What is Bubble?
      • Building for...
        • Web
        • Native iOS and Android
          • What is a native mobile app?
          • Native mobile vs. web development
          • Differences in native and web elements
          • Native mobile app terminology
      • Building your first app
        • Planning features
        • Database structure
        • Design and UX
        • eCommerce and payments
          • Shopping cart
          • Checkout page
          • One-time payments
          • Subscriptions
          • Marketplace
      • Creating and managing apps
      • The Bubble editor
        • Tabs and sections
          • Design tab
            • The element tree
            • The property editor
          • Workflow tab
          • Data tab
          • Styles tab
          • Plugins tab
          • Settings tab
            • Application settings
              • Custom headers/body
              • Visual settings
              • Social media sharing
              • Translating your app
              • Email settings
              • Collaboration
            • Custom domain and DNS
          • Logs tab
        • Tools
          • Key features
          • The search tool
          • The Issue Checker
          • The element tree
          • The element property editor
          • The debugger
          • Notes
        • Previewing your app
      • Transitioning to Bubble from...
        • JavaScript
        • HTML and CSS
        • SQL
    • Design
      • Elements
        • Web app
          • The page
          • Containers
            • Groups
            • Repeating groups
            • Table elements
            • Popups
            • Floating groups
            • Group focus
          • Visual elements
          • Input forms
            • Text and numbers
            • Dates and time
            • File uploads
            • Selection controls
        • iOS and Android app
          • The view
          • Containers
          • Visual elements
          • Input forms
          • Mobile reusable elements
        • The element hierarchy
          • The element tree
        • Reusable Elements
      • Styling
        • Color variables
        • Font variables
        • Styles
        • Custom Fonts
      • Responsive design
        • Building responsive pages
        • Legacy articles
          • The Basics (Legacy)
          • Building Responsive Pages (Legacy)
          • Migrating Legacy Pages
          • Tips When Designing (Legacy)
      • Templates
      • The Component Library
      • Importing from Figma
    • Data
      • The database
        • Data types and fields
        • Creating, saving and deleting data
        • Finding data
        • Displaying data
        • Protecting data with privacy rules
        • The database editor
        • Export/import data
          • Exporting data
          • Importing data (CSV)
        • Working with location data
        • Using Algolia
        • Database structure by app type
          • Marketplace Apps
          • Directory & Listings Apps
          • Social Network Apps
          • SaaS Apps
          • Project Management Apps
          • CRM Apps
          • Professional Services Apps
          • On-demand Apps
          • Documentation/ CMS Apps
          • Applicant Tracking System (ATS) Apps
          • Portfolio Apps
          • Gallery Apps
          • Online Store / Ecommerce Apps
          • Blog Apps
          • Messaging App
          • Dashboards
          • Building Block Apps
          • Bubble as a backend
      • Files
      • Images
      • Static data
        • App texts (translations)
        • Option sets
      • Temporary data
        • Custom states
        • URL parameters
      • User accounts
        • Authentication plugins
          • Facebook plugin
          • Fitbit plugin
          • Google plugin
          • Instagram plugin
          • LinkedIn plugin
          • Pinterest plugin
          • Slack plugin
          • Wistia plugin
          • YouTube plugin
        • Cookies set by Bubble
      • Time, dates and time zones
    • Logic
      • The frontend and backend
      • Workflows
        • Events
          • Frontend events
            • Recurring workflows
            • Custom events
          • Backend events
            • Database trigger events
        • Actions
        • API Workflows
      • Dynamic expressions
      • Conditions
      • Navigation
        • Single-page applications (SPA)
        • Multi-page applications
        • Page slugs
      • On-device resources
        • Location services
        • Camera/photo library
    • Workload
      • Understanding workload
        • Activity types
        • The workload calculation
        • Client-side and server-side processing
      • Tracking workload
        • Measuring
          • Using App Metrics
        • Monitoring
          • Workload notifications
          • Infinite recursion protection
      • Optimizing workload
        • Optimization framework
        • Optimization checklist
          • Page load
          • Searches
          • Workflows and actions
          • Backend workflows
        • Agency showcases
          • Minimum Studio
          • Neam
          • Support Dept
    • Security
      • Bubble's security features
      • Planning app security
      • Client-side and server-side
      • Bubble account security
      • App security
      • Page security
      • Database security
      • API security
        • API Connector security
        • Data API security
        • Workflow API security
      • Flusk
        • Overview
        • Flusk plan features
        • Getting started with Flusk
        • Flusk security tools
          • The Issues Explorer
          • Issue details
          • Tools and settings
            • Pages rating
            • Database rating
        • Flusk FAQ
      • Cookies
      • Security checklist
    • Previewing your app
      • Previewing a web app
      • Previewing a mobile app
    • Publishing your app
      • Web app
      • Native mobile app
        • Global native mobile settings
        • iOS App Store
        • Google Play Store
        • Publishing FAQ
    • AI
      • Generate apps with AI
        • About AI app generation
      • AI page designer
      • Connect to AI agents
    • Maintenance
      • Collaborators
      • Version control
        • Best practices: Version control
        • Transitioning from the legacy version control
        • Terminology: Version control
        • Version Control (legacy)
      • Commenting
      • Database maintenance
        • Copying the database
        • Restoring database backups
        • Bulk operations
          • Bulk operation methods compared
        • Wiping change history
      • Performance
        • Hard limits
        • Capacity Usage (legacy)
        • Notes on queries
      • SEO
        • Introduction to SEO
        • SEO: App
        • SEO: Page
      • Testing and debugging
        • Introduction to testing and debugging
        • The debugger
        • The server logs
        • Supported browsers
      • API workflow scheduler
    • Integrations
      • API
        • Introduction to APIs
          • What is a RESTful API?
        • The Bubble API
          • Bubble API terminology
          • Authentication
            • How to authenticate
            • No authentication
            • As a User
            • As an admin
          • The Data API
            • Data API Privacy Rules
            • Data API endpoints
            • Data API requests
          • The Workflow API
            • Workflow API privacy rules
            • Workflow API endpoints
            • API workflows
              • Creating API workflows
              • Scheduling API workflows
              • Recursive API workflows
              • API Workflow Scheduler
              • Case: Stripe notifications
        • The API Connector
          • Authentication
          • API Connector security
          • API guides
            • OpenAI
              • Authentication
              • Calls
                • ChatGPT
                  • Chat
            • Google Translate
              • How to setup Google API keys
          • Streaming API
        • API security
        • Plugins that connect to APIs
        • API Glossary
      • Plugins
        • What Plugins Can Do
        • Installing and using Plugins
        • Authentication plugins
        • Special Plugins
      • SQL Database Connector
      • Bubble App Connector
      • WorkOS
        • WorkOS SSO
        • WorkOS API
    • Infrastructure
      • Sub-apps
      • Bubble release tiers
      • Hosting and scaling
        • How Bubble hosting works
        • Scaling with Bubble
        • CDN (Cloudflare)
        • Bubble app names
        • Domain and DNS
      • Compliance
        • GDPR
        • SOC 2 Type II
        • HIPAA
        • Other frameworks and standards
    • Bubble for Enterprise
      • Hosting and infrastructure
        • Dedicated instance
          • The Dedicated editor experience
          • Technical specs
          • Main cluster dependencies
          • Customizable options
          • Migration process
            • Pre-migration
            • During migration
            • Post-migration
      • Security and compliance
        • Single sign-on (SSO)
        • GDPR
        • SOC 2 Type II
        • HIPAA
        • Other frameworks
        • Bubble's security features
      • Admin and collaboration
      • Priority support
      • Billing and Payment Guideline for Dedicated Instances
  • Core Reference
    • Using the core reference
    • Bubble's Interface
      • Design tab
      • Design tab (Legacy)
      • Workflow tab
      • Data tab
      • Styles tab
      • Styles tab (Legacy)
      • Plugins tab
      • Settings tab
      • Logs tab
      • Template tab
      • Toolbar
      • Top and context menu options
      • Deployment and version control
        • Deployment & Version Control Dropdown (legacy)
      • Notes
    • Elements
      • Native mobile elements
        • View element
        • List component
      • General properties
      • General properties (Legacy)
      • Styling properties
      • Styling Properties (Legacy)
      • Responsive Properties
      • Responsive Properties (Legacy)
      • Conditional formatting
      • States
      • Page Element
        • Page Element (Legacy)
      • Visual Elements
      • Containers
      • Container Layout Types
      • Containers (Legacy)
      • Input Forms
      • Reusable Elements
      • Element Templates (legacy)
    • Workflows
    • Events
      • General events
      • Element events
      • Custom events
      • Recurring event
      • Database trigger event
    • Actions
      • Account
      • Navigation
      • Data (things)
      • Email
      • Element
      • Custom
    • On-device resources
    • Data
      • Data Sources
      • Operators and comparisons
      • Search
      • Privacy
    • Styles
    • API
      • The Bubble API
        • The Data API
          • Authentication
          • Data API endpoints
          • Data API requests
        • The Workflow API
      • The API Connector
        • Authentication
        • Adding calls
    • Bubble-made Plugins
      • AddtoAny Share Buttons
      • Airtable
      • API Connector
      • Blockspring
      • Box
      • Braintree
      • Bubble App Connector
      • Chart.js
      • Circle Music Player
      • Draggable Elements
      • Dropzone
      • Facebook
      • Fitbit
      • Full Calendar
      • Google
      • Google Analytics
      • Google Optimize
      • Google Places
      • Ionic Elements
      • iTunes
      • Slidebar Menu
      • LinkedIn
      • Localize Translation
      • Mixpanel
      • Mouse & Keyboard Interactions
      • Multiselect Dropdown
      • Progress Bar
      • Rich Text Editor
      • Rich Text Editor (Legacy)
      • Screenshotlayer
      • SelectPDF
      • Slack
      • Segment
      • Slick Slideshow
      • SQL Database Connector
      • Star Rating
      • Stripe
      • Tinder-like Element
      • Twitter
      • YouTube
      • Zapier
    • Application Settings
      • App plan
      • General
      • Domain / email
      • Languages
      • SEO / metatags
      • API
      • Collaboration
      • Sub-apps
      • Versions
  • Account & Marketplace
    • Account and billing
      • Pricing and plans
        • Plans and billing
        • Billing cycle
        • FAQ: Pricing and Workload
      • Account Management
      • Building Apps for Others
      • Selling on the Marketplace
      • Plans & Billing (legacy)
    • Official Bubble Certification
      • Hiring certified developers
    • Building Plugins
      • The Plugin Editor
      • General Settings
      • Updating to Plugin API v4
      • Adding API Connections
      • Building Elements
      • Building Actions
      • Loading Data
      • Publishing and versioning
      • Github Integration
    • Building Templates
    • Application and data ownership
    • Marketplace policies
    • Bug reports
  • Vulnerability Disclosure Policy
  • Beta features
    • About the Beta features section
    • Native mobile apps
Powered by GitBook
On this page
  • Data types recommended
  • User
  • Company
  • Plan
  • Subscription
  • Customer
  • Project
  • Task
  • Option sets recommended
  • User Role
  • Plan Status
  • Plan Frequency
  • Example uses in your app
  • About the author: Coaching No Code Apps

Was this helpful?

  1. User manual
  2. Data
  3. The database
  4. Database structure by app type

SaaS Apps

By Gaby Román, Co-Founder of Coaching No Code Apps

Various members of the Bubble ecosystem contributed these use case-oriented database guides. There's always more than one way to do something in Bubble, but the advice here can help you get started if you're new to Bubble!

SaaS app data structures are unique in that almost all of the data needs to be organized under an account hierarchy. For example, every user that signs up might represent a company, so they may have a team, customers, and other resources that should all link back to that parent company.

The following data structure is recommended for companies that need a project management tool for internal operations. Users of the app can create and organize projects with related tasks. For example, a manufacturing company with product design and marketing teams would be able to manage the various to-do items within their departments while company managers can track company-wide project statuses and assignments. Overall, this would streamline communications between teams, better visualize company metrics, and help management make more intuitive business decisions.

Data types recommended

These data types are designed from the perspective of one company. Every company that signs up to your app will have a single “Company” record in the database, one or more “Users” (team members, managers, etc.), and related resources that are unique to the Company, such as “Customers,” “Projects,” and “Tasks.” The “Subscription” and “Plan” data types will help you manage each Company’s subscription with you, the app owner. The more Companies that sign up, the more records are created, but the key is to relate Company specific records like Customer or Project back to the parent Company for data security.

User

This is Bubble’s only built-in data type. Anyone who needs to be able to log into the app should have a User record.

Suggested fields on this type

  • First Name (text)

  • Last Name (text)

  • Related Company (Company): This field is important for knowing which data the user has access to and can be leveraged in many different privacy rules.

    • Privacy rule example under Customer: “When This Customer’s Related Company is not the Current User’s Related Company” > disable all checkboxes

  • Role (User Role, an option set): By assigning users with specific roles, you can control their access to pages, visual elements, and workflows. For example, a User whose Role is Company Admin can have the ability to create other Company Members, whereas Company Members themselves cannot.

Privacy rules for this data type

The User’s “Role” and “Related Company” will be the starting point for creating privacy rules both for the User data type itself and all other Company-specific types.

For the User data type, we suggest creating a rule that only allows users to access other user records within their same company, not other companies. You can do this with the following rule: “Current User’s Related Company is This User’s Related Company.”

You can break this down one step further by only giving Company Admins the ability to view more fields and/or edit other Company users; in addition, allowing the current user to have full access to their own record:

  • Current User’s Related Company is This User’s Related Company and Current User’s Role is ‘Company Admin’ > view all fields, allow auto-binding

  • Current User’s Related Company is This User’s Related Company and Current User’s Role is ‘Company Member’ > view selected fields, don’t allow auto-binding

  • Current User is This User > allow everything

Company

Suggested fields on this type

  • Name (text)

  • Admin (User): While this field isn’t necessary (as long as you can identify Users by their role and related Company), it’s a very handy “shortcut” to the Company’s Admin, especially if you need to reference that user often.

  • Related Subscription (Subscription): This is a reference to the custom Subscription record created for this Company. It’s another shortcut field that is typically helpful if you have multiple pricing plans that tier off features. Having quick access to the “Company’s Related Subscription’s Plan” can make it easier to create conditional expressions.

Privacy rules for this data type

Users should only be able to access their own Company’s record, which you can do with the following: Current User’s Related Company is This Company > allow full access

If you have a User Role for a System Admin (i.e. yourself, the app owner), then you can create a more global rule to give you access to all Companies, like this: Current User’s Role is System Admin > allow full access

The default “Everyone Else” rule should have all access options disabled. If the user is not a part of the Company nor a System Admin, then they cannot access the Company record in question.

Plan

This is a helpful data type to organize all your subscription plan levels. Our example includes an ID field for a payment gateway (e.g. Stripe, PayPal, etc.) so you have an easy reference to the equivalent entity on the gateway’s side. Note that this is not unique to a Company.

Suggested fields on this type

  • Name (text)

  • Description (text)

  • Amount (number): This would be the amount charged for every billing cycle. E.g. 50 if frequency is set to “Month” vs 500 if frequency is set to “Year” for a discounted annual plan.

  • Frequency (Plan Frequency, an option set)

Privacy rules for this data type

This data type doesn’t need a privacy rule because it’s not tied to any specific Company and holds no sensitive information. It’s a general system table that describes Subscription Plan options. These need to be available to everyone, including logged out users.

Subscription

This record saves the unique combination of a selected plan for a Company and any details about the Subscription itself such as the active date and status.

Suggested fields on this type

  • Related Company (Company)

  • Related Plan (Plan)

  • Active Date (date)

  • Canceled Date (date)

  • Status (Plan Status, an option set): This is a helpful field to keep track of which Companies are active or not and what kind of access they should have.

  • Payment Gateway ID (text)

Privacy rules for this data type

Create rules that give the System Admin and Company Admins access to this record:

  • Current User’s Role is System Admin > allow full access

  • Current User’s Role is Company Admin and Current User’s Related Company is This Subscription’s Related Company > allow full access

Customer

This is an example of a Company resource they might need in a SaaS app. Each Company would have their own Customers to build out their CRM. Again, don’t forget to include the “Related Company” field so that Company users can only have access to Company Customers.

Suggested fields on this type

  • Related Company (Company)

  • First Name (text)

  • Last Name (text)

  • Phone Number (text): While it might be tempting to create this as a number, you’ll be able to format phone numbers better for different countries if it's text. Plus, you never need to do math with phone numbers, so you’re not losing any capability.

  • Email Address (text)

  • Notes (text)

Privacy rules for this data type

Only System admins and Company users should be able to access Customers that are tied to their same Company:

  • Current User’s Role is System Admin > allow full access

  • Current User’s Related Company is This Company > allow full access

If you want to split up access to fields and auto-binding by Company Role, you can create separate rules per Role to break that down.

Project

This is another company-specific resource record.

Suggested fields on this type

  • Related Company (Company)

  • Title (text)

  • Manager (User): This is a shortcut field to the Company User (whether their role is Admin or Member) that is responsible for this specific project.

  • Team Members (list of Users): This is a shortcut field to any Company Users that might be assigned Tasks for this Project.

  • Due Date (date)

Privacy rules for this data type

Follow the same rules you created for the Customer data type.

Task

Suggested fields on this type

  • Related Company (Company)

  • Related Project (Project)

  • Title (text)

  • Due Date (date)

  • Completed Date (date)

  • Assigned To (list of Users): Here, we chose to make this a list in case a Task should have the ability to be assigned to more than one person.

Privacy rules for this data type

Follow the same rules you created for the Customer data type.

Option sets recommended

User Role

  • System Admin

  • Company Admin

  • Company Member

If your application offers different roles where access to data, pages, or even workflows are specific to that role, an option set is a great way to identify who the users are.

Plan Status

  • Active

  • Inactive

Plan Frequency

  • Month

  • Year

Example uses in your app

  • Viewing Projects Assigned to Me

    • Once the user logs into the app and opens up their “dashboard” page, they should be able to see a list of projects with tasks that are assigned to them.

    • The following search expressions can be used to show the user relevant projects:

      • Search for Projects (Team Members contains Current User)

      • Search for Tasks (Assigned To contains Current User) ‘s Related Projects

  • Viewing My Tasks filtered by Completion status

    • The user should be able to see Tasks assigned to them and filter the list to view which ones are completed, which ones are due, and which ones are overdue.

    • The following search expressions can be used to show the user their tasks with various filters:

      • Completed Tasks: Search for Tasks (Assigned To contains Current User; Completed Date isn’t empty)

      • Upcoming Tasks: Search for Tasks (Assigned To contains Current User; Completed Date is empty; Due Date > Current Date/Time)

      • Overdue Tasks: Search for Tasks (Assigned To contains Current User; Completed Date is empty; Due Date < Current Date/Time)

About the author: Coaching No Code Apps

Last updated 2 years ago

Was this helpful?

This is a very important data type for SaaS structures because it’s the most parent entity that will help you segment the rest of your app’s data in a single application. structures don’t require this as much if each sub-app is created per company, in which case, they’re already given independent databases. Whether this data type represents a “Company” or an “Account,” make sure all other data types whose records are unique to their parent have a field that ties back to this record.

This is another company-specific resource record and is seen as a “child” of the Project data type. Meaning, a Project is made up of a list of Tasks, but notice how we didn’t include a List of Tasks field under the Project data type. Since a Project could be long-term and potentially have hundreds of tasks, it’s better to have a one-way relationship on the Task side for performance. See .

Your database structure creates the entire foundation for your app as a whole, and because of its importance, it's one of the first things we focus on with our own clients before moving onto broader functionality. For help putting all the right pieces into place and creating a scalable app using Bubble, join a free workshop focused on scoping, building, and launching your no code app at .

Sub-app
this article
https://coachingnocodeapps.com/workshop