• What an action is.

  • Which two types of actions can exist in your app.

  • What the visual action editor is.

  • What action events and triggers are.

Actions are your app logic, defined in literal actions.

Actions can do just about anything you want in your app. You can create an entire workflow by adding action events to your action, each handling their own tiny step of the flow. You can choose between 27 different action events to add to your action, going from a create or update event to http requests (web services) or Pdf generates.

Two types

There are basically two places where you can create actions. 


The action button in the builder bar brings you to the back-end actions overview. Here you can create all your actions that are model-based. This means most of the time they are processing records from your database. If you want to start actions from the back-office or call upon these action from other actions, this is the way to go! 


You can also create an action on a web page (endpoint). These actions are only visible/editable on the endpoint itself, they will not show in the actions overview. The actions you define on an endpoint are always and only executed when the endpoint is called upon. These actions are executed before rendering the template. Avoid creating huge actions on endpoints to prevent long loading times.

Visual Action Editor

Building processes or creating workflows can be pretty complicated when done traditionally, especially when multiple workflows are part of a bigger system. At Betty Blocks we aim to make it as easy and intuitive as possible. That's why we created our Visual Action Editor.

The Visual Action Editor is where all the functionalities are defined through events. As you open the editor, you'll see a Start marker and an End marker. All events between them make up your action. Add them by clicking the  Logically, the first event is executed first, the second event second, and so forth. As every event has their own purpose, some affect the flow of your action. These are distinguished by their colors and shape. 

White: Normal events. These blocks are most seen of all. It means the event is executed once when called upon. All CRUD, Web page, Property- and User-based and External action events are shown with this block.

Yellow: Condition events. To be or not to be, that is the condition. In a Condition event, you can define a condition with a filter or expression, using variables and logic from our expression reference. As you can see in the image above, it has a green check mark and red cross mark. They make up the true and false flow. When the condition evaluates as true, it follows the green path. When the condition evaluates as false, it follows the red path. This is The condition flow closes with the tiny yellow block as the lines come together again. In each flow, events can be added by clicking the + marker. 

Note: Variables defined within the condition flow can't be used outside. An action can't go through the false flow, while at a later point a variable from the true flow is used.

Green: Group events. This event is used for splitting collections and using the results for further processing. For example; you have a collection of Activities, each related to an Employee. You want to send each Employee one email. By selecting the Activities collection in the group event and grouping on Employee, you'll get multiple Activities collections, one for each Employee. Keep in mind to set the Key option, as it makes the value which is grouped on available. Notice how the arrows move; after the Group iteration closes, the arrow goes up again and will repeat until all collections have been processed.

Blue: Loop events. This one has similarities to Group events but is actually a bit simpler to use. Select a collection and loop through each object. Each iteration handles an object from the collection. The As variable from the loop event makes the current object available. That means in every iteration, this variable contains a different value/object.


As you now know the basics of these different events and what they do, here's an example of how these events cooperate. First off, we've created a collection called activities. Let's group these activities on Employee and check whether the Employee has a specific role and if all the employee's activities are ready for approvement. If true, loop through these activities and update each activity with status 'Approved'. If false, send an email to the employee stating they need to get their act together and get to work! 

Action References.

To teach you everything about actions, we’ve made different references, each explaining its own subject. The action reference will teach you all about the different settings and options when creating an action. Ranging from the model to execute the action on to adding variables.

The action event reference will tell you all about the different action events: what they are, what they do and how to use them. Please check them out!

A trigger defines the moment your action initiates. If you want to have a button which a user has to click in order to execute the action, you’ll have to set the trigger to Manual, but if you want an action to execute whenever a new record is created you can set the trigger to After create. Detailed information about Action Triggers can be found in the action trigger reference.

Did this answer your question?