Event triggers have actions. It is these actions that then occur if a scenario matches the trigger criteria. For example, this could be sending an email; or assigning a member a Fitflix video.
A trigger may have one or more actions. If a trigger does not have any actions, it effectively has “nothing to do” and it will not yield any result.
All actions are processed at the time that an event is matched, although the time they take effect may be deferred (see below). Additionally, you may specify an action of the type “Any one action from a sub-group of actions”. This is a special action type that you may use to group a number of actions. When this action is processed, Quoox will randomly pick any one of the actions within that group to process. The other actions within the same group are skipped.
Adding a new action
To add a new action, select the type of action that you wish to configure from the drop-down list. Then press the Add action button.
You will be taken to the action configuration screen.
To add a new action to an “Any one action from a sub-group of actions” group, select from the drop-down list corresponding to that particular group. You will then, similarly, be taken to the action configuration screen.
Editing an existing action
To edit an existing action, click the icon alongside the corresponding action. This will open the action configuration screen with the details pre-populated.
Deferred and delayed trigger actions
Some trigger actions, such as emails and SMS messages, provide for “deferred or delayed enactment”. This gives you greater control over your messaging and many of the trigger actions. For example, if a trigger matches a members action at 9:03am, you could delay the action for 2 days and then optionally specify the time range between which the action occurs.
A real-world example of this is the “Attended a new session type” trigger. You could configure your trigger with a delay of 1 day, and then an action time range of 12:00 – 14:00. If the member is marked as having attended a new session type at 9:03am on the Tuesday, the action would then occur between 12:00 and 14:00 on the Wednesday.
Deferred and delayed actions put space between the triggering action and the visible result. This is a good way of i) reducing the appearance of automation, and ii) ensuring messages are sent during sociable hours.
Most action types have information you need to provide to configure the action. For example, for an SMS message action you would need to tell Quoox the message that you wish to send.
Different action types have different configuration requirements, and are largely self-explanatory.
As with a trigger, you may set a trigger action as being either active or suspended. Suspended trigger actions are not processed when a trigger is fired. This provides you methods for setting up different trigger actions, and ‘playing’ with different outcomes.
When a trigger is processed, it has a “context”. The context is the scenario in which the trigger is evaluated.
The context will typically have a “subject” (I.e., the member or lead against whom the trigger has fired) and “supporting elements” (I.e., the ‘session attended’ trigger will have a supporting element of the session and session booking).
The trigger context may be used to personalise the actions for a trigger by the use of merge fields. Different merge fields apply to each of the different trigger types, and the merge fields available for a given trigger type are documented within the Event Triggers section of the knowledge base.
Actions within Quoox triggers do not cascade. This is by design to avoid “run-away” triggers.
To explain what this means, you may have a trigger which sets a member status to “Needs attention”. If you had a different trigger setup which is fired when the member’s status is set to “Needs attention”, this trigger will not be processed. A trigger is effectively processed in its own “silo”. One trigger does not fire-off another trigger.
The “message received” trigger contains an additional ‘safety step’ in which the trigger will not be processed again for the same message sender for a given number of minutes. This avoids the scenario of the member sending a message and then turning on their ‘out of office’. If you had a trigger which auto-replied, this could end up in an endless loop. This would clearly be problematic, and adding a ‘suspension period’ to this trigger type overcomes the problem.