Article last updated on the 7th of November, 2022.
Contents
1. Introduction
In WorkPoint Automate, triggers are special steps which allow for execution of a series of steps when certain conditions are met.
Triggers are used in System processes only.
WorkPoint's event receivers register events happening in the WorkPoint system. If an event matches a WorkPoint Automate trigger, the subsequent steps of the process are executed.
Here are some examples of triggers in WorkPoint Automate:
- When an item is created
- When an entity is updated
- When a stage is changed
As previously mentioned, triggers may execute the steps in the process when certain trigger conditions are met. For example, using the "When an item is updated" trigger, a configuration could be made which executes if a task on a process is updated and as it's status changed to "Completed".
Another example could be a "When a stage is changed" trigger which executes a series of steps when cases change to a specific stage, sending an e-mail to the case responsible.
Note that a process may include multiple triggers. In this case, only one of the triggers' requirements needs to be fulfilled for the subsequent steps to be executed.
2. How to use triggers
2.1. Trigger options
As previously mentioned, triggers monitor specified locations, e.g. a business module list or a list on entities on a specified business module. If an event happens in the specified location and the event matches the trigger type, the subsequent steps in the process will be executed.
Defining the location a trigger monitors is done using the triggers options, which are described in the following table.
| Property name | Type | Description |
|---|---|---|
| Title | String | Give the trigger a title (does not need to be unique). |
| Business module | String |
Select the business module this trigger should monitor for events. |
| Disabled |
Boolean |
Enable or disable the trigger. Disabled triggers will not execute subsequent steps. |
| List1 | String | Select the list on an entity to monitor for changes. |
1The "List" option is only available on triggers which monitor a specific list for changes.
2.2. Conditions
For examples of common trigger condition setups, please visit this article.
Other than the options which define the location a trigger monitors, triggers also allow for conditions to be configured.
This makes it possible to not only monitor a location for events, but let the system know only to execute the subsequent steps if an event happens, and one or more specified conditions are met.
Configuring conditions is done in the Conditions section of the trigger settings, which looks like the following:
Conditions can be configured using the basic mode by filling in the fields in the image. These fields are described in the following table:
| Property name | Description |
|---|---|
| Type | Select a data type to compare. You can use simple text or pick content from the Context browser, e.g. Entity.ID. |
| Value | Enter a value to compare. |
| Operator | Enter an operator for the comparison, e.g "Equal to" or "Greater than". |
| Target type | Select a target data type to compare the original type to. |
| Target value | Select a target value to compare the original value to. |
Alternatively, using the Advanced mode, you can submit an Adaptive Expressions expression as a condition.
If no conditions are configured, the trigger will execute subsequent step when any event matching it occurs in the location it is monitoring.
Note that a trigger can have multiple conditions, which can be separated by either an AND or an OR operator.
Trigger conditions are comparative statements which will pass if the comparison evaluates to true.
For example, if we have a "When an entity is updated" trigger which triggers the sending of an e-mail, we can use conditions to make sure that the e-mail is only sent if the field which was updated was the "Project Manager" field, or if some other field was set to a specific value.
By using triggers, you can make the things you check for in order to start a process very specific.
3. Examples
3.1. Basic condition
In this example, we will set up a condition so that our "When an entity is updated" trigger only triggers if the triggering entity is not the Master site of our Cases business module.
This demonstration purposes, we have set up the following process:
Currently, this process will send an e-mail if a meta data change is detected on any entity in the "Cases" business module.
We will now configure the condition to make it so that only meta data changes on entities which are not the master site will trigger the "Send Mail Action" step. To do this, we need to know the ID of the master site on the business module. In our case, the master site has ID 1. You can find this ID in the business module list, given that the ID column is shown.
- We only want to run the subsequent steps in the process if the ID of the triggering entity is not equal to the ID of our master site, which is 1. We can select the entity ID from the context browser, so for "Type" we select "Context".
- We then click the Value field and expand the "Entity [Object]" menu item in the context browser.
- Finally, we select "ID [Number]". This fills the Value field with the entity ID of the entity which triggered the process, as seen in the following image:
- For the comparison operator, we select "Not Equal To". This is because we want to execute the process steps if the ID of the triggering entity is not equal to 1, which is the ID of our master site.
- To use a value of 1 fr our comparison, for Target Type we simply select "Text".
- For the Target Value, we then type in "1".
Our finalized condition then look like this:
When the process is triggered, this condition will look at the ID of the entity which triggered it. If the ID of the entity is not equal to 1, then subsequent steps will be executed.
3.2 Advanced condition
Using the Advanced option for conditions allows you to use Adaptive Expressions to implement logical checks and comparisons and run subsequent steps in the process depending on the outcomes.
You can use the Advanced option by selecting it in the Conditions section of the trigger:
- Click "Advanced" to switch to use Adaptive Expressions to define your trigger conditions.
The system displays the following dialogue:
- Click the "OK" button to switch to the advanced view.
The advanced view provides us with a text field in which we can type our Adaptive Expression to use as a condition for our trigger:
For this demonstration, we have prepared the following condition using Adaptive Expressions:
- This expression defines the condition such that the subsequent steps in the process will be executed only if the triggering entity's title is not "MASTER" (i.e. the master site of the business module), and the entity is currently in the "Active" stage (entity stages are represented by the ContentType).
For comprehensive guidance on the Adaptive Expressions, please visit the following links:
Note that we can use WorkPoint data in the Adaptive Expressions. We can, as shown above, use e.g. Entity.Title to get the title of the triggering entity. In the same way, you could use e.g. "Solution.Url" to get the url of the WorkPoint solution, or "CurrentUser.Email" to get the current users e-mail address.
As a general rule, first type in the scope of the data you want to get (e.g. Entity or CurrentUser), following by a dot and then the internal name of the data field (e.g. wpBudget or UserPrincipalName).
Please note that WorkPoint does not offer support on individual custom adaptive expressions for conditions. Please refer to Microsoft's documentation on Adaptive Expressions linked above.
4. List of triggers
| Trigger | Description |
|---|---|
| When an entity is updated | Triggers subsequent steps when the meta data of an entity on the monitored business module list is updated. |
| When an entity is created | Triggers subsequent steps when a new entity on the monitored business module list is created. |
| When an entity is copied | Triggers subsequent steps when an entity on the monitored business module list is copied. |
| When an entity is deleted | Triggers subsequent steps when an entity on the monitored business module list is deleted. |
| When an entity site is created | Triggers subsequent steps when a site for an entity on the monitored business module list is created. |
| When an entity buffer site is created | Triggers subsequent steps when a buffer site is created for the specified business module. |
| When an item is created | Triggers subsequent steps when an item in the monitored entity site list is created. |
| When an item is updated | Triggers subsequent steps when the meta data of an item in the monitored entity site list is updated. |
| When an item is deleted | Triggers subsequent steps when an item in the monitored entity site list is deleted. |
| When an item is published | Triggers subsequent steps when an item in the monitored entity site list is approved. |
| When a stage is changed | Triggers subsequent steps when an entity on the monitored business module list transitions into a new stage. |
Comments
0 comments
Please sign in to leave a comment.