Data types
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.
⚙️ App Settings
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 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) |
Name | text | Name of your app / website. This is the field that should be referenced anywhere where the name is used (instead of hardcoded). |
App primary color | text | App and email template primary color |
Usersnap off? | yes / no | This disables the Usersnap tool, which Airdev uses with its clients to submit feedback and bug reports. |
App Variables
This data type is specifically for setting up custom app-wide variables for your project. Simply add fields as need and reference them from your pages by accessing the var - app variables
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 |
Date signup completed | date | Date the user completed signup. This is populated upon sign up when the user signs up for an account by himself. If the user is invited to the app (e.g, app admin) then this is recorded when he first sets his password. |
Inactive | yes / no | User is marked as inactive = yes when app admin deletes the user from the admin 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. |
⚙️ Email Template
Email templates are managed from the admin portal and act as the main parent to manage email content for different scenarios
⚙️ Email Template Variant
The email template variant holds the email content for its parent Email template. When using multiple languages an email template will have multiple variants... one for each language.
Field name | Type | Description |
Email template | ⚙️ Email Template | Parent email template |
Is active? | yes/no | Sample pdf fileimage |
Language code | text | Language code for the language this variant represents |
Language name | text | Display name of the variants language |
Text body | text | Text to use as the body content for the email |
Text button | text | Button text |
Text signature | text | Text to include as the signature of the email |
Text subject | text | Text to add to the subject line of the email |
Used to verify a users email
⚙️ Header
We create one record for each header you create for your application
⚙️ Navigation Item
Contains all the code and metadata for an item such as a link, button, icon, etc that has been created for a footer or header element
⚙️ Verify
Stores the code data when a user is going through the verification process for their email, sms, or two-factor authentication.