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.
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 |
Website | If you have made a lot of changes to the app settings in the development version it may be easier to simply copy the website 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. |
Email Template | 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 from the same version (and copy to the other) to avoid content conflicts with your email templates. |
Marketing Page & Navigation Link | It's a best practice when using the Canvas Page builder to create and and update your marketing pages in the development version and then copy the data to your live site. Since Marketing pages & Navigation links require the other data type to function properly, any time data from one of these data types is copied to another database, data from the other data type should be copied as well. |
Palette Color | Palette colors are a standalone data type and can be copied from one version to the other with little impact to the application |
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. |
Email Verification Request | 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. |
Dummy | Dummy data is used to populate default content for Canvas blocks when they are first added. When an app is pushed live these blocks should have been customized to display content specific to your application. It's unlikely you would need to copy the Dummy data from development to live. |
How the Website data type is being used
There should only ever be one Website entry. More than one website entry will break the Canvas Template.
Every Canvas template will have a Website data type that is used to manage all app-wide settings such as colors, app name, contact information, etc. Almost all data for the Website object is controlled from within the Admin portal.
While you can add additional fields to the website 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 - Website object' with the type of content set to Website. The data source then is a 'Search for Websites: first item'.
With this variable set up, anywhere you need to reference the Website object on the page (e.g. the app name), rather than doing a search for the website object you can simply reference 'var - Website object's website' 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.
Last updated
