Data structure
The database structure for the template
All objects and some selected fields in the template are explained below. Please refer to our Bubble Best Practices document for guidance on how the Bubble database should be structured.
All data types and a few select fields are explained below. A good general rule to follow is that you shouldn't delete any fields that are included with the template and instead only add new ones.
Block entry
This data type is used to store content that goes into each homepage block. Each homepage block (template) will have a maximum number of block entries:
Testimonials section: Multiple entries
Featured section: Up to 3 entries
Process section: Up to 3 entries
Slideshow section: Between 3 to 5 entries
Capabilities section: Up to 9 entries
Video section: 1 entry
Press section: Between 3 to 5 entries
About section: 1 entry
Call-to-action section: 1 entry
Pricing section: Up to 4 entries
Html section: Multiple entries
Contact section: 0 entries
Dummy
This data type allows you to quickly preview your page layout by it as your data source. This is filler data for designers to create the UI.
These fields can be used to see what the UI of a page looks like with given types of data, which is helpful when you want to focus on the design and ignore the content. Building this way is also great when the designer isn't familiar with the data structures for a particular design.
Field name | Type | DescriptionAddrewtext |
Address | geographic address | Address in the San Francisco Bay Area |
Attachment | file | Sample pdf file |
Background picture | image | Sample image |
Cover photo | image | Another sample image |
text | Sample email | |
First | text | First name of a person |
Last | text | Last name of a person |
Long description | text | Paragraph-length text |
Number of likes | number | Number larger than 0 |
Number of stars | number | Number between 1 and 5 |
Order | number | Integer used to order how these Dummy objects are displayed |
Phone number | number | Number with 10 digits |
Price | number | Integer used for testing price displays |
Profile picture | image | Image of a person (or dog) |
Regular picture | image | Another image |
Short description | text | A sentence-length text |
Title | text | 1-3 word text |
Feature backlog
This data type represents each feature that an App admin has added into the Backlog section of the Owner's Portal.
Homepage block template
The data type is used for the homepage maker. App admin can add any number of homepage blocks / homepage sections straight from the Admin portal by starting from a homepage block template.
Homepage block
App admins can add an unlimited number of homepage blocks. They can control the content and settings from the Admin portal.
Palette color
This data type is color palette list is referenced in the Air Color Picker plugin / element. Feel free to add more color entries for quick access when using the Air Color Picker element.
Push token
We use this data type for push notifications when we turn your app into a native mobile iOS or Android app.
User
The user data type represents each person who has an account in your application.
Field name | Type | Description |
Date agreed to terms and privacy docs | date | Date agreed to terms and privacy docs during sign up |
Inactive | yes / no | User is marked as inactive = yes when App owner deletes the user from the Owner's Portal |
Last login | date | Captures the last date that the user loaded any page in the app |
Signup method | text | E.g., E-mail, LinkedIn, Facebook, Twitter, or etc. |
Pending email verification | email verification | Current user's email verification (this will be deleted from the user once the user verifies his email) |
Website
This data type includes fields for all app-wide settings. Most of the data fields are controlled by the App admin from the Admin portal. There should only be a single object of this data type.
Field name | Type | Description |
Ask for cookies? | yes / no | App Owner can control whether or not to ask users to accept cookies (if yes, a cookies banner will show on the homepage) |
text | Contact / support email that all emails in the application come from. Whenever a new email action is created in the application, it should refer to this field instead of being hardcoded | |
Email HTML | text | Used in the SendGrid API call for "send emails" that generates a nicely-formatted HTML email |
Email verification required? | yes / no | App owner can control whether or not to require users to verify their emails during the sign up process (if yes, users will receive an email that contains a verification link and they will need to click the link to verify their emails) |
List of blocks | List of homepage blocks | Homepage blocks / sections |
Name | text | Name of your app / website. This is the field that should be referenced anywhere where the name is used (instead of hardcoded). |
Primary color | text | App and email template primary color |
Usersnap off? | yes / no | This turns off the Usersnap tool, which AirDev uses with its clients to submit feedback and bug reports. |
Last updated