Notifications
The notification system in MTG CLM is a fine-tuned and decoupled mechanism which enables the functionality of sending custom notifications.
It stands as a complementary module to the broader MTG CLM ecosystem and operates in parallel to existing CLM PKI operations, without interfering with or adding unwanted delay to them. MTG CLM’s notification architecture addresses three critical problems that affect traditional certificate management: configuration rigidity, system unreliability, and limited administrative control.
Traditional notification systems cannot adapt notification timing, recipients, or formats to organizational needs. When notifications fail in conventional systems, they are lost forever, creating gaps in certificate lifecycle awareness. MTG CLM transforms this landscape by providing highly configurable notification management with fault-tolerant delivery that ensures critical certificate events reach their intended recipients.
Notification Architecture
MTG CLM’s notification system operates through three distinct layers, each designed to address specific organizational needs and permission structures.
User-Controlled Subscriptions
Users subscribe themselves to realms and policies they have permission to view, maintaining complete control over their notification preferences. This mode enables individual users to take ownership of their certificate awareness without requiring administrative intervention.
User Control Features:
-
Subscribe to any accessible realm or policy.
-
Configure notification channels and preferred language in contact details.
-
Edit subscription event types.
-
Delete subscriptions that are no longer required.
Default Protection: All users automatically receive email notifications for events tied to certificates they have requested, ensuring critical personal certificate events are never missed even without explicit subscription setup. This means that users choose for which events tied to their certificates they get notified. This can be either all events or a more specific / limited event subset.
Administrative User Management
Administrators subscribe users to relevant realms and policies, ensuring critical notifications reach the right recipients even when users haven’t configured their own subscriptions. This mode addresses organizational requirements where certificate management responsibilities are assigned by administrators rather than chosen voluntarily by users.
Administrative Capabilities:
-
Subscribe other users based on permission hierarchy.
-
Manage subscriptions for users within administrative realm scope.
-
Edit and delete user subscriptions while maintaining proper permission boundaries.
-
Ensure comprehensive notification coverage across teams and departments.
External Entity Integration
Administrators can configure external recipients for organizational-wide certificate management, extending notification reach beyond internal users. External entities represent email groups, emails, or any recipient grouping that requires certificate lifecycle awareness.
External Integration Features:
-
Administrations can configure external recipients (e.g, e-mail, e-mail lists).
-
Channel types and preferred language settings are configurable within contact details.
-
Full administrative control is maintainable over external subscription management.
Fault-Tolerant Delivery System
Unlike traditional certificate management approaches, MTG CLM’s notification system provides reliable delivery with automatic retry mechanisms. When notification delivery fails, the system queues notifications for later delivery rather than abandoning them entirely. This fault-tolerance ensures that critical certificate events reach their intended recipients even during temporary system outages or connectivity issues.
Migration Experience
Organizations transitioning to MTG CLM’s enhanced notification system experience no disruption to existing workflows. Users continue receiving familiar notifications through the already present system infrastructure during transition periods. The new notification architecture operates alongside existing mechanisms, allowing gradual adoption without operational risk.
Subscription Management
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:
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
-
CERTIFICATE_REQUEST_APPROVED**
-
CERTIFICATE_REQUEST_DECLINED**
-
CERTIFICATE_CREATED**
-
CERTIFICATE_IMPORTED
-
CERTIFICATE_EXPIRING**
-
CERTIFICATE_REVOKED**
-
-
Non-subscribable
-
CERTIFICATE_ATTACHMENT
-
CERTIFICATE_REQUEST_PENDING_EMAIL_VERIFICATION
-
-
| On top of "subscribable" some events may also be "periodical". 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 either choose to further configure all event types or a subset of them, according to their specific needs. |
- 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. |