Using event data in a handler

When creating a trigger for an object, there are two things that specify how the trigger will behave:

• The event and its payload
• The handler and its configuration

The event itself does not have any configuration options, you simply select an event to listen to, which will always have the same payload structure.

The event handler, on the other hand, is usually fully configurable. Different event handlers have different configurations, but the way of interacting with the information provided in the event is always the same.

Assigning values to event configuration fields

Many fields in event configurations are fixed which means they are values that are defined in the trigger editor and do not depend on the event type. Other fields are mapped, that is to say, their value depends on the value of a given field in the event payload. Most fields are mixed, in that they can either have a fixed value or be mapped to an event payload property.

Fixed values
Fixed values are set during configuration time and remain the same independently of the event type or payload. For example, when configuring a Call webhook handler, the webhook is set during configuration:

Mapped/mixed fields
Mapped fields provide a list of properties from the event payload which can be selected. Mixed fields provide the option to treat the field as a fixed value or as a mapped value. For example, in the call webhook handler, the payload field is a mixed field, and the value of the payload can either be set at configuration time or when the event is received:

The chain button toggles between treating the value as a fixed value or as a mapped field. When the button is green, it indicates that the field is being treated as a fixed value. In this example, whenever the webhook is called, the payload sent to the webhook will always be the same (independently of what the event type is or what its payload contains), the string Hello webhook, this event has just been triggered!.

When the chain button is blue, it indicates that the field is being treated as a mapped property:

In this example, the payload being sent to the webhook is the origin property of the event, which is an object which contains the fields id, name, type and pathName which is the data set if it is a data set event, or the run configuration if the event is for a run configuration, etc. When the event is triggered and the event is called, these variables will be sent to the webhook (in JSON format).

Column mapping

Handlers that contain a column mapping field allow you to define the kind of data you want for each row that is being added, each dictionary entry, each data set row, each robot execution input, etc.

Example scenario - Data set rows added => Add dictionary entry

In this scenario, a trigger has been created for the Rows added event of a particular data set. The data set has a data type that contains four-string (text) fields, firstName, lastName, age and email. The Add dictionary entry handler has been selected to be activated when this event is triggered. It has been selected to add the entries to a dictionary called Node dictionary. The key and the value of the selected dictionary are text values, not objects, and that is reflected in the column mapping options. The value of payload.rows.email has been mapped to the key of each new entry, and the value of payload.rows.lastName has been mapped to the value of each new entry.

With this configuration in place, let us assume that a set of 30 rows is imported to this data set. What will happen next is that this trigger will be invoked and an entry will be created for each of the 30 separate rows, with the email as the key and the last name as the value. Once they are created, they will be added in bulk to the dictionary.