Data Domains (Organisational Units)

The first step to land the organization's governance model in Anjana Data is to establish the data domain structure, also referred to as organizational units.

A data domain is the mechanism through which custody and accountability over data assets is established, allowing the organization's reality to be represented in terms of functional or semantic domains. Data assets are classified into these units, and users who perform a governance role in a domain are responsible for the objects that belong to it.

Each data domain also acts as the foundation of the authorization mechanisms, determining which users can exercise which roles over the associated assets.

The structure can be configured in two ways:

• As a flat hierarchy, with a single level.

  

• As a multi-level hierarchy, which allows reflecting different levels of granularity in governance.

  

Once the hierarchy is defined, names must be assigned to each unit according to the organization's governance model.

In Anjana Data, organizational units are configured in the organizational_unit table and will subsequently be available on object creation screens.

The Organizational Unit Table in the Configuration Panel (Administrator View)

Data domains (organizational units) are configured in the Organizational Unit table. Defining these units is an indispensable prerequisite for configuring authorization, i.e., the assignment of roles to users within specific organizational units, which is managed in the User-Ou-Roles table.

Within this table there is a fictitious organizational unit called Cross that allows authorizing users with cross-cutting roles without having to assign the role in each of the existing units. Although this organizational unit is created by the platform itself, it can be deleted and recreated at any time.

Structure of the Organizational Unit table

Each registered organizational unit is characterized by the following fields:

• id_organizational_unit: unique identifier of the organizational unit.

  • It is assigned automatically from the Configuration Panel, based on database sequences.

• description: textual description of the organizational unit.

  • It is an informational and internal field, with no direct functionality within the platform.

• module: purely informational field (legacy, inherited from older versions). It is currently deprecated, although it retains three possible values:

  • "BG" → Business Glossary

  • "DC" → Data Catalog

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

• alias: alias of the organizational unit.

  • Must include the full hierarchy path (example: Parent/Child/ChildOfChild).

  • It is used as a translation key, which allows adding translations in the translations table of the configuration panel using the same config_key as the alias.
    Each of the parts that make up the alias of the organizational unit are concatenated with “/” (for example: Parent/Child/ChildOfChild). This concatenation will be the translation key if you want to display unit names in the different application languages.

    In other words, the Alias must be equivalent to the full hierarchical path from the root node to the organizational unit's own node.

• parent: reference to the alias of the immediate parent organizational unit in the case of a multi-level hierarchy.

  • If the hierarchy is flat or this is a root level, this field is left empty.

  • Only aliases of organizational units that have been previously created can be referenced.

• organizationalUnitType: informational field indicating the hierarchical level to which the organizational unit belongs.

Adding an Organizational Unit to the Organizational Unit table

Adding a new organizational unit (understood as the complete hierarchy, for example Parent/Child/ChildOfChild) involves registering in the Organizational Unit table as many records as the hierarchy has levels (unless some already exist).

To add each record:

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

2. Complete the fields according to the structure described in the previous section.

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

Example: Configuration of the Parent1/Child1/Child1OfChild1 unit

1. First level

   • Module: ALL

   • Alias: Parent1

   • Parent: (empty)

   • Description: (at the administrator's discretion)

   • OrganizationalUnitType: Level 1 (at the administrator's discretion)

2. Second level

   • Module: ALL

   • Alias: Parent1/Child1

   • Parent: Parent1 (select from the dropdown)

   • Description: (at the administrator's discretion)

   • OrganizationalUnitType: Level 2 (at the administrator's discretion)

3. Third level

   • Module: ALL

   • Alias: Parent1/Child1/Child1OfChild1

   • Parent: Parent1/Child1 (select from the dropdown)

   • Description: (at the administrator's discretion)

   • OrganizationalUnitType: Level 3 (at the administrator's discretion)

Modifying an Organizational Unit in the Organizational Unit table

Modification of the Alias and Parent fields should only be done if no objects associated with those organizational units or their descendants exist in the data portal.

If it is necessary to change the hierarchical structure of organizational units that are in use within the data portal, a data deletion must first be performed from the configuration panel menu (Actions > Clear data).

If it is necessary to change the Organizational Unit to which an object belongs, it is recommended to:

Option 1:

Change the translation key for the translation value of the alias in the translations table.

Option 2:

Follow the steps below

1. Create a new Organizational Unit with the new value hierarchy

2. Transfer custody of the objects assigned to the old Organizational Unit using the Organizational Unit change functionality via a user with a Role with CHANGE_OU permissions.

3. Verify whether there are attributes of the Organizational Unit type in any object template. If so, perform a bulk edit using a user with a Role with API_ADMIN permissions to remove the value.

4. Once custody of all objects has been transferred, it is recommended to:

   1. Remove the user authorization in the old Organizational Unit

   2. (Optional) The Organizational Unit can be deleted from the Organizational Unit table

Configuring organizational units via direct database access (Developer View)

The database (DB) table containing the organizational unit configuration has the following structure:

Below is an example script to configure the organizational units for the Spain domain corresponding to the following image:

INSERT INTO zeus.organizational_unit
(id_organizational_unit, alias, description, "module", parent, organizational_unit_type)
VALUES
(7, 'España', 'PAIS: ESPAÑA', 'ALL', NULL, '1'),
(9, 'España/Clientes', 'Dominio Clientes', 'BG', 7, '2'),
(10, 'España/Productos o Servicios', 'Dominio Productos o Servicios', NULL, 7, '2'),
(11, 'España/Finanzas', 'Dominio Finanzas', NULL, 7, '2'),
(12, 'España/Recursos Humanos', 'Dominio Recursos Humanos', NULL, 7, '2'),
(13, 'España/Ventas y Marketing', 'Dominio Ventas y Marketing', NULL, 7, '2'),
(14, 'España/Operaciones', 'Dominio Operaciones', NULL, 7, '2'),
(15, 'España/Proveedores', 'Dominio Proveedores', NULL, 7, '2'),
(16, 'España/Compliance y Legal', 'Dominio Compliance y Legal', NULL, 7, '2'),
(17, 'España/Tecnología y Sistemas', 'Dominio Tecnología y Sistemas', NULL, 7, '2'),
(18, 'España/I+D', 'Dominio I+D', 'ALL', 7, '2');