Notifications
This page provides technical details for configuring and managing MTG CLM’s notification system, including subscription management, contact configuration and event handling.
Understanding Subscriptions
Realm vs Policy Subscriptions
Subscriptions can be configured at two levels with different notification scope:
- Realm Subscriptions
-
Subscribe to all certificate events within an entire realm. Since realms contain multiple policies, this provides broad coverage for all certificates issued using any policy within that realm.
- Policy Subscriptions
-
Subscribe to certificate events for a specific policy within a realm. This provides targeted notifications only for certificates issued using that particular policy.
The subscription process is identical for both levels; the only difference is the scope of events you receive. Policy subscriptions offer more granular control when you need notifications for specific certificate types or use cases.
Subscription Management
User Self-Subscriptions
Users can subscribe themselves to any realm or policy they have permission to view.
User actions:
-
Subscribe to realms or policies
-
Configure notification channels and language preferences
-
Edit subscription event types
-
Delete subscriptions when no longer needed
Default behavior: All users automatically receive email notifications for certificates they have requested.
Administrative User Management
MTG CLM Administrators can subscribe other users based on organizational requirements and permission hierarchies.
Administrative actions:
-
Subscribe users to realms or policies
-
Manage existing user subscriptions
-
Edit and delete user subscriptions within permission boundaries
-
Ensure comprehensive notification coverage across teams
For users with elevated permissions, MTG CLM provides sophisticated tools to orchestrate notifications across your organization, managing both application users and external recipient contacts with precision and security.
Permission-Based Subscription Architecture:
Contact Management
Notification Channels
Notification System Components
The MTG CLM notification system consists of the following business entities interacting with each other:
- Notification Channel Types
-
Defines the different types of supported notifications.
- Notification Event Types
-
Defines the events that may lead to a notification being sent. There are two event types :
Subscribable:
- CERTIFICATE_REQUEST_PENDING_APPROVAL
-
Triggered when a new certificate request is submitted but the associated policy requires manual authorization, placing the request in a holding state (
PENDING_APPROVAL) until an authorized party acts upon it. - CERTIFICATE_REQUEST_APPROVED**
-
Triggered when an authorized party manually reviews and approves a pending certificate request, moving its status to
APPROVED. - CERTIFICATE_REQUEST_DECLINED**
-
Triggered when an authorized party manually rejects a pending certificate request, moving its status to
DECLINEDand ensuring no certificate is generated. - CERTIFICATE_CREATED**
-
Triggered the moment a certificate is successfully generated (resulting in the
ISSUEDstatus), either automatically or following an approval/verification process. - CERTIFICATE_IMPORTED
-
Triggered when an existing, externally generated certificate is successfully imported into MTG CLM.
- CERTIFICATE_EXPIRING**
-
Triggered when an active certificate approaches the end of its validity period, acting as a proactive alert to begin the renewal process before the certificate becomes invalid.
During subscription you must set the Days Before Expiration value: you will then be notified on the value of days provided, throughout which the certificate is not renewed.
If multiple values are selected and the certificate does not get renewed in the meantime, a recurring notification will be triggered.
For example, if values 30,15,5,2 are chosen, you will get notified 30 days before expiration, if no renewal has been made by then.
Then, by day 15, if no renewal still has not been made, you will get notified again and so on.
In this context, a successful certificate renewal is considered the creation of a new certificate for the same end entity under the same policy.
|
- CERTIFICATE_REVOKED**
-
Triggered when a previously active certificate is invalidated before its natural expiration date, meaning the certificate should no longer be trusted.
Non-subscribable
- CERTIFICATE_ATTACHMENT
- CERTIFICATE_REQUEST_PENDING_EMAIL_VERIFICATION
| On top of "subscribable" some events may also be "variant". When providing these event types, additional data dictating that period are required. |
**Implicit Notifications: Users can be notified for status changes in a certificate they requested without explicitly subscribing to it. Users can choose to further configure all event types or a subset of them, according to their specific needs.
By default, for Users new to CLM, their implicit notification event types are set according to a system-wide preconfigured default. This default can be further configured by updating the global configuration with key IMPLICIT_NOTIFICATIONS_DEFAULT_EVENT_TYPES
|
- Notification Languages
-
Defines the language being used in template details. The available languages are:
-
English - en
-
German - de
-
- Notification Templates
-
Defines the contents of a notification. You can find out more here
- Contacts
-
Contains recipient details.
- Notification Subscriptions
-
Contains the subscription details.
- Notifications
-
Contains every data needed to attempt to deliver the notification.
Notification Related Properties
Property |
Description |
|
Defines how many times the notification creation jobs will execute in case of failures. |
|
The interval, in hours, between a failed execution of a notification creation job, and the next execution of it. |
|
Defines how many times the notification processing jobs will execute in case of failures. |
|
The interval, in hours, between a failed execution of a notification processing job, and the next execution of it. |