The Application Editor, which is what you use to build your app, is structured around seven key tabs and their sections, which are described here.
This is where you design the visual appearance of the app. Draw elements on the page, drag and resize them, and adjust their properties and appearance. For new users, we recommend starting here. To add a new element, click an element type in the Palette on the left, then click and drag on the page to insert it. Double-clicking on an element reveals the Property Editor, where you can customize the element's appearance and behavior. Right-clicking on an element displays a drop-down menu with additional editing options.
For more information to get started, see the "Building a user interface" guide.
The UI Builder subtab is where you can add new elements to the page and modify any existing elements. Bubble is generally a "what you see is what you get" (WYSIWYG) editing experience - whatever you create in this tab is generally what an end-user of your app will see, though there are many features to help you design your app exactly how you want it.
Your app can have multiple pages, and in fact comes by default with a few pages: the 404 page which end-users see if they visit a URL on your app that doesn't exist, and the reset_pw page which end-users use to reset their passwords. You can create new pages or switch to editing other pages (or reusable elements) via the dropdown in the upper left, in the top bar.
The elements tree shows all the elements that currently exist on the page. Indentation signifies a relationship between a container and the contents of that container - remember that there can be multiple levels of nesting (e.g. groups within groups within ...).
The top-down ordering of the elements tree corresponds to the vertical positioning of elements on the page (note: not the z-ordering). Greyed out items in the list are currently hidden; you can click on these in the elements tree to make them visible and select them.
Below the elements tree is the palette of all elements that you have access to for building your app. Bubble comes with many built-in element choices; you can also gain access to new elements via plugins.
The element palette is divided into a couple of sections for organization. Visual elements are ones that generally simply display something on the page. Container elements are elements that can contain other elements, including other containers. Input form elements generally allow the end-user to provide some kind of input, whether it be text, files, or something else.
Below that is the section of reusable elements available in the app. And at the bottom is a section of two special element templates: tab element and signup login form, which are two common user interfaces that might be helpful in your app.
You can switch the Design tab to the Responsive sub-tab. This is where you control the responsive settings of the page and all the elements within. Responsive settings refer to the configuration of how the page is displayed on varying screen widths - how the layout 'responds' to changing widths.
At the top of the left flyout of this sub-tab, there are shortcuts to snap the page width to different common screen widths, e.g. mobile portrait, mobile landscape, tablet and laptop. You can also change the page width to any arbitrary width using the ruler at the top.
This is where you define what happens when users interact with the app. For each action the user makes, e.g., clicking an element, typing text, logging in or out, you build a sequence of responses that react to what the user does. Actions can modify data, interact with the outside world via emails or calls to outside services, or modify the appearance of the page.
For more information to get started, see the "Building workflows" guide.
The Data Tab manages the data that users create when using the app. It is where you configure and see the data within your app's database. It consists of a number of sub-tabs.
For more information to get started, see the "Working with data" guide.
This sub-tab is where you define the data types that your app has - the kinds of things that you want to store data about in your database. The list of existing data types is listed on the left, along with a place to create a new data type. When a data type is selected, its fields are shown on the right side, along with the ability to create a new field on that data type.
This sub-tab is where you define rules around which users can see different kinds of data, or under which situations a user can see the data. Privacy rules are very important for the data privacy of your app! By default, new data types are generally visible to all end-users, so it's important to set privacy rules before you begin handling real end-user data.
For more information to get started, see the "Protecting data" article.
This sub-tab shows you the data in your app's database. You view the data by data type, and you can create custom views of a data type to show a specific set of fields as columns, a filtered subset of data, sorted data, etc. Note that the development and live versions of your app have separate databases, so you need to switch between them in the upper right in order to see the respective data. You can also create, modify or delete specific things (rows) in the database, or do bulk upload, export or modify actions.
Option sets are lists of a given set of options that are defined by you for use throughout your app. Examples would include things like a pre-defined list of statuses that tasks can go through, a list of all countries in the world, types of user privilege levels, etc. Unlike data, the options in an option set cannot be added to, deleted or modified by an end-user - they are defined as part of the app. This sub-tab is where you manage your option sets: which sets exist, the specific options in a set, and any additional attributes you've created on a set.
You and, if you build your app to facilitate this, your end-users can upload files to the app's database. These are stored separately from the defined data types or option sets, and can be seen in this sub-tab. You can also manage various aspects of any uploaded files here.
The Styles Tab manages collections of visual properties that are shared across elements in the app. Styles make it easy to maintain and modify a consistent visual identity. Rather than setting the font, background, and border for each element, define a style and apply it to all the elements of a given type. Bubble includes some built-in themes to help you get started. Use these to completely restyle the app. We integrate some popular themes from across the web, such as Bootstrap and Material Design.
For more information to get started, see the "Using Styles" article.
The Plugins Tab extends the functionality of Bubble by installing and configuring plugins. Plugins add additional elements, events, actions, and data sources. These plugins are created by the Bubble Team and other Bubble users, and there are both free and paid plugins. Most external services connecting to the app, including payment providers such as Stripe, analytics providers such as Mixpanel and Google Analytics, and social networks such as Facebook, are packaged as plugins.
You can see the gallery of available plugins with the "+ Add plugins" button. Any plugins already installed in the app are shown in the left column of this sub-tab. Clicking on a particular installed plugin will show any configuration settings of that plugin in the right section, along with an opportunity for you to leave a rating of that plugin for others in the marketplace to see.
For more information to get started, see the "Using plugins" guide.
Many plugins will be updated over time by their creators. If you have a plugin installed in your app, new versions of that plugin do not immediately take effect for your app; this is because new versions might have changes that would break older functionality that your app may rely on. Instead, you will see the option to change the version of the plugin in the Plugins tab, on the details of that particular plugin. This allows you to change to a different version in development mode, assess and fix any issues caused by the update as needed, and then deploy to live. Note that similarly, you can also choose to move to an older version of the plugin, though there is no guarantee the older version will be available to revert to forever.
Clicking this button will open the plugin marketplace, where you can browse, install and subscribe to plugins in the Bubble ecosystem.
Plugins can extend various functionality of your Bubble app; these varying kinds of functionality are categorized in the "Types" filter. For example, "Action" refers to plugins that add new workflow action choices, while "Login service" is where you'd find plugins that let your end-users log in with an external website (e.g. "log in with Facebook"). A plugin can be categorized under varying types.
Categories are different use cases and themes that plugins are categorized by. The plugin author self-selects which category/ies to be listed under.
The Bubble ecosystem has free as well as paid ("premium") plugins. For paid plugins, sometimes you will have the choice of paying a one-time price, or subscribing to the plugin for a monthly recurring price. Remember that plugins are installed and purchased on a per-app basis.
We at Bubble have created a number of plugins to provide useful functionality to apps. Our ecosystem of Bubble users and developers have created even more plugins to help you!
Practically speaking, if you find a bug with a Bubble-built plugin, the Bubble team will triage and respond to you about it. If you find a bug with an ecosystem-built plugin, you should reach out to the plugin's creator with information about the bug.
The plugin gallery can be sorted by a number of different dimensions to help you more easily find plugins. You can sort by the plugin's name, usage (# of apps it's installed on), rating, publishing date, or price.
The Settings Tab is where you perform administrative tasks. For example, controlling who can edit the app, setting app-wide appearance settings, such as a color palette or an icon, configuring the domain name, managing languages and translations, controlling SEO behavior, and configuring the API. There are a number of sub-tabs with controls over different aspects of the app.
For further detail about each setting, see the "Application settings" guide.
This is where you see which Bubble app plan your current app is on. Remember that Bubble plans generally apply at the app, not the user, level. In this sub-tab, you can see some of the capabilities of your current plan and change your plan as desired.
On the App Plan tab, you'll see information about which credit card is on file for your Bubble account; this is the payment method that will be charged for any changes. You will also see information about any active coupons / discounts on your account.
The App Plan tab will also show you information about paid plugins that are attached to this app. Remember that plugins are purchased on a per-app basis.
This sub-tab contains a mix of different settings - some design-oriented, some privacy-oriented, some app-level management oriented. Of particular note is that here is where you input Google API keys to allow geolocation and maps to work in your app.
See this article on how to set up your Google Maps and Geocode API Keys.
If you have your Google keys set up, your app will use those keys when making requests from Google Maps and Geocode. Google rate-limits these requests, and by default, you (the app creator) will receive an email from us when the application is being rate-limited. Checking this box will disable that email.
See this article on how to set up the integration between your app and Algolia.
Algolia has a default size limit for data fields that are sent to it. Bubble implements clipping correspondingly to help Bubble apps stay under that default size limit. However, advanced users may not want Bubble to do this for various reasons, and can use this setting to control that.
Over time, as many changes are made to your Bubble app, the application will remember information about parts of it that may no longer be relevant (e.g. a style that used to exist but no longer, or a data type that used to exist but has since been deleted). This tool in the General tab will help you clean some of that unused content out, which could improve performance of your app overall. Note that doing so will prevent you from certain actions, such as restoring a deleted data type, if you've cleared out the history of that deleted data type.
Similar to "Optimize application", this feature clears the saved history of changes to your app. If you're sure you no longer want this history (which powers features like reverting your app to a past point in time), you can clear it to improve app performance.
Bubble apps can be exported as a JSON file - please see this article.
If you have the JSON of a Bubble app (e.g. from exporting a Bubble app, see above), you can import it into the current app with this feature.
This sub-tab is where you control your app's custom domain. By default, apps come with a URL like myappname.bubbleapps.io, but if you've bought a domain that you want to use, like myappname.com, you can connect it to your app here. Along with that, you can also configure settings so that your app can send out emails at greater scale.
This sub-tab contains Bubble's feature to help you localize your app to different languages. Here, you see different "app texts" - snippets of text that appear throughout your app, some of which are built-in, others from plugins, and still others that you define. For any of these snippets, you have the opportunity to provide the translation of that snippet into any other language that Bubble supports out of our catalog of several dozen.
To facilitate changing many App Texts at once, you can import and export all the App Texts from one or more languages as a CSV. If you are planning to import, we recommend you first do an export to get the expected structure of the CSV file for the import.
Bubble has various features to help you improve the SEO ranking of your app. Although the content of your app is probably the most important factor in SEO ranking, there are a variety of technical requirements for SEO that Bubble can help with, many of which live in this sub-tab.
With this feature, you can upload a file and specify a file name, and Bubble will begin exposing that particular file at [yourappdomain].com/[filename]. This is necessary to accomplish certain things (e.g. to prove ownership of your domain for various other web services) and can also just provide convenient access to certain key files for your app or business.
No two files should have the same name. Also note that you must deploy your app for newly hosted files in your development version to also appear in your live version.
Bubble apps come with APIs, which allow your app to connect with other web services. This sub-tab is where you turn the app's APIs on or off, as well as control what's available through the APIs.
Once you've turned on at least one of your app's APIs, you have the option to generate a new API token. This is one of the ways a call to the API can be authenticated. See the API reference.
For each API token you choose to create, you are able to supply a custom label for it, which makes it easier for you to remember where each token is used, for example. Regardless, you will also see the private key itself.
On certain higher app plans, you can invite other Bubble users to collaborate with you on your app. This is where you can control who your collaborators are and what privileges they have on the app.
This is an advanced feature that lets you connect one app with another in a parent-child relationship, and changes to the parent can be 'pushed' to the child. See article.
When you first create a sub app, you have the option of copying the parent app's database to the sub app with this checkbox.
This section lets you push changes from a parent app to its sub apps. Please refer to this article to understand what does vs does not get pushed.
Bubble generally rolls out updates to the platform many times a day and there is no need for you to do anything in order to receive those updates. However, occasionally one of these updates will be a "breaking change" that could change the existing behavior of your app. For this subset of changes, you have to proactively apply that specific update, i.e. upgrade your Bubble version, which can be done in this sub-tab.
The Logs Tab monitors activity when users interact with the app. It shows the overall usage statistics, allowing you to keep an eye on your plan limits. It also allows to you view individual server-side workflow runs, so you can see when users modify data or take other server actions, such as sending an email. Finally, you can view and manually cancel scheduled future workflow runs.
This sub-tab shows you various data around your app's capacity usage. In other words, it shows the general activity of users on your app and the computing resources used by your app. If you suspect that your app is slower than expected because you are capacity-constrained (since each app plan comes with a certain level of capacity), this is where you can investigate that.
This section of the page shows you various metrics around your app's capacity. See article.
By default, Bubble will send you certain emails when we detect that capacity has hit certain thresholds. One option you have is "Do not send daily emails when the application hits its maximum capacity usage over the previous 24 hours" - this will suppress the corresponding email.
In addition, you can choose to "Only send emails when the maxed-out period exceeds this duration (minutes)".
This section of the page shows you a breakdown of what parts of your app are using capacity in a given time period. Note that you can click on sections of the chart to go into deeper levels of detail. Also note that the chart represents the % breakdown of what capacity was used on - so the chart will total 100% in periods of high and low capacity usage.
This section shows summary stats on how many workflows have run this month as well as how much file storage your app is using.
For workflow runs, note that the number does not include workflows that have run solely on the end-user's browser (on the client).
This section shows various metrics relating to pages of your app being loaded, including data that shows how much data is being loaded on those pages.
There are logs for many kinds of activities performed by your app or end-users on your app - these are called server logs and can be accessed in this sub-app. You can search through your server logs by time window and by categories of logs; this is great for debugging your app.
There are various types of logs that you can toggle for this search:
Started running workflow - This marks the beginning of a workflow executing
Event condition passed - The event condition evaluated to true (or wasn't set), so Bubble is going to run the workflow
Event condition not passed - The event condition evaluated to false, so Bubble is going to end the workflow
Running action - Bubble is beginning to run a specific workflow action
Action condition failed - Bubble is ending the execution of a workflow action because the condition evaluation to false
Workflow error - The workflow stopped running because of an error
Autobinding operation - A user modified data by editing an input that uses autobinding
Plugin server side output - A server-side plugin action ran; this is the raw output, for use in debugging
Plugin server side error - A server-side plugin action failed with an error; this is the error, for use in debugging
Scheduled task to run - Bubble scheduled a task to be executed at a future point in time
Scheduled task completed - A scheduled task that was running finished execution
HTTP request - The app made an outbound HTTP request to an external API
HTTP response - An outbound HTTP request the app made completed with the given response
Request for API workflow - An API endpoint in our workflow API was called
Sending email failed - Bubble was unable to send an email because of an error
For each log entry, you will see a number of fields:
Name: the name of the item relevant to the log, which sometimes is what kind of log it is or the name of a specific workflow action, for example
Email: the email of the user associated with this log running, often the end-user causing the workflow / action to happen
ID: the unique ID of the user with the email above
Timestamp: when the log happened, in your local time
Message / properties: the body of the log, which gives information about that particular entry; the information available will depend on what kind of log it is
One feature of Bubble is the ability to set a workflow to run later at a certain time or on a recurring basis going into the future. You can see any such scheduled future workflows on this sub-tab.
Each result from the search represents a scheduled workflow that will run in the future. For each result, you see the following information:
Scheduled time: when the workflow will run, represented in your local time
ID: the ID of this scheduled workflow, which you can use, for example, to cancel that scheduled workflow from another workflow
API event: the workflow that will run
Current user: generally signifies which user caused this workflow to be scheduled (may not map to the user whose permissions will be applied when the workflow runs, as that can be configured in the definition of the workflow itself)
Parameters: any parameters that workflow will run with, as expected in the definition of the workflow
This tab will only be visible if the current app was created from a template. If you use a template as a base, please write a review in the Template Tab. Reviews increase the quality of Bubble's templates.