Platform Notifications and Workflows

The next step in configuring the governance operating model in Anjana Data is to define the notifications that inform users about events, validation flows (workflows), or platform incidents.

Notifications are a key mechanism for ensuring traceability and communication within data governance, as they alert users or entire roles about actions such as the expiration of an object, the creation of a workflow, an adherence failure, a policy modification, or a license expiration.

In Anjana Data, notifications are configured in the Notifications table of the configuration panel and will subsequently be available in the data portal for affected users.

Table Notifications in the Configuration Panel (Administrator View)

Notifications are configured in the Notifications table of the configuration panel. Defining notifications is an essential step to be able to configure workflows in the BPM and for key users to receive notifications relevant to them.

Structure of the Notifications table

Each notification registered in the table is characterized by the following fields:

• id: unique identifier of the notification (PK).

• moduleType: module to which the notification applies. This is currently an informational (legacy) field inherited from older versions. Possible values:

  • "BG" → Business Glossary

  • "DC" → Data Catalog

  • "ALL" → applies to the entire platform (recommended option).

• notificationCode: alphanumeric code that identifies the notification and allows it to be invoked from the platform's functionalities.

• notificationReceiverType: defines the type of recipient. Possible values:

  • "USER" → the notification is sent to a specific user.

  • "ROLE" → the notification is sent to all users assigned the indicated role.

• translationKey: translation key that links to the message text in the InternalTranslation table. The text can contain variables that will be substituted when the notification is issued.

• notificationType: type of notification. Possible values:

  • "ALERT" → alert

  • "NOTICE" → notice

  • "ADMIN_ALERT" → alert directed at administrators

• receiverRole: recipient role of the notification (if notification_receiver_type is ROLE). Must match the name in the Roles table.

• severity: criticality level of the notification.

• subject: translation key that links to the message text in the InternalTranslation table containing the notification's subject.

• externalSending: allows enabling notification sending through external channels. To activate it, include the keys of the external providers separated by commas. For example, to send to the available providers: EMAIL, SLACK, MICROSOFT_TEAMS, GOOGLE_CHAT. If empty, it will not be sent to any external provider. See the list of available providers.

Notification codes (notificationCode)

For the application to function correctly, the Notifications table must contain records that correspond to a series of predefined notificationCode values.

Variables for the Key of InternalTranslation as part of the notification body

Additionally, the bodies of notification messages defined via translation keys (Key field of the Translations table) can contain dynamic variables delimited by ##. These variables will be automatically replaced with the corresponding values when the notification is generated and sent.

For example:

"An error occurred while deleting the workflow with id #OBJECT_ID#".

If a variable is included in a message where it has no applicable value, it will be replaced with N/A.

The following are the different variables supported by Anjana Data for use in notifications:

Native notifications

Anjana Data natively includes a large number of ROLE-based notifications to cover the main data governance events (creation, deletion, expiration, workflows, errors, etc.).

It is the responsibility of the functional administrator to correctly configure the receiver_role field in each notification, so that messages reach the appropriate stakeholders according to the governance operating model defined by the organization.

An incorrect or incomplete assignment can cause users not to receive critical alerts or, conversely, to be overloaded with notifications that do not apply to them.

Creating a new Notification in the Notifications table

Creating a new notification (for example, an alert to validate a workflow step) involves:

1. Adding a record in the Notifications table with the notification's basic data.

2. Configuring the translation keys associated with the notification (translationKey and subject) in the InternalTranslation table, for all the languages used by the organization in Anjana Data (Languages table).

To add the record in the Notifications table and create a new notification:

1. Click the New button in the top-right corner. This will open a wizard with the fields defined in the Structure of the Notifications table section.

2. Fill in the notification fields according to the structure described in the previous section.

3. Click Save to save the notification or Cancel to discard it.

Configuring translations for notifications

Once the notification has been created in the Notifications table, the texts the user will receive must be defined: the message body (translationKey key) and the subject (subject key), in each of the languages configured on the platform.

This configuration is done from the Administration Portal, in the Internationalization section, accessible from the Data Portal's navigation menu.

For each notification, a translation is created for both the body and the subject, filling in the following fields:

• Key: must match the value defined in the notification (translationKey for the body and subject for the subject).

• Usage: descriptive text that helps identify that the translation corresponds to a notification. It is recommended to define a naming standard to maintain a common reference vocabulary.

• Language (English and other configured languages): text that the user will receive according to the language set in their profile.

The message body supports dynamic variables delimited by # (for example, #OBJECT_ID#), as described in previous sections.

Modifying a Notification

Modifying the subject or body of a notification has no impact on the configuration, as long as the translation keys (translationKey or subject) are not altered. In that case, it is enough to update the text for the corresponding language, from the Internationalization section of the Administration Portal, using one of these two options:

• Direct editing of the text in the editable field.

• Editing via wizard: clicking the pencil icon opens a wizard that allows editing the texts in the different languages.

If, on the other hand, it is necessary to modify the translation keys (translationKey or subject), the changes must be applied both to the notification (Notifications table) and to its translations.

Querying and using notification data in the database (Developer View)

In addition to being configured from the configuration panel, notification information is stored in the database and can be queried in read-only mode for analytical purposes. For example, it allows the client to build their own data mart, dashboards, or reports on their platform's notification configuration (which events are notified, to which roles, with what criticality, through which channels, etc.).

Table hermes.notification

The configuration of each notification is stored in the hermes.notification table. Its columns, available for querying, are:

Related tables for enriching queries

To get a more complete view, the notifications table can be joined with other tables in the model:

• InternalTranslation: contains the text of the body and subject of each notification per language. It is joined by linking translation_key and subject with the table's key field, filtering by the desired language (language field). Allows retrieving the final message seen by the user.

• Roles: allows resolving the receiver_role with the recipient role's details (linking with its name field).

• Languages: list of languages configured on the platform, useful for narrowing text queries by language.

Query examples

Full list of configured notifications, with their type, recipient, and criticality:

SELECT id_notification,
       module_type,
       notification_code,
       notification_receiver_type,
       receiver_role,
       notification_type,
       severity,
       external_sending
FROM hermes.notification
ORDER BY id_notification;

Notifications directed at a specific role:

SELECT notification_code, notification_type, severity
FROM hermes.notification
WHERE notification_receiver_type = 'ROLE'
  AND receiver_role = 'DataOwner';

Count of notifications by module and type (useful as a metric for a data mart):

SELECT module_type,
       notification_type,
       COUNT(*) AS total
FROM hermes.notification
GROUP BY module_type, notification_type
ORDER BY module_type, notification_type;

Notifications with external channel sending configured:

SELECT notification_code, notification_type, external_sending
FROM hermes.notification
WHERE external_sending IS NOT NULL
  AND external_sending <> '';