Actions

Actions are the things that makes stuff happen in your app. They are the the part of a workflow that performs a specific task, such as making a change in the database, hiding/showing/animating something on the page or navigating to a different page.

Actions happen as the result of an event, and together, they make up the workflow.

Events determine when to do something, and actions determine what to do

Actions can be chained together to perform a set of tasks in sequence, and each step can rely on information generated in a previous step. Each step can also be controlled with a dynamic expression that controls whether to run or skip that step, based on specific conditions.

Working with actions

In the Bubble workflow editor, actions are visible as soon as you create or open a workflow from the sidebar.

Creating actions

To add the first action to a workflow, click the + symbol underneath the event. You will see a list of actions separated into categories.

As soon as you add or click an action, Bubble will show you the settings for that action. Below is an example from the Make changes to a thing action:

The Thing to change specifies the data source of the thing you want to change. After selecting it, Bubble will display the available fields on that data type. In the example above we change the name of the user by providing a static text value.

Setting conditions for running an action step

A workflow can consist of as many steps as you need, but sometimes you'll need to set some rules that determine whether one of those steps should execute or not. For example, you could have a workflow that requires the user to be logged in in order to run; if they are not, you can show an error message.

For this, you use the only when field: as the name suggests, this tells Bubble to only run this action when... a condition is true. Conditions are dynamic expressions that provide a yes or no value, depending on a given set of factors.

The order in which actions are triggered

The points below offer insights into Bubble's workflow logic along with some general recommendations. It is worth mentioning that the terms "steps" and "actions" are used interchangeably, although in the given examples, "steps" are used when the order is significant.

For efficiency purposes, workflows run in parallel across the server and the front end. Despite the names "Step 1," "Step 2," it is important to note that a given step does not necessarily wait for the previous one to complete before triggering the next one. The following is some information about Bubble workflow logic and general recommendations. Please also note that steps and actions are used interchangeably, but steps may be used in these examples when the order is important to note.

General rules about how workflows run:

• Frontend workflow actions run in order but the next action does not wait on the previous action to be complete before triggering.

• Backend workflows are triggered as soon as the workflow is triggered, independently from steps. For example, a "Schedule API Workflow" action will be triggered as soon as the workflow is triggered even if it is placed last in the workflow action sequence.

• Custom events run in sequence, not parallel. If Workflow 1 triggers a custom event that starts Workflow 2, Workflow 2 will complete before the remaining actions in Workflow 1 run.

• Searches aren’t always immediately updated with new data. So if you create a new item, and then try to retrieve it via search, it may or may not work; you should not rely on this.

  • Retrieving a thing from “result of step X” where step X is the “Create…” step should always be safe.

Workarounds to help achieve workflow consistency:

• When a workflow trigger (e.g. a button) can have multiple results based on conditions, it is safer to create multiple workflows and place the conditions at the workflow level instead of creating one workflow with all possible actions and placing the conditions at the action level.

• In a workflow with two actions, if Step 2 is using a condition based on a search depending on data manipulated in Step 1, then Step 1 should be implemented into a custom event to make sure it is finished before moving on to Step 2.

• If a backend workflow should be triggered after other steps in the workflow, then it should be implemented in a custom event placed after the steps that need to come first.

• The safest way to use data from one step to another is to use the “Result of step X” operators instead of searches.

• We do not offer the explicit ability for an action to wait for a workflow to be over before moving on to the next step; however, using "add a pause before next action" action is usually an effective workaround.

Using data from a previous step

Sometimes an action needs to refer to an earlier step in the same workflow. If you do this by referring to it indirectly, there is a risk that the change you initiated has not yet had time to update and may not be reflected in the later step. Let's look at an example to illustrate this:

Let's say you are using the Make changes to a thing to save some information to a data type called Product. In a later step, you refer to that same product by the data source Result of step 1 and then that Product's name.

1. In this example we are first changing the name of the Product

2. And then we use the Set state of an element to save that name in a custom state

Native mobile actions

Navigation

Go to view

Stack

Stack navigation is a navigation pattern where users move through a “stack” of screens as they progress through your app. Take the Spotify app as an example: when you’re on a tab, such as Home or Your Library, and navigate to a playlist screen, you’re viewing a new screen while the original tab remains active. This is because the current view is “stacked” on top of the base view, which is the tab itself. To return to the base view, you simply tap the back arrow in the top left corner of the screen.

Reset navigation stack

When navigating to a new view, the original stack remains active, allowing users to return to it using the built-in back button or swipe gestures. If you want to prevent users from going back to the original view, you can use the Reset navigation stack option. This is useful in scenarios where you want to completely clear the navigation history.

For example, if a stack displays a login form and the user successfully logs in, you may not want them to navigate back to the login screen. Reset navigation stack ensures they start fresh from the new view.

Modal

Another way to navigate to a new view is to use a modal. A modal should be used when you want to provide a scoped experience to the user that requires the full screen. A good example of this is the new message modal in the iOS messages app. Since you don’t need the context of the messages view below, the modal takes up the full screen to allow you to craft your message, but also allows you to quickly return to your messages view.

To open a view as a modal, you’ll use the “Go to view” navigation workflow action but select Modal instead. This will open the target view as a modal sheet over the base view. While you can swipe down to close the modal, it's generally a good idea to include a button to close the modal in an app bar.

To add a close button, add an app bar to the view that will be opened as a modal and add a trailing button with a “Go to previous page” workflow action. This will close the modal when the user taps the button.

Go to tab

The Go to tab action functions similarly to the Go to view action, including the use of view properties. However, the target view must be associated with a tab. When navigating using the Go to tab action, the tab bar will automatically update to reflect the new tab

Set current view's property

The Set current view's property action lets you assign a value to a property on the current open view. To use the action, you need to first define one or more properties on the view.

Push notifications

Push notifications allow you to send real-time updates, reminders, or alerts directly to a user’s device, even when the app is not actively in use. Whether it’s a personalized message, a promotional offer, or a notification about app activity, push notifications help keep your users informed and connected with your app’s content.

These notifications leverage the native capabilities of iOS and Android devices, and provide a highly targeted way to reach your audience.

Push notifications require an active permission from users before they can be sent. You must request this permission before sending push notifications to users who have not explicitly approved them.

The devices data type

Using push notifications adds a new built-in data type to your app called devices. This data type contains key information about a user's device(s), and is used as a data source when sending push notifications.

The devices data type is read-only: you cannot rename it, any of its fields or add new fields. This data type is also automatically protected by a preconfigured privacy rule, since the push notification token is sensitive and should not be shared.

This devices data type is automatically added as a property on the user, meaning that you can access it with a dynamic expression such as:

Current User's devices

Do a search for:User's devices

Overriding the built-in privacy rule

The push notification token should be considered sensitive data, and should generally not be shared. If you need to share the taken outside of your Bubble app (such as sending a request to a third-party app or system), you can use a backend workflow and check Ignore privacy rules when running this workflow to circumvent the built-in privacy rule.

Requesting permission to send push notifications

Both iOS and Android require explicit user consent before sending push notifications. This permission is obtained using the Request push notification permissions action, which triggers the operating system’s standard notification request prompt. The prompt is system-generated and consistent across all apps, meaning it cannot be customized.

Sending push notifications

After the user has approved the permission request, you can start sending push notifications. To do this, set up an event in the workflow editor, and locate the Emails and notifications action category, and select the Send push notification action.

The Send push notification action comes with the following properties:

• Title: the main header

• Subtitle: the sub-header

• Body: the main message

• Devices: needs to be populated with the device data type from one or more users. If you are sending a push notification to the current user, you can use the dynamic expression described in the section above.

Your app icon will also be displayed in the push notification, and cannot be customized per notification. The properties above are used on both systems (iOS/Android) and the final result looks fairly similar on both device types.

Scheduling push notifications

Sometimes you'll want to send push notifications at a scheduled time. The Send push notification action is available in the backend workflow editor. To schedule a push notification, set up an API workflow and use the Schedule API workflow action.

Limitations

• Web preview: Push notifications cannot be tested in web preview mode.

• BubbleGo: Push notifications cannot be tested in the BubbleGo app.

• Deployment for testing: To test push notifications, your app must be deployed and uploaded to App Store Connect and added to TestFlight.

Location services

Native mobile apps has two actions related to location services. Click the links below to read more about each action:

• Get current location

• Request location permissions

Other ways to learn