# 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*](#user-content-fn-1)[^1]*,* 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 by clicking on an event.

Actions are contained within the workflow, and visible when you click an event. Click the image to enlarge.

### Creating actions To add the first action to a workflow, click the *Click here to add an action* rectangle. You will see a list of actions separated into categories. {% hint style="info" %} You can add new actions to use across your app by installing plugins or by adding API calls with the API Connector with *use as* set to *action.* \ Article: [The API Connector](https://manual.bubble.io/~/changes/lkknp2T2KBasv7RmhMhx/help-guides/integrations/api/the-api-connector) {% endhint %} 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*](#user-content-fn-2)[^2] action:
The *Thing to change* specifies the [data source](#user-content-fn-3)[^3] of the thing you want to change. After selecting it, Bubble will display the available fields[^4] on that [data type](#user-content-fn-5)[^5]. 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](#user-content-fn-6)[^6] that provide a *yes* or *no* value, depending on a given set of factors. {% hint style="info" %} This step relies on using **dynamic expressions** to set up **conditions** in order to determine whether to run a workflow or action. If you're not familiar with these concepts, we recommend first reading the articles below: Article: [Dynamic expressions](https://manual.bubble.io/~/changes/lkknp2T2KBasv7RmhMhx/help-guides/logic/dynamic-expressions) Article section: [Conditions](https://manual.bubble.io/~/changes/lkknp2T2KBasv7RmhMhx/help-guides/conditions#only-when-conditions-workflow-conditions) (only when) {% endhint %} ## The order in which actions are triggered {% hint style="warning" %} **Note:** Although a workflow is created as a linear set of actions, there is a lot going on behind-the-scenes when a workflow executes. This can sometimes lead to some steps firing before other, earlier steps in some cases. Some workflows run in the client's browser, while others (such as database operations) need to happen on Bubble's server. Some workflows will happen in both the browser and on the server. If a workflow includes a mix of actions from these three categories, the order in which they are triggered may differ from the linear design in the workflow because of what's firing in the browser versus the server. {% endhint %} 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.
Video lessons * [Understanding workflow execution rules](https://youtu.be/IbhCrciOKHM)
## Using data from a previous step {% embed url="" %} 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*](#user-content-fn-7)[^7] to save some information to a data type called *Product*. In a later step, you refer to that same product by using [*Do a search for*](#user-content-fn-8)[^8] and narrowing it down with the [*first item*](#user-content-fn-9)[^9] operator:
1. In this example we are first changing the name of the Product 2. And then we use the [*Set state of an element*](#user-content-fn-10)[^10] to save that name in a custom state In this case, there is a slight risk that the first operation (Make changes to a thing) has not yet had time to complete until the Do a search for finds and returns data; as such, the custom state could be saving the name of the thing *before* it was changed. To avoid this, you can use the [Result of step 1](#user-content-fn-11)[^11] data source. Not only do you not have to perform the search, but when you use this step, Bubble ensures that the operation done in Step 1 is completed before any later steps that rely on information from it are executed.
Video lessons * [How to use the *results of* data source in an expression](https://youtu.be/D3ks42piYww)
## Other ways to learn
Video lessons * [Understanding workflow execution rules](https://youtu.be/IbhCrciOKHM) * [How to use the *results of* data source in an expression](https://youtu.be/D3ks42piYww)
[^1]: An event is the trigger that initiates the running of one or more actions in a workflow, such as a button being clicked.\ \ Article: [Events](https://manual.bubble.io/~/changes/lkknp2T2KBasv7RmhMhx/help-guides/logic/workflows/events) [^2]: *Make changes to a thing* saves changes to a specific database record. Reference: [Make changes to a thing](https://manual.bubble.io/~/changes/lkknp2T2KBasv7RmhMhx/core-resources/actions/data-things#make-changes-to-thing...) [^3]: A data source is any place from which Bubble can retrieve data, such as the database, the current user or an external API.\ \ Article: Dynamic expressions [^4]: *Fields* are the areas on a data type where information is stored. You can create as many fields as you need on a data type, and you set a *type* for that field, such as text, number or image. Article: [Data types and fields](https://manual.bubble.io/~/changes/lkknp2T2KBasv7RmhMhx/help-guides/data/the-database/data-types-and-fields) [^5]: *Data types* are like containers that hold specific types of information and each data type is made up of fields where that information is stored. *User* is a built-in data type, but you could add custom types like *products*, *blog posts* or *sports teams* as needed. Article: [Data types and fields](https://manual.bubble.io/~/changes/lkknp2T2KBasv7RmhMhx/help-guides/data/the-database/data-types-and-fields) [^6]: Dynamic expressions are like "live" formulas that update in real-time based on user input, database updates and other changes in your app. [^7]: *Make changes to a thing* is an action that saves changes to a specific database thing, such as saving the name of a User, the text in a Blog post or the image of a Product. Article: [Creating, saving and deleting data](https://manual.bubble.io/~/changes/lkknp2T2KBasv7RmhMhx/help-guides/data/the-database/creating-saving-and-deleting-data) Reference: [Make changes to a thing](https://manual.bubble.io/~/changes/lkknp2T2KBasv7RmhMhx/core-resources/actions/data-things#make-changes-to-thing...) [^8]: *Do a search for* is a data source that searches your app's database and returns a list of records. It bases this search on *constraints*, such as searching for all users that have the first name "Jane" or "John". Article: [Finding data](https://manual.bubble.io/~/changes/lkknp2T2KBasv7RmhMhx/help-guides/data/the-database/finding-data) Reference: [Do a search for](https://manual.bubble.io/~/changes/lkknp2T2KBasv7RmhMhx/core-resources/data/data-sources#do-a-search-for) [^9]: *First item* is an operator that you can add to any list of things to return the first thing in that list. For example, if you search for a list of Users with *Do a search for*, you can add the *first item* operator to return the first user in the list. You can combine this with constraints and/or sorting to find the right thing.\ \ Reference: [First item operator](https://manual.bubble.io/~/changes/lkknp2T2KBasv7RmhMhx/core-resources/data/operations-and-comparisons#...-first-item) [^10]: *Set state of an element* is used to set the value of a custom state on an element. Custom states are like variables, where you can save information temporarily until it is updated/page is refreshed. Article: [Custom states](https://manual.bubble.io/~/changes/lkknp2T2KBasv7RmhMhx/help-guides/data/temporary-data/custom-states) Reference: [Set state of an element](https://manual.bubble.io/~/changes/lkknp2T2KBasv7RmhMhx/core-resources/actions/element#set-state-of-an-element) [^11]: The *Result of step X* data source is used to refer to something that was reference in an earlier step in a workflow. For example, if in Step 1 you make changes to a thing, you can refer to that thing in Step 2 by choosing *Result of step 1* as the data source.\ \ Reference: [Result of step x](https://manual.bubble.io/~/changes/lkknp2T2KBasv7RmhMhx/core-resources/data/data-sources#result-of-previous-step)