Bubble Docs
  • Introduction
  • New? Start Here
  • What is Bubble?
  • The Glossary
  • User manual
    • Getting started
      • What is Bubble?
      • 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
        • The element hierarchy
          • The element tree
        • 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
        • 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
    • 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
    • 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
      • 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
    • 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 🔒
      • Introduction
        • What is a native mobile app?
        • Native mobile vs. web development
        • Differences in native and web elements
        • Native mobile app terminology
      • Building
        • Views and navigation
        • Native mobile actions
        • Components and gestures
        • Device resources
          • Location services
          • Camera/photo library
      • Previewing
      • Publishing
Powered by GitBook
On this page
  • Data types recommended
  • Restaurant
  • Menu Item
  • Cart Item
  • Order
  • Review
  • User
  • Option sets recommended
  • Status
  • Example uses in your app
  • Additional notes
  • About the author: Zeroqode

Was this helpful?

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

On-demand Apps

By Zeroqode Team

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!

The on-demand type app can be easily associated with startups like Uber, Instacart, BloomThat, etc. Overall, on-demand apps generally contain capabilities for ordering, delivery, and tracking functionality via a map. Customers can order something from the platform and wait for a courier to deliver the items from a restaurant, for instance. Think UberEats, as one example.

The following guide will give some recommendations for data types and option sets when setting up the database of your on-demand app. The target Bubble app will allow users to have a platform where it is possible for restaurants to list their menu with different meals, and for customers to add menu items to a shipping cart and place orders. The drivers will pick the order and deliver it to the customer.

Data types recommended

The main data type is User, of course. Users are picking different Menu Items from a menu to add to their shopping cart in the form of Cart Items, then placing an Order in order to confirm the payment. Meals come from a specific Restaurant. After completing the payment and receiving the Order, the customers are able to leave a Review for the Restaurant they ordered food from.

Restaurant

This data type contains all the details about a restaurant registered on the platform, ranging from its name to its location. It contains all the list of Menu Items the restaurant offers. As the platform begins running, this data type will also track the Orders that users make from this restaurant.

Suggested fields on this type

  • name (text): the name of the restaurant, as displayed in the app

  • description (text): to store the restaurant description for customers

  • approved (yes / no): to store whether or not the restaurant has been approved by the platform, in case you want to hide the un-approved ones

  • location (geographic address): to store the geographic location of the restaurant so that it can be displayed on a map

  • menu items (list of Menu Items): to store the list of all menu items that are available to buy from this restaurant

  • orders (list of Orders): to store the list of orders related to this restaurant

  • owner (User): to store the restaurant owner’s information; note this assumes that every restaurant owner is also a user on your platform, but we can show owners of restaurants different pages or information relative to users who are purely shoppers on the platform

  • reviews (list of Reviews): to store the list of reviews related to this restaurant, so customers can see the feedback

Privacy rules for this data type

Menu Item

This data type stores information about the individual item from a Restaurant’s menu, which can be added by a user to their cart. A Menu Item comes from a specific Restaurant, and for simplicity’s sake, we can implement logic at the workflow level (i.e. not shown in this guide) to make it so that all the Cart Items in a given cart must come from the same Restaurant.

Suggested fields on this type:

  • restaurant (Restaurant): to store the Restaurant that offers this menu item

  • name (text): to store the name of this menu item, so it is possible to display it

  • description (text): to store a description of this meal (optional, but may be handy)

  • picture (image): to store a picture of this menu item

  • price (number): to store the price of this meal

Privacy rules for this data type

All these fields are ones that aren’t particularly sensitive, so they would likely be visible to all users. However, one nice feature for Restaurant owners might be to enable autobinding for any fields on a Menu Item that is associated with their Restaurant.

Cart Item

This data type is used to add meals to the shopping cart. It stores the information such as the Menu Item (related to a Restaurant) being added to the cart, the total price, quantity, etc. All the Cart Items in a user’s cart will be added to an Order prior to payment. You can also think of a Cart Item like one line item in the user’s ultimate receipt for an order.

Suggested fields on this type

  • menu item (Menu Item): this is the item that the user adds to the cart; the user chooses which Menu Item, then the other fields below dictate the quantity they want of that item and the price that comes out to

  • quantity (number): to store the quantity of the menu item added to the shopping cart

  • total price (number): to store the total price of the chosen quantity of the Menu Item; storing this is useful in case the restaurant changes the price of the item in the future; if it’s stored here, the app will remember how much the item(s) cost at the time of purchase

Privacy rules for this data type

Since users’ shopping carts will be private to themselves, we would create privacy rules to only make any Cart Item findable in searches and all of its fields visible to the creator of the Cart Item.

Order

This data type stores information about orders created on the platform. It contains information about the Cart Items that the user added to their cart, and we can assume that an Order is created during the (successful) checkout process. This data type also will store various information about how the payment works, including the fee the app will take and the amounts that will be paid out to the different parties of the transaction (the restaurant’s cut, driver’s cut, etc.).

Suggested fields on this type

  • cart items (list of Cart Items): to store the list of the cart items that are being purchased as part of this order

  • restaurant (Restaurant): to save the Restaurant that the meal was ordered from

  • delivery address (geographic location): to store the address this order should be delivered to

  • courier (User): to store who will deliver this order; note that this means we assume all couriers on our platform will also be Users in the app

  • order total price (number): to store the total price for this order

  • app revenue (number): to store the platform's cut for each order transaction

  • courier fee (number): to store the payment amount taken by the courier as their cut

  • restaurant payout (number): to store the total payment amount received by the restaurant for the order

  • current status (Status): to store the status of this order; this will be an option set of pre-determined options (see below)

  • payment ID (text): if you’re using a platform like Stripe to manage payments, this field can store the unique ID of this payment

  • order ID (text): to help all parties manage a particular order, it can be helpful for your app to generate a unique order ID for this order, which would be stored here

Privacy rules for this data type

Orders should only be visible (i.e. findable in searches) to the parties of the transaction - the Users who are either the ones placing the order, who are the couriers delivering the order, or who are the restaurant owners fulfilling the order. Moreover, sensitive fields like payment IDs and the various prices and payouts should have privacy rules set such that only the relevant party can see them.

Review

After the order is completed, users who placed the order can leave a Review. We’ll assume that Reviews are about a particular Restaurant.

Suggested fields on this type

  • reviewer (User): to store the User who is writing the review

  • restaurant (Restaurant): clarifies which restaurant this review is about

  • rating (number): we can use a 0 to 5 scale for ratings

  • text (text): any free-form content the user wants to leave as part of the review

Privacy rules for this data type

Reviews for a Restaurant can generally be left public, i.e. they can be found by any User. For the privacy of those writing the reviews, you may want to specifically hide the reviewer field from the public.

User

This data type contains information about the users on the platform. As we have seen above, there are different kinds of Users on our platform - customers, Restaurant owners and couriers. So for now, our User data type will have fields that relate to any of those three types of users; this means that more Users in the database are unlikely to have all the fields filled out, since they are unlikely to be a customer, Restaurant owner and a courier all at the same time.

Suggested fields on this type

  • first name (text): self-explanatory; it’s useful to save the user’s first name as its own field so you can easily do things like incorporate their first name into a confirmation email’s greeting

  • last name (text): self-explanatory

  • is admin (yes / no): it’s often useful to create a field on User to determine whether that user has special privileges with the platform; for example, this can be used to control whether the user can see an admin panel to help manage all orders (useful for your customer support team)

  • address (geographic address): to store the address of the user so it can be pre-filled for future orders

  • favorite restaurants (list of Restaurants): to store the list of restaurants a customer likes, if you want to build this feature into your platform

  • cart (list of Cart Items): this is how we build a ‘shopping cart’ feature - this field stores the list of items added to the shopping cart by the customer, which can then be referenced when the user goes to checkout; after a successful checkout, you can clear this field on User so that they start from an empty cart on their next visit

  • driver license number (text): to store the number of the driver’s license for courier users

  • driver license picture (image): to store the photo of the driver’s license for courier users

  • orders (list of Orders): to store the list of orders the customer made, as an order history

  • owned restaurant (Restaurant): to store the Restaurant object in case the current user is a restaurant owner

Privacy rules for this data type

As with many apps, our User data type contains sensitive information that generally should not be available to the public, e.g. last name, address, driver license information, etc. Any such sensitive field should be hidden from view for anybody except the user themselves and perhaps any admin users on the platform.

Option sets recommended

Status

  • New

  • Accepted

  • Found a courier

  • Picked up

  • Delivered

  • Canceled

This option set is used to define the available statuses of an Order. As the order goes through different stages of its life-cycle, various workflows would advance the status of the Order as various updates happen.

Example uses in your app

Let’s assume that our app, now called Eaty, has an admin page where a member of the platform’s team can see all orders:

The main repeating group on the page shows a query of all Orders by default, but note how the other horizontal tabs on the page would show a list of Orders with filters for different Statuses. For each Order on the page, we see various fields about the Order.

Additional notes

After building the basic functionality of an on-demand app, you may want to consider more advanced features. For example, on-demand apps often benefit from a chat feature with the other parties in the order, push notifications to alert users about order status changes, and a live map to track the delivery. Moreover, you may want to create some mobile-optimized pages for those using the app on the go, such as your couriers. Luckily, all these features and more are possible with Bubble.

About the author: Zeroqode

Last updated 3 years ago

Was this helpful?

You can create privacy rules to allow only the restaurant’s owner to see certain fields on their restaurant. If the owner has a page to edit their restaurant’s information, you can also for the fields they’re allowed to edit.

A good example of a ready-made on-demand Bubble app is the template from .

They have also built a great range of 🔌 to boost the development of your Bubble app, as well as 🎓 courses to improve your Bubble skills.

enable auto-binding
Eaty
Zeroqode
Plugins
Lab