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 workflows, or incidents on the platform.

Notifications are a key mechanism to ensure 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, the modification of policies, or the expiration of a license.

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

Notifications Table in the Configuration Panel (Administrator View)

Notifications are configured in the Notifications table of the configuration panel. Defining notifications is an indispensable step to configure workflows in the BPM and to ensure that key users receive notifications of interest.

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. 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 platform features.

• 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.

• traslationKey: translation key that links to the message text in the Translations table. The text may contain variables that will be substituted at the time the notification is issued.

• notificationType: type of notification. Possible values:

  • "ALERT" → alert

  • "NOTICE" → notice

  • "ADMIN_ALERT" → alert directed to administrators

• receiverRole: recipient role of the notification (if the 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 Translations table containing the subject of the notification.

Notification Codes (notificationCode)

For the application to function correctly, the Notifications table must contain records corresponding to a set of predefined notificationCode values.

 Variables for Key in Translations as Part of the Notification Body

Additionally, notification message bodies defined through translation keys (the Key field in the Translations table) may contain dynamic variables delimited by ##. These variables will be automatically replaced by the corresponding values at the time the notification is generated and sent.

For example:

"Ocurrió un error en el borrado del workflow con id #OBJECT_ID#".

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

The following details the various variables that Anjana Data supports for use in notifications:

 Native Notifications

Anjana Data natively incorporates 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 may cause users not to receive critical alerts or, conversely, to be overloaded with notifications that do not concern them.

Adding a New Notification to the Notifications Table

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

1. Adding a record to the Notifications table with the basic notification data.

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

To add the record to the Notifications table and register a new notification:

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

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

3. Click Save to save the role or Cancel to discard.

Translation Configuration for Notifications

Once the notification has been created in the Notifications table, it is necessary to add records to the Translations table for the message body (translationKey) and the subject (subject) in the different languages configured in the application.

The procedure is as follows:

1. Notification body (translationKey)

   • For each notification and for each language registered in the Languages table, a record must be created in the Translations table.

   • In the key field, the translationKey defined in the notification will be used.

   • In the value field, the body text of the message in the corresponding language (the language field) will be included.

   • The message body may include dynamic variables delimited by ## (example: #OBJECT_ID#).

2. Notification subject (subject)

   • For each notification and for each language registered in the Languages table, an additional record must be created in the Translations table.

   • In the key field, the subject key defined in the notification will be used.

   • In the value field, the subject text in the corresponding language (the language field) will be included.

Modifying a Notification

Modifying the subject or body of a notification has no impact on the configuration, as long as the translation keys are not altered, i.e., the translationKey or the subject. In this case, only the content of the value field in the corresponding records of the Translations table needs to be modified.

Conversely, if it is necessary to modify the translation keys (translationKey or subject), changes must be applied in both the Notifications table and the Translations table.

Configuring Notifications via Direct Database Access (Developer View)

The database (DB) table containing the notifications parameters has the following structure:

Below is an example query to configure the notifications associated with the DPO role:

INSERT INTO hermes.notification
(id_notification, module_type, notification_code, notification_receiver_type, translation_key, notification_type, receiver_role, severity, subject)
VALUES
(1,  'BG', NULL, 'ROLE', 'NOTIFICATION.1.BG.ROLE', 'ALERT', NULL, 'HIGH', 'NOTIFICATION.SUBJECT.ACTION.MUST.BE.VALIDATED'),
(3,  'BG', NULL, 'ROLE', 'NOTIFICATION.3.BG.ROLE', 'NOTICE', NULL, 'LOW',  'NOTIFICATION.SUBJECT.ACTION.PERFORMED'),
(5,  'BG', NULL, 'USER', 'NOTIFICATION.5.BG.USER', 'NOTICE', NULL, 'LOW',  'NOTIFICATION.SUBJECT.ACTION.PERFORMED'),
(6,  'BG', NULL, 'ROLE', 'NOTIFICATION.1.BG.ROLE', 'ALERT', NULL, 'HIGH',  'NOTIFICATION.SUBJECT.ACTION.MUST.BE.VALIDATED'),
(7,  'DC', NULL, 'ROLE', 'NOTIFICATION.7.DC.USER', 'ALERT', NULL, 'HIGH',  'NOTIFICATION.SUBJECT.ACTION.MUST.BE.VALIDATED'),
(8,  'DC', NULL, 'USER', 'NOTIFICATION.8.DC.USER', 'NOTICE', NULL, 'LOW',  'NOTIFICATION.SUBJECT.ACTION.PERFORMED'),
(9,  'DC', NULL, 'USER', 'NOTIFICATION.ACTION.REJECTED.WITH.REASON', 'NOTICE', NULL, 'LOW', 'NOTIFICATION.SUBJECT.ACTION.REJECTED.WITH.REASON'),
(10, 'DC', NULL, 'ROLE', 'NOTIFICATION.10.DC.ROLE', 'NOTICE', NULL, 'LOW',  'NOTIFICATION.SUBJECT.ACTION.APPROVED'),
(11, 'DC', NULL, 'ROLE', 'NOTIFICATION.11.DC.ROLE', 'NOTICE', NULL, 'LOW',  'NOTIFICATION.SUBJECT.ACTION.REJECTED'),
(12, 'BG', 'NEW_DSA', 'ROLE', 'NOTIFICATION.NEW_DSA', 'NOTICE', 'data_architect', 'LOW', 'NOTIFICATION.SUBJECT.NEW.DSA'),
(13, 'BG', 'EXPIRATION', 'USER', 'NOTIFICATION.EXPIRATION', 'NOTICE', NULL, 'LOW', 'NOTIFICATION.SUBJECT.EXPIRATION'),
(14, 'DC', 'ERROR_AUTOMATIC_METADATA', 'ROLE', 'NOTIFICATION.AUTOMATIC_METADATA', 'NOTICE', 'DataSteward', 'LOW', 'NOTIFICATION.SUBJECT.METADATA'),
(15, 'DC', 'DATASET_FAIL', 'ROLE', 'NOTIFICATION.DATASET_FAIL', 'ADMIN_ALERT', 'DataOwner', 'HIGH', 'NOTIFICATION.SUBJECT.CREATION.FAIL.DATASET'),
(16, 'DC', 'DSA_FAIL', 'ROLE', 'NOTIFICATION.DSA_FAIL', 'ADMIN_ALERT', 'DataOwner', 'HIGH', 'NOTIFICATION.SUBJECT.CREATION.FAIL.DSA');