Data & Workflows
An overview of how data is used in the Canvas template
Copying development data to live
Canvas uses the database extensively to create a highly functional and dynamic application. While in development, all this data is being saved to the development database of your app.
It's important to remember that your Bubble app has two separate databases for the live and development versions. When deploying live the first time you will need to copy the development database to the live database for Canvas to have access to all the settings you have applied during development.
To do this, from the Bubble editor navigate to the Data tab, open App data, and then click on 'Copy and restore database' in the top right.
In the popup click the 'Copy development data into the live database' button, ensure 'Data type to copy' is set to All types, type 'COPY FROM DEVELOPMENT TO LIVE' in the input and press the Confirm button.
Be aware that copying the data from one version to the other will overwrite all information in the database to which you are copying data.
Copying specific data types
After your initial deployment to a live application you may find scenarios where you need to copy a specific data type from Live to Development or Development to Live. This is common especially with email templates and marketing pages where you make updates in development and need to have the new data copied directly to the live site.
To do this, you will follow the same steps as outlined above for copying the entire database. But instead of setting the 'Data type to copy' to All types, define the specific Data type you need to copy and then proceed as normal.
We have added a gear icon (⚙️) before all data types, and field names that are core to the Canvas template. In general, these elements should not be edited unless you understand the impact changes will have on the template.
Below is some guidance on when and how to copy Canvas data types from one database to the other.
Data type | Guidance and best practices |
⚙️ App Settings | If you have made a lot of changes to the app settings in the development version it may be easier to simply copy the app settings data over to the live version rather than duplicating all the changes manually. However, it is a best practice to update app settings directly in the live admin portal once your site has been deployed. |
⚙️ Header & ⚙️ Navigation item & ⚙️ Legal | It is important to always keep the header and navigation item data types in sync. Before initial deployment, we recommend creating or editing your header and navigation item in the development version and then copy those data types to your live site. After initial deployment, we recommend to not copy the header or navigation item data types from one version to the other. Instead, you should make any header or navigation related updates directly in your live site via the admin portal. Whether it is the live or development version, you should add and update these data types from the same version to avoid content conflicts with your headers and navigation items. |
⚙️ Email Template & ⚙️ Email Template Variant | Since email templates must be set up with their own custom workflows, adding a new template will require making and deploying workflow changes from the development version of your app. Whether it is the live or development version, you should add and update email templates and email template variants from the same version (and copy to the other) to avoid content conflicts with these data types. |
⚙️ Verify | Email verification request data is generated automatically and is only valid within the version it is created. You will never need to copy this data type. |
App variables | After the initial deployment, copying this data type from one version to the other will overwrite any existing app variables in the other version. |
User | After the initial deployment, it's not recommended to copy users from one version to the other as this will overwrite any users that have been added to the app in the other version. |
How the ⚙️ App Settings data type is being used
There should only ever be one ⚙️ App Settings entry. More than one ⚙️ App Settings entry will break the Canvas Template.
Every Canvas template will have a ⚙️ App Settings data type that is used to manage all app-wide settings such as colors, app name, contact information, etc. Almost all data for the ⚙️ App Settings object is controlled from within the Admin portal.
While you can add additional fields to the ⚙️ App Settings object as needed to customize your application, we recommend not changing the default fields in any way.
Using the hidden variables popup
Variable simply refers to the use of an element to hold one or more values. Instead of repeating these values in multiple places in your page or workflows, the variable holds the results of a calculation, a single thing from a database search, a list of things from a database search, or some other value and can be referenced multiple times from other page elements and actions.
Each page has a popup called 'Popup Hidden Variables' designed to hold app data as variables for easy reference.
As an example, each page has a group element in this popup called 'var - ⚙️ app settings' with the type of content set to ⚙️ App Settings. The data source then is a 'Search for ⚙️ App Settings: first item'.
With this variable set up, anywhere you need to reference the ⚙️ App Settings on the page (e.g. the app name), rather than doing a search for the ⚙️ App Settings object you can simply reference 'var - ⚙️ app settings object's app setting' instead. This keeps your data organization clean and concise on the page.
Any data that is referenced from multiple elements or actions on the same page should be stored in a variable group in this popup to avoid redundancy in retrieving data. This helps minimize the possibility of error when searches are duplicated across elements. It also makes it much simpler to update any search parameters as the search only needs to be changed in one location.
Types of Variables
Variables are stored in two kinds of elements: Groups and Repeating Groups. These elements are often more useful than custom states because they can have default data sources, conditional data sources, or have their data set by a workflow. A custom state's data can only be set by a workflow.
It is good practice to name each Group or RG with a naming convention of var - [Name of variable] as opposed to the normal 'Group..." convention. This allows you to quickly search for the page variables using the 'var' prefix.
GROUPS Groups are used to store single item variables such as a number, text, or single Thing from the database.
REPEATING GROUPS Repeating groups are used to store list variables such as a list of numbers, list of texts, list of Things, etc.
When using a Repeating Group as a list variable, use the Vertical scrolling layout style to allow your page to only load the data that is needed to display in the current page view.
Using the inclusive Yes/No option set
When filtering data by the yes/no field type in Bubble, you can only return values that are either Yes or No. For instance:
The inclusive yes/no option set allows you to create search parameters based on the yes/no field type in Bubble and return all things with a value of 'Yes' OR 'No', a value of only 'Yes', or a value of only 'No'. For instance:
The enable this we've added a list of yes/no values as an attribute to the Options in the Yes/No Option set.
For the Yes value we add only the 'yes' value to this list.
For the No value we add only the 'no' value to this list.
For the Yes or No value we add both the 'yes' and 'no' values to this list
The search logic then is to check, not if the value is EQUAL TO the Yes/no values, but if the value IS IN the Yes/no values.
To see how we use this in Canvas, check out the dropdown to filter users by active status on the admin page of your app. It can be found in the elements tree by clicking the '+' to open Group Main Content > Group Nav 8 - Users > Group User header > Dropdown Users.
