Triggers - Genius CE & Enterprise

Triggers

Triggers set off events or actions that can be used to automate processes and perform specific actions within the Genius CE & Enterprise platforms. 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 Genius CE & 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 enable users to define actions or workflows that are automatically executed in response to specific events or conditions, streamlining processes and enhancing automation within the Genius CE and Enterprise platforms.

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 must attempt to perform 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 requirements 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 met.

Actions

Actions are the tasks or operations that can be executed when the defined criteria are met. To add an action, 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 (calling a 3rd-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 request content based on 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:

• The variables should be formatted as "[COURSE_CF.PRODUCT_ID]" 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:

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 predefined actions are rules already defined in the Genius CE and Enterprise platforms to help users build their triggers. It will list the pre-defined actions based on the selected "Object Type." Currently, there is only one option implemented for the "RequestedSection" object type: "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 enables scalability and the potential to expand 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 an 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 trigger's configuration. It ensures that any actions that require automatic retries, based on the trigger settings, are performed as specified. Triggers

Triggers are essential components within the Genius CE & Enterprise platforms, designed to initiate events or actions that facilitate the automation of various processes. By leveraging this functionality, users can efficiently perform specific actions without manual intervention. There are several ways to access and manage triggers, providing flexibility in how users interact with this feature:

• Menu: To access triggers, navigate through the Administration menu by selecting Integrations, followed by Triggers. This pathway serves as the primary interface for managing triggers across different sections of the Genius CE & Enterprise platforms.
• Section-Specific Triggers: In addition to the main menu pathway, users can access triggers directly within specific sections of the platform. These include:
  • Learners -> Triggers: This section contains triggers specifically related to learners or students.
  • Enrollments -> Triggers: Here, you will find triggers associated with enrollment processes.
  • Sections -> Triggers: This area is dedicated to triggers that are specific to various sections.

By utilizing these triggers, users can establish automated workflows that execute predefined actions in response to specific events or conditions. This capability not only streamlines processes but also enhances the overall automation experience within the Genius CE & Enterprise platforms.

To create a new trigger, click the "Add Trigger" button.

Below is a detailed explanation of each field required when setting up a trigger:

• Name: This field is where you will specify the name of the trigger.
• Description: Here, you can provide a brief description of what the trigger is designed to accomplish.
• Object Type: This indicates the type of object that the trigger will operate on. Currently, the available object types include:
  • Enrollment
  • Learner
  • Section
  • RequestedSection
• Trigger Type: This field defines when the trigger event will be executed. The options available are:
  • On Create
  • On Update
  • On Create Or Update
  • On Delete
• Status: This indicates the current status of the trigger, with options to set it as:
  • Active
  • Archived
• Run Actions only the first time criteria are met: Selecting this option ensures that the trigger will only execute once when the requirements are met. If the trigger fails during execution, the user must manually attempt to perform the function again.

Criteria

When you click on "Add Clause," the system will present you with a variety of options to define the criteria for the trigger:

Here’s a breakdown of each field available for setting criteria:

• Field: This refers to the specific field in which the requirements will be applied. All fields available in the object's ViewModel will be displayed for selection.
• Operator: The operator used to validate the criteria. The available 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: This is the specific value that will be used to validate the criteria against the selected field.

To illustrate the usage of criteria, here are some examples:

You have the option to add multiple criteria to a trigger. By default, all specified criteria must be valid (AND) for the action to be executed. This means that when you define multiple criteria for a trigger, all of those conditions must be satisfied at the same time for the trigger to activate and execute the corresponding action. This design ensures that the trigger is only triggered when all specified conditions are met.

Actions

Actions refer to the tasks or operations that can be executed when the defined criteria are met. To initiate the addition of an action, click the "Add Action" button.

Currently, there are three types of actions available for users to choose from:

• Http Request
• Send Email
• Pre-Defined Actions

HTTP Request

The HTTP Request action enables users to configure the details of a Webhook action, which involves making a call to a third-party API. Users can specify the HTTP method, URL, message body, retry behavior, and any additional headers required for the request. This level of flexibility is crucial for integrating and communicating with external systems or services as necessary.

Here’s a detailed explanation of each field in the HTTP Request configuration:

• Method: This refers to the HTTP method that will be employed in the request. The available methods include:
  • GET
  • POST
  • PUT
  • DELETE
• Url: The URL to which the request will be sent.
• Body: This is the message body that will be included with the request.
• Retry Count: This field specifies the number of times the system will attempt the request if an error occurs during the initial attempt.
• Headers: This is a list of key-value pairs that can be included in the request header.

Within the Body field, users can define variables that will be used to construct the request objects. This means you can set up placeholders or variables within the body of the Webhook request, which will be replaced with actual values when the Webhook action is triggered. This dynamic approach allows for the content of the request to be tailored based on specific conditions or data at the time of execution, making the Webhook action highly adaptable to various scenarios and use cases.

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

• The variables should be formatted as "[COURSE_CF.PRODUCT_ID]" to ensure they are replaced with their corresponding values during execution.

It is also possible to use variables in the URL, which will be replaced in the same manner as they are used in the Body.

Here’s an example of a URL that incorporates variables:

Send Email

Send Email functionality enables users to configure the sending of specific emails based on predefined conditions.

Below is an explanation of each field available when setting up an email action:

• To: This field specifies the recipient of the notification.
• CC: Email addresses that will be included in the carbon copy (CC) field.
• Subject: This is the subject line of the email.
• Import Template: This option lists existing templates within the system. When selected, the chosen template will be imported for this notification.
• Body: This field contains the email body that will be sent. Users can select variables from the object's view model to dynamically compose the email body.

Pre-defined Actions

Pre-defined actions are rules that have already been established within the Genius CE & Enterprise platforms to assist users in building their triggers. The available pre-defined actions will vary based on the selected "Object Type." Currently, there is only one option implemented for the "RequestedSection" object type: "Enroll Requested Section."

The framework for pre-defined actions has been structured to allow for future implementations of additional actions for each object type within the system. This design offers scalability and the potential to expand the range of available actions as needed, ensuring adaptability to evolving requirements and workflows.

Post Actions

Post Actions are those that can be executed based on the response received from an HTTP request. When this option is enabled, additional configuration options will appear on the screen for users to set up:

Final Criteria

Final Criteria are used to filter the response of an HTTP Request and determine whether to execute a post action based on the defined criteria.

Here’s a breakdown of each field available for setting up Final Criteria:

• Reference Action: This field allows you to specify the action that will be used to apply the final condition. If no action is selected, the system will apply this condition to all actions of type HttpRequest.
• Field: This refers to the field in which the condition will be applied. The options available include:
  • Always (Force Approval)
  • ResponseBody
• Operator: This field specifies the operator that will be used to validate the criteria. The available options are:
  • Equal To
  • Not Equal To
  • Contains
  • Not contains
  • Is blank
  • Is not blank
• Value: This field specifies the value that will be used to validate the final criteria.

These fields allow you to define conditions based on the response received from an HTTP request, specifying the criteria that will trigger the action you wish to apply. The flexibility provided by these settings allows for precise control over how actions are executed based on the response data.

Final Actions

Final Actions are the tasks that will be executed if the conditions of the Final Criteria are satisfied.

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

For example, based on the result of an API call, you might enroll the student in the requested section.

Logs

Each time a process is triggered, a log entry is created for each action executed. Users can view these logs on the Triggers screen by clicking the following button:

The Logs screen will appear as follows:

On this screen, users can verify the specific details of what was sent in the requests, review the responses received, and examine the payload that was included in the HTTP request.

Furthermore, users can also view the Final Actions executed on this screen.

If a job fails, users have the option to force the re-execution of the trigger by clicking the following button:

Jobs

TriggerJob.ExecutePendingActions

This job is responsible for executing automatic retries according to the trigger's configuration. It ensures that any actions requiring automatic retries, as specified by the trigger settings, are performed as intended.