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
          • Mobile app quick start guide
          • 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
      • 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 native mobile 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
  • ParentOrganization
  • Company
  • Contact
  • Lead
  • Option sets recommended
  • Company Type
  • About the author: Amlie Solutions

Was this helpful?

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

CRM Apps

By Petter Amlie, founder of Amlie Solutions

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!

In this example, we are building a CRM or Customer Relationship Management software. This is used by organizations to keep track of their clients, vendors and contacts.

Well-known CRM examples are Salesforce, Insightly, Zoho CRM and SuperOffice. We’re going to set up a CRM that allows multiple clients to work in the same software without seeing each other’s data (typically called a SaaS model), and this will be reflected in some of the ways we structure the Data and Privacy Rules. What this means in practice is that I, as a paying client, will only have access to see and make changes to my own data, and I can trust that nobody else has access to my data.

Additionally, the way we set it up allows for multiple Users for each client, since the client will typically be a company itself. This way, an account owner can invite their team into your CRM platform to collaborate on sales processes and customer management.

Data types recommended

We’ll be working with a fairly simple set of Data Types to show the principles behind the multi-client CRM model. This could easily be extended with more Data Types (such as Deals, Projects, Tasks and Meetings) using those same principles. Most Contacts and Companies added to the platform will start their life-cycle as a Lead, that then becomes a Contact and/or Company as it moves through the sales process.

ParentOrganization

The ParentOrganization is the organization that your app’s Users belong to. For example, I might register as a company called Acme Inc. and add all my 25 employees to that ParentOrganization. Those 25 employees will then have access to only data that belongs to their ParentOrganization, and nothing else. To make this happen, we need to add the ParentOrganization to all other Data Types and set up Privacy Rules for each of them.

The ParentOrganization is created when the first user in that organization registers in your application, and then that User invites their team to that organization.

In principle, this organization only needs a name; we can set up the Data Type as below:

Suggested fields on this type

  • Name (text)

  • Owner (User) - this will be the User who first registered the account and is the owner, or admin, of it

Privacy Rules

As we explored earlier, the ParentOrganization makes up the primary security “fence” of your application: all Users should only be able to access data that belongs to their ParentOrganization. This also means that we need to keep the ParentOrganization itself private: Users outside of my organization shouldn’t even know that we have an account. So let’s set that up like this:

If this ParentOrganization is Current User’s ParentOrganization, this User can:

  • View all fields: yes

  • Find this in searches: yes

  • View attached files: yes

  • Allow auto-binding: no

Ok, so that Rule lets only Users who belong to that ParentOrganization to see its details, but note that we’re blocking access to edit it. But remember, when the Organization is first set up, we also set up a field for Owner. That particular User should be able to make changes to their own organization. That would look like this:

If this ParentOrganization’s Owner is Current User’s ParentOrganization, this User can:

  • View all fields: yes

  • Find this in searches: yes

  • View attached files: yes

  • Allow auto-binding: yes

Notice the last rule in bold: since this User is the owner of the ParentOrganization, we’ll allow that User to make changes to it.

Company

Now we move on to the actual data that your Users will store in the CRM. A Company is any organization that you add to your CRM that’s not your own. A Company can be both a Client and a Vendor, as separated by the Company type field. We have added a few standard fields like phone number and address, and you can of course add as many more as you need to store more information.

Suggested fields on this type

  • ParentOrganization (ParentOrganization) - connects this to the entity who owns this data and thus should be allowed to see it; see this article

  • Name (text)

  • Address (Google Maps address)

  • Phone (text)

  • Website (text)

  • Type (list of Company Types, an option set) - note that this is a list of Company Types. If you add just Client to that list, then the Company can be sorted as a Client, and the same if you add Vendor. However, since we’re using a list here, you can add both Client and Vendor, allowing a Company to be both.

Privacy rules

Since we set up our ParentOrganization in the last step, we now need to make sure that the Company type we’ve created is only available to Users who belong to the Organization to which it was added:

If this Company’s ParentOrganization is Current User’s ParentOrganization and Current User’s ParentOrganization is not empty, this User can

  • View all fields: yes

  • Find this in searches: yes

  • View attached files: yes

  • Allow auto-binding: yes

So, our rule says that the Company belongs to a ParentOrganization, and so does the User: as long as these two match, that User can see and edit the Company. Take note of the second condition we’ve added: and Current User’s Organization is not empty - this is an extra level of security that will stop Users from seeing Companies if both the ParentOrganization of the Company and the User is empty (in which case they will technically match). This should never happen, of course: but since software bugs do occur sometimes, this gives us an extra layer of security even in the unlikely case that both the User’s ParentOrganization and the Company’s ParentOrganization is somehow lost or deleted.

Contact

In many cases when you add a Company to your CRM, you’ll also want to add Contacts to that Company. A Contact needs to contain information similar to what you would save in your phone’s phone book. A Contact doesn’t have to belong to a Company, but if they do we can use that field to filter and sort Users in our platform:

Suggested fields on this type

  • ParentOrganization (ParentOrganization)

  • Company (Company) - the custom Data Type above

  • First name (text)

  • Last name (text)

  • Phone (text)

  • Email (text)

  • Address (Google Maps address)

  • Date of Birth (date)

  • LinkedIn Profile (text)

Privacy Rules

The Privacy Rules for a Contact are similar to a Company: Users should only be able to see Contacts that belong to their own ParentOrganization. Let’s set it up like this:

If this Contact’s ParentOrganization is Current User’s ParentOrganization and Current User’s ParentOrganization is not empty, this User can:

  • View all fields: yes

  • Find this in searches: yes

  • View attached files: yes

  • Allow auto-binding: yes

Lead

A Lead is a bit different from Contacts and Companies in that they are more temporary. They are basically potential clients: you don’t know whether they will convert to an actual client yet, and your Users may not want to store them as a Contact just yet to avoid overflooding the database with irrelevant Contact and Company records. A Lead can typically come into contact with your Client using a contact form: they’ll provide their contact information, but it’s too early to say whether they’re serious about doing business

If a Lead does convert into business, we’ll convert it into a Contact and/or a Company. At this point we’ll create the Contact/Company record based on the information saved in the Lead. Optionally, we can delete the initial Lead at that point (unless you want to keep it around)

We’ll introduce a slight change to this Data Type to illustrate what’s possible with Privacy Rules: we’re going to assume that if this Lead was created by an employee, we want only that employee to be able to edit it. We’re going to use the built-in Created by field for that.

Suggested fields on this type

  • ParentOrganization (ParentOrganization)

  • First name (text)

  • Last name (text)

  • Company name (text)

  • Phone (text)

  • Email (text)

  • Comment (text): if you are generating leads from a contact form, a comment field is a great way to save what kind of interest the lead has in your company.

Privacy Rules

For this one, we’re actually creating two Privacy Rules. One is to make the Lead visible to all members of the same ParentOrganization (like we did with the other Data Types), and the second rule is to let the Lead’s Creator be the only one allowed to make changes to it:

If this Lead’s ParentOrganization is Current User’s ParentOrganization and Current User’s ParentOrganization is not empty and this Lead’s Created by is not Current User, this User can

  • View all fields: yes

  • Find this in searches: yes

  • View attached files: yes

  • Allow auto-binding: no

If this Lead’s ParentOrganization is Current User’s ParentOrganization and Current User’s ParentOrganization is not empty and this Lead’s Created by is Current User, this User can:

  • View all fields: yes

  • Find this in searches: yes

  • View attached files: yes

  • Allow auto-binding: yes

Note like in our ParentOrganization that the only difference is in the final Rule. In plain English, we’re saying that if the Current User created this Rule, then that User should be able to edit it (by allowing auto-bind).

Option sets recommended

For any data that’s shared between all Users of the platform and remains fairly static, we can use an Option Set. Option Sets load faster than data in your database, but they’re not meant to hold any private information.

In our CRM, we’ll use it to store the two types of Companies in our database.

Company Type

  • Client

  • Vendor

The Company Type Option Set is used to separate Client and Vendor companies. We’re storing the Company Type as a List, which makes it possible to make a Company both a Client and a Vendor.

About the author: Amlie Solutions

This guide is written by Petter Amlie. Petter is the founder of Amlie Solutions, a no-code expert, public speaker and author of two books on Bubble: The Ultimate Guide to Bubble Performance and The Ultimate Guide to Bubble Security. You can find a growing number of free guides, video courses and in-depth articles on his website.

…

Last updated 3 years ago

Was this helpful?