Adding and Maintaining Triggers
Last Updated: 19 Jun 2017
The Trigger asset is used to perform automated actions whenever certain events happen in your Squiz Matrix system. The Trigger will "listen" for an event, check the conditions for that event and then (if the conditions are met) perform an action.
Adding a Trigger
When you add a Trigger, it will always get added under the Trigger Manager. If you set a Category value for the Trigger, it will be created under a folder with that Category name.
If you create a Trigger outside of the Trigger Manager, it will automatically get a link created under the Trigger Manager as well.
This screen allows you to configure the Events, Conditions, and Actions of the Trigger.
- Status: Select whether or not to enable the Trigger. If the Trigger is not enabled, it will not fire when the event occurs. By default, when a Trigger is created it is Disabled. Once you have set up the Trigger, select Enabled from the list provided.
- Blocking: Select whether or not the Trigger should block the event and any subsequent Triggers from running if it fails. For example, if the Trigger fired when the Status of an asset changed and it failed to complete the actions, the Trigger would stop the Status from being changed and stop other Triggers from running.
- Name: The name for the Trigger.
- Description: A description of the Trigger to explain what it does.
- Category: The category that the Trigger belongs to. When you enter a category, a Folder with this name is created in the Asset Map under the Trigger Manager and the Trigger is stored under that Folder. You can group multiple Triggers together in the same Folder by using the same category name. To create multiple categories, separate each Folder name with a /. For example Folder1/Folder2 will create two Folders, with Folder2 a child of Folder1. To move Triggers between Folders, change the category name.
This section allows you to select which types of events the Trigger is "listening" for.
When an event that is selected occurs, the conditions of the Trigger will be checked to determine whether or not the actions specified need to be performed. For more information about each of the events that are available, refer to the Trigger Events chapter in this manual.
If no events are selected, the Trigger will fire when any event occurs within the system. This can affect the performance of your system and at least one event should be selected. On other hand, selecting too many events can also affect the performance of your system.
This section allows you to add conditions to the Trigger. These conditions will be checked when the event that is selected occurs. If the conditions are true, the actions specified will be performed.
To add a new condition to the Trigger, select the condition from the list provided and click Commit. Additional fields will appear in the Conditions section. For example, the figure below shows the Asset Status condition in the Conditions section.
A condition can be inverted be selecting the Inverse this condition field. When a condition is inverted, the inverted logic of that condition will be used. For example, the Asset Status condition can be set to check if the Status of an asset is Live. This condition would match on all assets that are Live. If this condition was inverted, however, it would match on assets that were NOT Live, such as Safe Edit or Archived assets.
Please note that as the inverted logic of a condition will likely be met in a large number of scenarios, as such, it is recommended to use this option sparingly as system performance may decrease.
You can add multiple conditions to a Trigger. To do this, select the new condition in the Add new Condition type field and click Commit. Please note that some conditions can only be added once, hence will not appear in the list if they have already been added. For more information on each of the conditions, refer to the Trigger Conditions chapter in this manual. When you add a new condition, it will appear at the bottom of the Conditions section. If you add a condition, but do not change its settings, it will automatically fail.
To disable an existing condition, select the Disable check box on the condition and click Commit; the condition will be greyed out, indicating that it is currently disabled. When a condition has been disabled, its settings will not be checked against when the Trigger is fired. To enable a disabled condition, simply uncheck the Disable field and click Commit.
To delete an existing condition, select the Delete check box on the condition and click Commit. The condition will be removed from the Trigger and will need to be added again if you wish to reinstate it.
When an event is fired, the configured conditions will be checked in the order they are presented on the Details screen of the Trigger. If these conditions pass, the set action(s) will be executed.
Because of this, it is recommended that you list conditions based on their expected processing time. Conditions that work on checking exact values (such as a specific Status or tree location) should be listed above conditions that check against a range of values, which generally take longer to process (such as all Page type assets).
This will allow the collection of assets being checked to be filtered down before going through some of the more lengthy condition checks. This will customarily lead to an overall performance improvement when checking the conditions of your Trigger.
This section allows you to add the actions that the Trigger will perform. These actions will only be performed when the conditions specified in the section above are true.
To add a new action to the Trigger, select the action from the list provided and click Commit. Additional fields will appear in the Actions section. For example, the figure below shows the Set Status action.
You can add multiple actions to a Trigger. To do this, select the new action in the Add new Action type field and click Commit. For more information on each of the actions, refer to the Trigger Actions chapter in this manual.
The actions configured on a Trigger are executed in the order they are presented on its Details screen. By default, if one of these actions cannot be run, the Trigger will fail and any subsequent actions will not be executed. You can, however, specify an action as Non-Critical; this will allow any remaining actions to continue to be run if another action fails. For example, in the figure above, if the Non-Critical option was selected and the Trigger was unable to set the Status of the asset, the remaining actions configured on the Trigger would still be performed. By default, the Non-Critical option is not selected on Trigger actions.
Triggers within Squiz Matrix have individual transactions for each action configured. This means that, under most circumstances, any actions that have already been executed will not be rolled back in the event that a Trigger fails.
By default, the actions are performed as the user that caused the Trigger to fire (i.e. the currently logged in user). This means that some actions may fail, as the user does not have permission to perform the action. For example, a Backend User with Write Permission to an asset cannot change the Status of the asset to Live. If this user causes a Trigger to fire that changes the Status of an asset to Live, it will not work. However, if the Ignore Permissions option is selected, Squiz Matrix will ignore the access rights the user has been given and perform the action. Hence, the Status of the asset will be changed to Live even though the user cannot do this manually.
To disable an existing action, select the Disable check box on the action and click Commit; the action will be greyed out, indicating that it is currently disabled. When an action has been disabled, it will not be performed when the Trigger is fired. To enable a disabled action, simply uncheck the Disable field and click Commit.
To delete an existing action, select the Delete check box on the action and click Commit. The action will be removed from the Trigger and will need to be added again if you wish to reinstate it.
Action on Other Assets
By default, Triggers will be actioned on the broadcasting asset, i.e. the asset that fired the configured event. The Action on Other Assets option allows you to modify these settings and specify an alternate set of assets that the Trigger will be actioned on.
When this option is enabled, the Assets to Action On section will be displayed, as shown in the figure below.
The fields available in this section are as follows:
- Include Current Asset?: this field allows you to specify whether or not to include the asset that the action is executing on (the default).
- Include Linked Parents?: this field allows you to include parents of the current asset, matching a specified link type(s) and/or link value.
- Assets: this field allows you to select the individual assets that the Trigger will action on.
- Dynamic Parameters: this field allows you to configure a dynamic parameter to set the assets that the Trigger will action on via a comma-separated list of asset IDs.
- Asset Level: this field allows you to specify the level of assets that the Trigger will action on. The following options are available:
- Selected assets
- Selected assets and their dependants
- Selected assets and their children
- Include Asset Types: this field allows you to specify the assets types that the Trigger will action on. By default, this field will be set to 'All asset types'.
By default, when a Trigger is created it is disabled. This means that the Trigger will not fire and hence the actions will not be performed. In the Asset Map, (disabled) will appear at the end of the name of the Trigger asset.
To enable a Trigger, go to the Details screen of the Trigger asset, select Enabled in the Status list and click Commit.
Editing a Trigger
Once you have created a Trigger, to add or remove any events, conditions or actions go to the Details screen of the Trigger asset. Each Trigger asset is located under the Trigger Manager in the Asset Map.
By default, when a Trigger is created it will automatically be stored under the Trigger Manager in the Asset Map. If you create a number of different Triggers, this list can be long and it can be difficult to find the Trigger that you want.
To make it easier to find Triggers, you can categorise each Trigger in the Category field on the Details screen. When you enter a category, a Folder will be created under the Trigger Manager in the Asset Map. The name of the Folder will be the name that is entered into the Category field. For example, if you enter Status into the Category field, a Folder called Status will be created, as shown in the figure to the right. To create multiple categories, separate each category name with a /. For example Folder1/Folder2 will create two Folders, with Folder2 a child of Folder1. To move Triggers between Folders, change the category name.
Moving, Linking & Cloning Triggers
Because Triggers are Shadow Assets, they can't be moved in the Asset Map like normal assets such as Standard Pages or Folders. For example, you can't drag and drop a Trigger to move it into a different Trigger Folder (Category). You need to edit the Trigger's Category field in order to do this.
You are however able to:
- Link a Trigger to be located under another asset outside of the Trigger Manager, for example under a Folder.
- Clone a Trigger.
- Trigger Manager
- Adding and Maintaining Triggers
- Trigger Events
- Trigger Conditions
- Trigger Actions
Noticed an error?
Want to suggest an improvement?