How To Add a Common Events on DCM Case
A Common Event is a mechanism for executing standard or custom logic at various stages of a Case's lifecycle. For example, the ability to send an email every time a Case is assigned, or validate that all information is correct before creating a Case.
Configuring a Common Event
Common Events for Case Types are configured in the DCM Setup by navigating to DCM Setup → Case Setup → Case Types → select a Case Type → Common Events tab
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 Case's lifecycle (Discussion context is included):
| Context | Moment | Description |
|---|---|---|
| CASE | Create Case | This occurs when a new Case I created by a user or by an application. |
| CASE | Update Case Data | This occurs when a user clicks "Save" in the Case Info tab when updating a Case. |
| CASE | Assign Case | Case Assign occurs on its own when a user clicks a button, when a Case is assigned, or when a Case is routed. |
| CASE | Route Case | This event happens when a Case is routed through the Milestone diagram. |
| CASE | Delete Case | This occurs when a user deletes a Case in Case Monitor. |
| Context | Moment |
|---|---|
| DISCUSSION | Create Thread |
| DISCUSSION | Create Thread Comment |
| DISCUSSION | Modify Thread |
| DISCUSSION | Modify Thread Comment |
| DISCUSSION | Delete Thread |
| DISCUSSION | Delete Thread Comment |
| DISCUSSION | Thread people joined |
| DISCUSSION | Thread people removed |
Types of Common Events
The actions to be executed can be any of the following lists:
- Assign Case
- Change Case Priority
- Execute Rule
- Send Email
- Send Email (legacy)
- Route to Genesys Cloud
- Route to Genesys Engage
- Route to PureConnect
- Send SMS with Twilio
- Send to Slack Channel
- 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 get executed. If any of the validation rules returns an error, then the user will not be able to 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 as 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 as 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.
| Moment | SQL NonQuery Function | SQL NonQuery | C# |
|---|---|---|---|
| AFTER - ACTION | YES | YES | YES |
| BEFORE - ACTION | YES | NO | NO |
| BEFORE - VALIDATION | YES | NO | NO |