Follow

Process Management Framework - Triggers

Article last updated on the 10th of March, 2022.

1. Introduction

In the Process Management Framework, 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 Process Management Framework trigger, the subsequent steps of the process are executed.

Here are some examples of triggers in the Process Management Framework:

  • Item updated trigger.
  • Entity updated trigger.
  • Stage changed trigger.

As previously mentioned, triggers may execute the steps in the process when certain trigger conditions are met. For example, using the "Item 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 "Stage 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).
Disabled Boolean Enable or disable the trigger. Disabled triggers will not execute subsequent steps.
Business module String
Select the business module this trigger should monitor for events.
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:

WorkPoint Process Builder - Google Chrome

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 an Entity 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 "Update entity 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.

  1. 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".
  2. We then click the Value field and expand the "Entity [Object]" menu item in the context browser.
  3. 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:
  1. 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.
  2. To use a value of 1 fr our comparison, for Target Type we simply select "Text".
  3. 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:

  1. Click "Advanced" to switch to use Adaptive Expressions to define your trigger conditions.

The system displays the following dialogue:

WorkPoint Process Builder - Google Chrome
  1. 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:

WorkPoint Process Builder - Google Chrome

For this demonstration, we have prepared the following condition using Adaptive Expressions:

WorkPoint Process Builder - Google Chrome
  1. 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:

General Adaptive Expressions documentation

Prebuilt Adaptive Expressions functions

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
Entity updated trigger Triggers subsequent steps when the meta data of an entity on the monitored business module list is updated.
Entity added trigger Triggers subsequent steps when a new entity on the monitored business module list is created.
Entity copied trigger Triggers subsequent steps when an entity on the monitored business module list is copied.
Entity deleted trigger Triggers subsequent steps when an entity on the monitored business module list is deleted.
Entity site created trigger Triggers subsequent steps when a site for an entity on the monitored business module list is created.
Entity site collection buffered trigger Triggers subsequent steps when a buffer site is created for the specified business module.
Item added trigger Triggers subsequent steps when an item in the monitored entity site list is added.
Item updated trigger Triggers subsequent steps when the meta data of an item in the monitored entity site list is updated.
Item deleted trigger Triggers subsequent steps when an item in the monitored entity site list is deleted.
Item published trigger Triggers subsequent steps when an item in the monitored entity site list is approved.
Stage changed trigger Triggers subsequent steps when an entity on the monitored business module list transitions into a new stage.
Have more questions? Submit a request