Triggers in Enterprise+

Introduction

This article is intended to serve as a guide for configuring triggers that automate actions in Enterprise+.

Triggers

Triggers set off events or actions that can be used to automate processes and perform specific actions within the Enterprise+ platform. Users can access this functionality through multiple pathways:

• Menu: Administration -> Integrations -> Triggers: This is the main pathway to access and manage triggers across different sections of Enterprise+.
• Section-Specific Triggers: Users can also access Triggers within specific sections, such as:
  • Learners -> Triggers: Triggers related to learners or students.
  • Enrollments -> Triggers: Triggers associated with enrollments.
  • Sections -> Triggers: Triggers specific to sections.

These Triggers allow users to define actions or workflows that are automatically executed in response to certain events or conditions, streamlining processes and enhancing automation within the Enterprise+ platform.

To add a new Trigger, click on the "Add Trigger" button.

Here is an explanation for each field:

• Name: Trigger Name.
• Description: Trigger Description.
• Object Type: Type of Object that the Trigger will operate on. Currently, there are the following types:
  • Enrollment
  • Learner
  • Section
  • RequestedSection
• Trigger Type: Defines when the Trigger event will be executed.
  • On Create
  • On Update
  • On Create Or Update
  • On Delete
• Status: Trigger Status.
  • Active
  • Archived
• Run Actions only the first time criteria are met: This option forces the Trigger to be executed only once. If the trigger fails, the user will have to attempt to execute the function again.

Criteria

When you click on "Add Clause," the system opens the following options:

Here is an explanation for each field:

• Field: The field that will be used to apply the criteria. All available fields in the object's ViewModel will be listed.
• Operator:  The operator that will be used to validate the criteria. Options include:
  • Equal To
  • Not Equal To
  • Greater than
  • Greater than or equal to
  • Less than
  • Less than or equal to
  • Contains
  • Not contains
  • Is blank
  • Is not blank
  • In
  • Not in
  • Starts with
  • Not starts with
  • Ends with
  • Not ends with
  • Is today
  • Is days before
  • Is days after
• Value: The value that will be used to validate the criteria.

Here are some examples of criteria usage:

You can add multiple criteria to a trigger, and by default, all criteria must be valid (AND) for the action to be executed. In other words, when you have multiple criteria defined for a trigger, all of those criteria must be met simultaneously for the trigger to activate and execute the associated action. This ensures that the trigger is only activated when all specified conditions are true.

Actions

Actions are the tasks or operations that can be executed when the defined criteria are met. To add an action, simply click on the "Add Action" button.

Currently, there are three types of actions:

• Http Request
• Send Email
• Pre-Defined Actions

HTTP Request

HTTP Request allows users to configure the details of a Webhook action (call 3^rd party API), specifying the method, URL, message body, retry behavior, and any additional headers required for the request. This flexibility enables you to integrate and communicate with external systems or services as needed.

Here is an explanation for each field:

• Method: The HTTP method that will be used in the request.
  • GET
  • POST
  • PUT
  • DELETE
• Url: The URL to which the request will be submitted.
• Body: The message body that will be submitted with the request.
• Retry Count: The number of times the system will attempt the request if an error occurs during the initial attempt.
• Headers: A list of key-value pairs that can be included in the request header.

Inside the Body, you can list the variables that can be used to assemble objects. This means you can define placeholders or variables within the body of the Webhook request. These variables can be replaced with actual values when the Webhook action is triggered, allowing you to dynamically construct the content of the request based on the specific conditions or data at the time of execution. This dynamic approach makes the Webhook action highly flexible and adaptable to different scenarios and use cases.

Here's an example of a Body for a Webhook action that includes variables:

{

   "accessItems": "[COURSE_CF.PRODUCT_ID]", 

   "user": "[USER.USER_NAME]", 

   "option": "PRODUCTS" 

}

• The variables should be formatted as "[COURSE_CF.PRODUCT_ID]" in order to be replaced by their corresponding values.

Variables can also be used in the URL to be replaced in the same way as they are used in the Body.

Here's an example of a URL using variables:

http://test.geniussis.com/Courses/[COURSE.COURSE_INDEX]

 

Send Email

Send Email allows the user to configure sending specific emails based on certain conditions.

Here is an explanation for each field:

• To: Recipient of the notification.
• CC: Email addresses that will be placed in the carbon copy (CC).
• Subject: Subject of the email.
• Import Template: Lists the existing templates in the system. When selected, the system will import the template for this notification.
• Body: The email body that will be sent. Users can select variables from the object's view model to compose the email body.

Pre-defined Actions

The pre-defined actions are rules already defined in Enterprise+ to help users to build their triggers. It will list the pre-defined actions based on the selected "Object Type," and currently, there is only one option implemented for the "RequestedSection" object type, which is "Enroll Requested Section."

The structure of pre-defined actions has been designed to accommodate future implementations of additional actions for each object type within the system. This flexibility allows for scalability and the potential to extend the range of available actions as needed, providing adaptability to changing requirements and workflows.

Post Actions

These are actions that can be executed based on the response of an HTTP request. When enabling this option, additional configuration options appear on the screen to be set up:

Final Criteria

Used to filter the response of HTTP Request and execute a post action based on defined criteria.

Here is an explanation for each field:

• Reference Action: This is the action that will be used to apply the final condition. If not selected, the system will apply this condition to all actions of type HttpRequest.
• Field: The field that will be used to apply the condition. Options include:
  • Always (Force Approval)
  • ResponseBody
• Operator: The operator that will be used to validate the criteria. Options include:
  • Equal To
  • Not Equal To
  • Contains
  • Not contains
  • Is blank
  • Is not blank
• Value: The value that will be used to validate the final criteria.

These fields allow you to define conditions based on the response of an HTTP request and specify the criteria that trigger the action you want to apply. The flexibility of these settings allows for precise control over how actions are executed based on the response data.

Final Actions

These are the actions that will be executed if the conditions of the Final Criteria are met.

• The "Final Actions" have the same execution possibilities as regular actions.

In an example scenario, based on the result of an API call, you are enrolling the requested section for the student.

Logs

Each time the process is triggered, a process log is recorded for each action. These logs can be viewed on the Triggers screen by clicking the following button:

This is the Logs screen:

On this screen, you can verify exactly what was sent in the requests, view the responses to the requests, and see the payload that was sent in the HTTP request.

A user can also check the Final Actions on this screen.

If the job fails, force the re-execution of the trigger by clicking on the following button:

Jobs

TriggerJob.ExecutePendingActions

This job is responsible for executing automatic retries according to the configuration of the trigger. It ensures that any actions that require automatic retries, based on the trigger settings, are performed as specified.