Home > Help center > Eventor > Management - Eventor - The Eventor Flow

Management - Eventor - The Eventor Flow

The Flow itself is the main goal of the Eventor software and where automatic system actions are created. Creating an Eventor Flow is a task that includes the involvement of system Events and Listeners. For more general information on system Events and Listeners, please click here.

How Eventor Flows work

Eventor Flows are designed to function automatically in the system. They are basically responses to certain system events - how the system should act and what it has to do if a certain action occurs.

A Flow is comprised of an Event, which specifies the system action to which that Flow will be reacting, and a Listener, which carries out the actual system action of the Flow. These system flows may additionally require specific system information depending on the event that triggered them and the Listener that would be attached as a functionality. This is where the core logic of the Eventor manifests itself. In order to best understand it, the defining features of an Event and a Listener need to be mentioned here, as well:

  1. Events - represent single system actions, each of which returns a certain set of data, such as user ID, product category, etc. These variables are directly relevant to the action.
  2. Listeners - represent the possible functionalities for the Events once they are set as a part of a Flow. Each Listener has certain conditions, that need to be met by the Administrator (whoever is setting up the flow) in order for that Listener to be successfully executed.

In order for а Flow to work completely and properly, it may require additional information to serve as details for the Listener. These are parameters that the system has to provide and are manually selected during the Flow setup. They depend on the Event's initial resources. It is important to note what data various event resources return, and what data the function needs to carry itself out in the best possible way.

Eventor Flows do not work with predefined parameters for each event; that would mean limitation of the software capabilities. Instead, the Eventor makes sure to obtain the needed variables by finding a chain of related resources. After that path is charted, the software can then access the needed data and the Flow can be successfully configured.

Flow Details - Parameters

An important part of the Eventor Flow is the choice of system parameters. This is done with the purpose to create the Flow as detailed as possible, provide more information for the Listener to operate, and precisely configure the system as to which data to gather and how to obtain it. The Parameters section basically assists with the general adequacy of the entire process. Choose parameters for the system to include/consider in the Eventor Flow, and also provide the logical system path to them.

step two of creating an eventor flow

The Parameters represent all possible factors in the system, categorized in logical groups and relations to one another, i.e. each parameter has a relation to another parameter from a different category, or an entire category. This way they are all connected to one another, but at the same time the system needs to go through all connected relations in a certain sequence in order to reach a certain parameter. These relations are represented with yellow strings.

On the top the system displays Step 1 being completed (the choice of an Event, Listener and details) and next to it what is required out of Step 2 (choosing parameters). The Parameters themselves are afterwards displayed below. The Parameter logical groups are set in columns and divided in levels. The layout displays the initial resources of the Event chosen for the Flow, located to the left of the screen. These parameters from the chosen Event's category are by default selected as parameters for the Flow. The relations from it follow the direction to the right side. The further to the right a Category is, the more connections/relations the system has to go through to reach it, or a resource from it. Nevertheless, this method allows the system to obtain almost any data/parameter requested to complete an automated Eventor Flow.

Note: Certain Parameters' and Parameter Categories' information could be obtained through more than one path. Each Category can lead to various resource groups, some of which may already be present through a different Category path. In these cases, it is best to check the Category closest to the initial resource group of the selected Event. This action will automatically check the shortest relations path to it and the associated relation categories on that path. Additionally, selecting one Parameter Category will select all the data in it, no matter how much from it is needed.

Tip: Knowing which parameters to choose when designing the Eventor Flow is a tricky task. The one creating the Flow needs to be very aware of the configuration of their system, its backend, and hence - all possible resources and logical Parameter groups. The logic remains constant and with the more experience, confidence and ease will become part of the creation of Eventor Flows. For more information, please click here**.

To best try and make this process easier, here is an important question which the creator of a Flow can explore in order to find out the best Parameters for the situation:

What information does the Listener require to best and most adequately perform?

Example: If the Listener is "MailToUser", it is designed to use data to send as an email to the customer during certain events. In that case it needs a way to receive that data by the system. Data such as: user's email address, where the email would be send to, the user's first and last names, so that the beginning of the email addresses the user, information about the topic of the email, if it is a product purchase, refund, etc. At the same time, by default, all of those parameters are already in relation and topical to the initial variables of the associated event.

Choosing Parameters

In order to choose certain parameters, the entire category needs to be selected in the available checkbox, no matter if only one resource is needed frоm that group. Even if the parameter needed is on a deeper category level, the system will automatically include all previous categories from the relation and their data. Additionally, on specific categories, various conditions can be assigned, in the form of variable rules called "relation filters".

Control buttonDefinitionDetail
Alternative textScroll sideways- If there are too many parameter categories in the relation sequences, they will be displayed next to each other and this control to scroll the screen sideways will be available.
Alternative textBack- Go back to the previous step of the Flow setup process without losing progress data.
Alternative textNext- Continue to the next step of the Flow setup process.
Alternative text Alternative textSelect/Deselect Parameter- Choose the parameter category which holds the desired parameter(s).
Alternative textConditions- The Relation Filter sets conditions for the variables. This means that during the setup of the Eventor Flow, the parameters that are chosen can be specified to have, or not have, certain characteristics. E.g. - gather data for all products in the system, except such added after a certain date.

Entity vs. Collection

The parameter logical groups are set in two types - entity and collection.

Entity - when the relation between parameters is one to one, i.e. one parameter can relate to only one other parameter entity from the next logical group. E.g. - one order can relate to only one category product, not more.

Collection - a.k.a. a collection of entities: when the relation between parameters is one to many, i.e. one parameter can relate to multiple other parameter entities from the next logical group. E.g. - one purchase can relate to multiple orders. Only Collections can have Conditions, simply with the purpose to sort them out and specify them.

Flow Details - Assigning Aliases

Once the desired Parameter category is chosen, a popup window appears for setting up aliases. Each parameter has a certain title that has system logic. In case the creator of the flow prefers, they can rename it to ease the process. This will not change the variable itself, just that entry for that flow.

set an alias for the eventor parameters

Flow Details - Parameter Conditions

To best understand the Parameter conditions, or also called Relation filters, a preview of the setting is displayed below. These conditions help assign specific characteristics to the Parameter categories that allow it. This is done by using a resource, various relation units, and a value.

This additional setting is not available for every parameter category. Wherever it is available, it includes the variables from that specific group.

setting up relation filter for eventor


The following example is a Relation Filter from the "Order" Parameter Category. This category contains general information on an order. Its filter specifies the quantity of the product to be less than 50 (years, months, etc., depending on the product itself). This means that the entire Flow will have to comply with this setting and when a product's quantity is larger, the Flow will not apply to it.

example of a filter for parameter

Flow Details - Additional overall Conditions

The step involves the last adjustments on additional overall conditions. Unlike the Relations filters from the previous step, all variables from all selected parameter groups can be set with a specific condition here.

On the top of the page the completed steps are present with a brief explanation on Step 3. After that, the additional Conditions can be set up. The example screenshot below has been populated for the purpose of visual representation. In the case something additional needs to be specified in the flow that may not be relevant to all possible cases, it is set as a condition. Additionally, the resources, that can be attached, depend on which Parameter categories have been already selected. Those resources only will be available during this step. This process is again done by using a resource from a drop-down list, various relation units, and a value.

The example here shows that there is a condition set that specifically states that the Product Category ID must not match #765, which means that the system will be applying the Eventor Flow to all Product Categories except this one.

step three of creating the eventor flow is to set up conditions

Note: In order to create a Condition during Step 3, the desired variable and its parameter group need to be first already selected (previous screen). Additionally, creating the conditions could happen during Step 2, if the specific parameter group has the option to set up Relation filters.

Available Admin actions

Control buttonDefinitionDetail
Alternative textAdd resource- Add a new resource from the drop-down list. The included resources are parameters from the previously selected Parameter categories in Step 2 of Eventor Flow creation.
Alternative textDelete- Delete the condition row.
Alternative textAdd new rule- Add a new condition row to create a new rule.
Alternative textBack- Go to the previous step of the Eventor Flow creation without losing data so far.

Conditions, Variables and Updates

It is important to note how the system fetches information on event updates in order to best understand how to build an Eventor Flow.

Every time the same event goes through a modification, the event is triggered and the update displayed. The example below displays an event where the Descriptor has been modified. The update is marked with "_update:" and after that the variable that has been changed.


	"descriptor": "example.com",
	"status": "pending",
	"paid": 0,
	"_update": {
	    "descriptor": "example.com"

The next data example includes a modification made to the paid status. At the same time, the event returns all the rest of the variables in their latest update.


	"descriptor": "example.com",
	"status": "pending",
	"paid": 1,
	"_update": {
	    "paid": 1

The next example data is again of the same event with an update done to the order status. First - when it is "approved", and then - when it is "activated".

Note: An order will go through a few statuses, until it reaches either "activated" or "collapsed". Each one will be a separate "_update" to that order event.

	"descriptor": "example.com",
	"status": "approved",
	"paid": 1,
	"_update": {
	    "status": "approved"

	"descriptor": "example.com",
	"status": "activated",
	"paid": 1,
	"_update": {
	    "status": "activated"

All of these examples represent the same exact event - purchasing example.com, and all the updates the event goes through in order to be completed - going from unpaid to paid, being approved for processing, being processed, and finally approved. With Eventor, though, an Admin can set up an Eventor flow every time a specific update happens to a specific event. Still, it is important to pay attention which variable is being set in that condition.

Considering the examples above, let's set up a Condition to an Eventor flow, where the Admin wants to send a notification when the order of the user is paid.

step three conditions example

For now, this condition makes sense, as it is set up to trigger the flow when the paid status equals "1", meaning when it has been completed. Still, an order being paid is a type of an event update to an order purchase event, and if we take into account how the system actually fetches information on event updates, as described above, it is then clear that this condition will not work as desired. This is due to the fact that the system displays Paid status = 1 in more than one occasions - at the update from unpaid to paid itself, and after that during every other update to that same already paid order. Hence, the system will execute the flow in every single such occasion, as per the condition above. This will lead to multiple notifications instead of just one.

The problem here is the variable used to display the paid status. Instead of using the obvious one "paid", we need to use the "_update" status for that variable instead. This way, the system will know to isolate only that event modification, where the payment was actually made, as it is specified as the update. Moreover, every other time the event is triggered by another update, the flow will not be executed as the update will be different and not the specified one.

variable example in step three setup

Note: It is important tо use the correct variables in Eventor Flow Conditions. Keep in mind that events may be triggered again in the case of updates. To isolate an event by the update, use "_update" and the respective variable after that.

Flow Details - Listener details

In this section the Listener needs to be set up specifically for the flow being created. Depending on the type of Listener, various fields can exist here. In this example, the Listener functionality is to send a customer Email, which, in this Listener's case, doesn't involve a template.

Mostly, in this section is where all the chosen parameters from Step 2 are put in use. The screenshot below gives an example as to how the resources are used for each respective field. In this Listener's case the actual content of the email is a freely written text, which in the respective parts includes specific resources. The actual body of the email could also contain JSON variables, if preferred so.

Tip: TWIG syntax is supported so more complex services can be set up like loops, ifs, etc.

After the Flow's event is triggered and the Flow itself - activated, the system will replace the resources with their respective information, e.g. the actual user's names, the actual product name, etc.

example content of email listener during step three

Note: Please note this Listener's content is purely an example. An actual text set here may require more content and variables.