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. More steps will be added to the actions over time.
Authenticate user
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 is able to 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.
Record ID: the variable containing a record ID 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.
Create record
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.
Update record
With this step, you can update an existing record in the database by assigning values to an object's properties and relations. Property values of the record can be updated using static values or dynamically, using variables.
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.
Delete record
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.
Log message
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:
Message: The builder can either choose to insert static text here or choose a variable from the scope of the particular step. Its value will then be logged into the application logs.
HTTP(S)
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:
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.
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.
Query parameters: Query parameters are extensions of the URL. 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.
Body: Optional data which needs to be present for a successful request. Often required when performing a POST request
As: The name of the variable containing the response from the external service.
Loop
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.
Store file
This step uploads (and stores) a file to the asset store. The file is uploaded using a provided URL. A reference to the file in the asset store is returned as the result of this step, which in turn can be used in a create or update step. In the example below, we assign this image to a user record.
Model: Contains the property which we use to save the reference to the downloaded file.
Property: The property of the chosen model to which we want to save the reference to the downloaded file.
URL: A URL to an externally hosted file (currently only supports HTTP(s)) which we store in our local model and the asset store.
As: The name of the variable containing the reference to the stored files in the asset store.
Note: In order to actually store this file reference in the property of a model, a create or update step has to be used. The model and property options in the upload file step are used to perform validations on file type and size. The file cannot be stored in any other property or Model. The reference returned is tied to this combination of model and property.
Condition step
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: Create a new variable to be used inside this step.
As mentioned previously, these are the only action steps we can offer within the renewed actions section. We are currently working on creating others so that you will be able to get full experience creating your applications with fresh Betty Blocks toolings very soon.
➝ Next article: Variables