Triggers are agents that can be set to execute actions in response to the occurrence of a particular event.

Context of use

It is possible to automate the execution of actions in response to an event using the API. But when the triggering event is an internal GT event, the API is not very appropriate. Suppose we wanted to run the data integration action for a given template each time the server receives a response to refresh a dashboard. With the API, we would need to:

1. Make a script that :

• • Store the date of the last response for all entities in a table, which would allow an SQL view to determine whether new responses have arrived
  • Test the presence of new responses using the view and then, if necessary, execute the integration action.

2. Run this script at regular intervals, for example, using a task scheduler.

As you can see, it is quite a lot of work to execute the script and, on the other hand, triggering it at regular intervals is not optimised. Let’s imagine that we run the script every 5 minutes. This means that as soon as a response is received, it will take up to 5 minutes to refresh the dashboard. But if we increase the frequency of execution of the script, we run the risk of degrading the performance of the server.

A trigger will be perfectly appropriate in this case. Indeed, it only requires a few clicks to be configured and will always be triggered at the right time.

In summary, if the API is the only way to execute actions in response to an external event, triggers should be preferred when the source event is internal to the server.

Configuration

Triggers are associated with a template, like actions and messages. It is from the events relating to this template that actions are triggered.

To create a new trigger :

1-In the templates/actions page, select the template.

2-Click on the “Create a new trigger” button

3-Enter a name and a description in the same way as for an action.

4-In the “Input” sheet, define the trigger event. In our case, we want to execute an integration action as soon as a response is received.

Our event will therefore be “Response received”.

5-In the “Output” sheet, specify :

1. The table and field providing the Statement date that will be used for the actions to be executed. If no Statement date table is provided, the server will use the Statement date of the campaign on which the trigger was evaluated.
2. The user account that will be used to execute the actions. This can only be an Administrator or Developer account.
3. The actions to be executed. As with a combination, you can select all the actions for the templates in the current project. And, in the same way, if you use launch actions (collection or restitution), it will be necessary to configure the messages (with the edit button)

6-Click on “Ok”, your trigger appears in the list. The switch on the right allows you to make it active or inactive.

Note: Only users with administrator or developer rights can create and activate a trigger.

Advanced use

The scope of use of a trigger can be refined by using the axis. Consider the following launch action:

It is possible to configure a trigger that will only be triggered when all responses from a country have been received.

To do this, in the trigger configuration interface, you must not check “City”, but only “Country” in the filtering diffusion axis:

It is also possible to set up a trigger so that it only runs when a response from certain countries is received – and not the others. This would require the use of a “Table of filtering values”. This should contain a column with the same name as the chosen axis(es) and the trigger will then only run if the value of the diffusion axis or the combination of values of several axes is present in the table.

Following the same principle, it is possible to set up a trigger that would only run for certain Statement dates, which would allow, for example, to deactivate a trigger for test campaigns automatically.