Skip to main content
Skip table of contents

Common Events on Procedures

A Common Event is a mechanism for executing standard or custom logic on injecting or inserting ad-hoc procedures. For example, the ability to send an email every time a Procedure is injected. Or to validate that all information is correct before a Task will be created.


When are Common Events Executed

A Common Event can be an ACTION or a VALIDATION. They can be fired BEFORE or AFTER the following moments in a Create/Update/Delete Entity operation:

ContextMoment
PROCEDUREInject Adhoc Procedure
PROCEDUREInsert Adhoc Procedure

Type of Actions

The actions allowed to be executed are:

  • Assign Case
  • Change Case Priority
  • Execute Rule
  • Send Email
  • Send SMS with Twilio
  • Write to History

Overview of Custom Rules for Common Events

The most popular use case for Common Events is to execute some sort of custom logic either to validate a user action or to do additional processing after the action has been completed.

Below is an example of how Common Events work for the Create Case process. Similar to all Common Events, the order that they get executed can be diagrammed below.


First any VALIDATION custom rules gets executed. If any of the validation rules returns an error, then the user will not be able to the create a Case and the user will see an error message on their screen.

Second any ACTION - BEFORE custom rules get executed. All custom rules deployed as SQL FUNCTIONs will execute synchronously. All NON-SQL FUNCTION rules such a C# or SQL NonQuery will execute through the AppBase Queue asynchronously. Errors are suppressed.

Third the actual process of Case Create occurs.

Fourth any ACTION - AFTER custom rules get executed. All custom rules deployed as SQL FUNCTIONs will execute synchronously. All NON-SQL FUNCTION rules such a C# or SQL NonQuery will execute through the AppBase Queue asynchronously. Errors are suppressed.

Supported custom rule types

Not all types of rules are supported for every type of Common Event. For example, a VALIDATION rule can only be an SQL FUNCTION. While an ACTION can be any type of AppBase rule. 

An SQL FUNCTION will always execute synchronously, while all other rule types will execute through the AppBase Queue asynchronously. 

MomentSQL NonQuery FunctionSQL NonQueryC#
AFTER - ACTION

YES

YES

YES

BEFORE - ACTION

YES

NO

NO

BEFORE - VALIDATION

YES

NO

NO

Steps

  1. On the top right, navigate to 
    → <<your solution>>
  2. On the left, navigate to 
     → Setup
  3. Navigate to Case Setup → Case Types (1)
  4. Select and open a Procedure to edit using the hyperlink under the column Procedure.
  5. Navigate to the Common Events tab (2).
  6. Click the Add Common Event button to add a new event.
  7. In the pop-up window, enter the configuration of the event.
    1. Purpose: Indicate the purpose of the event. In our example, Action - Execute Rule.
    2. Moment: Select the Moment based on the table above. In our example, Before.
    3. When: Select when the event is triggered. In our example, Insert Adhoc Procedure.
    4. Action or Validation: Indicate if the event is an Action or Validation. In our example, Action.
    5. Event Type: Select the Execute Rule.
    6. Rule: Select the rule from the drop-down list. If needed, add the parameter(s) for the rule.
  8. Save the new event.
  9. If there is more than one event, select the order for the execution(s) using the arrows at the left of the event.


JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.