Skip to main content
Action step functionality

This article describes the functionality of native action steps (application functions) presented on the Betty Blocks platform.

Updated this week

Each time you build your action flow, it will consist of event sequences called action steps. These steps determine the action’s roadmap and they are divided into categories: Authentication, CRUD, Debugging, External, Flow, and Miscellaneous. In this article, we are going to review the functionality of each action step given to a user out of the box.

The Authentication step enables end-users of your application to log in and execute private actions. Usually, it is applied when a user needs access to some specific functionality in an application.

The Authentication step can be configured with the following options:

  • Authentication profile. Here you can add currently supported authentication profiles. See the Authentication profiles page for more information.

  • Based on the chosen authentication profile, the builder can configure the inputs for the profile:

    • User name and password: the variables containing the username and password which will be used to authenticate the end-user. Shown if the builder chose to use the username/password authentication profile.

    • Password: the variable containing the password of the user to be authenticated. Shown if the builder chose the custom authentication profile.

  • As. State the name of the variable containing the result of the authentication execution.

Using this step, you can create new records in a database and assign values to their properties with static values, or dynamic variables.

The Create record step can be configured using the following options:

  • Model. A model to create a new record in.

    • Value mapping: The builder can map values, static (filling them in manually) or dynamic (using a variable), to the properties of the chosen model.

  • As: The name used to define the variable created in this step. You can reuse the same variable in your next steps.

With this step, you can update an existing record in the database by assigning values to an object's properties and relations.

The Update record step can be configured using the following options:

  • Record: Set a record to be updated. The builder can choose a record using the variable picker that contains all available record variables in the particular scope. For more information see the Variables article.

    • Value mapping: The builder can map values, static (filling them in manually) or dynamic (using a variable), to the properties of the chosen record. The provided values will overwrite the existing values of the chosen record.

As: The name used to define the variable updated in this step. You can reuse the same variable in your next steps.

The chosen record gets deleted from the database when this step is executed.

The Delete record step can be configured using the following options:

  • Record: Set a record to be deleted. The builder can choose a record using the variable picker that contains all available record variables in the current scope.

  • Result: The name of the variable you want the record to have after being deleted in this step.

This step sets a message for debugging purposes. The message is delivered to the application logs.

The Log message step can be configured using the following option:

  • Severity: When setting up the Log message, you can specify the log severity by choosing Debug, Info, Warning, and Error types to categorize and track the information reflected in the logs.

  • Variables: Select all the variables you want to log in an application log.

The results will be visible in your application Logs, accessible via the Tools section on the builder bar.

With the HTTP(s) step, you can perform a request to an external web service. It will enable you to connect to a REST API, for example.

The HTTP(S) step can be configured using the following options:

  • Method: Indicates the desired action to be performed for the given external resource. Supported methods are GET, POST, PUT, and DELETE.

  • Headers: Key-value pairs that allow sending additional information to the external service. Headers are often used in authentication to the external service.

  • Protocol: An external service uses a protocol for communication. Supported protocols are either HTTP or HTTPS (secured HTTP).

  • URL: The URL of the external web service you want to use.

  • URL parameters: They often define the actions that the caller wishes to perform. They are defined as optional key-value pairs. Mostly used in combination with the GET method.

  • Query parameters: Optional key-value pairs appended to the URL that provide additional information to the server. They are typically used to filter or modify the request in some way, such as specifying search criteria or pagination details

  • Body: Optional data which needs to be present for a successful request. Often required when performing a POST request

  • Body parameters: These are key-value pairs used within the body of the request. They map values that you want to use in the request body, often for creating or updating resources on the server.

  • Schema model: Used to type the output of this step when it is an object or array of objects.

  • As: The name of the variable containing the response from the external service. Here you can specify the format of the output, which can be Text, Object, or Array.

Loop is responsible for executing one or multiple action steps continuously as long as a specified condition is true. Currently, the only supported condition is iterating over all elements in a collection.

The Loop step can be configured using the following options:

  • Collection: The builder can choose a сollection of records over which he wants to iterate. For every element in that collection, new action steps can be executed.

  • Iterator name: The name of a variable containing the record of this particular iteration. The value of this variable will be replaced with the record of every new iteration.

  • Index: The name of the variable containing a numeric value that indicates the counter of performed iterations. The first record in the collection is located at index 1, the second at index 2, etc.

This action step allows you to store files using a provided URL or configuration variable. This functionality is particularly useful when you need to save files from external sources directly into your application’s storage.

  • Model: The model containing the property where the reference to the stored file will be saved

  • Property: The specific property of the chosen model where the file reference will be stored. This property must be designated to handle file references

  • URL: The URL of the externally hosted file to be stored. Only HTTP and HTTPS URLs are supported

Condition flow changes the way action flow is executed, this comes down to the way a condition step works fundamentally. The Condition step evaluates a variable and based on the given criteria it returns a true or false value. Based on the value, your action continues its flow.

  • Paths: Select the variable to check if the first value is ‘True’ (this name can be changed). For example, it could be a checkbox variable and if it is checked by a user, the first (true) flow is executed. If the above criteria are not met (checkbox left unchecked), then the last (else) path will be executed, which can also be named in your own way.

Variables tab

Each action step has a Variables tab that allows you to add more variables to the step. These variables can be used for dynamic value mapping, which is particularly useful when the values that need to be assigned depend on other variables or calculations within your application. By leveraging this feature, you can ensure that your action steps are more flexible and can adapt to varying inputs and conditions.

More about Variables

Did this answer your question?