# Attributes based on Source

Attribute Management in TrustLogix allows organizations to configure user attributes for data access control. 

Entitlement Attribute Management in TrustLogix ensures flexible and scalable attribute creation and mapping. Whether using direct, derived, hierarchical, or recursive hierarchical types, organizations can manage access efficiently.

1. Attribute Source Configuration
2. Creating Attributes with Source Configuration:
   * Direct Mapping Attribute
   * Derived Attribute
   * Hierarchical Attribute
   * Recursive Hierarchical Attribute
3. Creating Attributes Without Source Configuration

> TrustLogix supports separation of duties for attribute management feature.
>
> **User Attribute Administrator** is responsible for **Attribute Source Configuration, Attribute Creation** and **also Attribute Value population**
>
> **Value Manager i**s responsible for **Attribute Value Population**
>
> Ensure the right user is logged in and performing respective activity. The users can be confined to a particular data source by assigning the data source in user administration screen.

### Attribute Source Configuration

#### Attribute Source Configuration is a one-time activity required to define a source for attributes. Any registered TrustLogix account can configure a source from a dimension table (or master table).

#### Steps to Configure a Source:

* Enter the **name** of the connection.
* Select the **data source** from the dropdown list.
* Click **Create Configuration**.
* On the next screen, attributes can be created using this source.

### Creating an Attribute with Source Configuration

#### Steps:

* Select **Target Datasource** and **Data Product**.
* Choose **Attribute Type**.
* Enter **Display Name** and **Description**.
* Select the **Multi-Value** checkbox if applicable.
* Click **Import** to create the attribute.
* Go to **User Attributes** tab to verify the newly created attributes.

#### Direct Mapping Attribute

* Used when the attribute value is **directly mapped** to a column.
* Example: Department Name mapped from a Department Dimension Table.

```sql
CREATE OR REPLACE TABLE DPM_POC.MASTER_DATA.DEPARTMENT (
    DEPARTMENT_ID NUMBER(38,0) NOT NULL,
    DEPARTMENT_NAME VARCHAR(100) NOT NULL,
    PRIMARY KEY (DEPARTMENT_ID)
);
```

* The **Department Name** attribute will be stored as a dropdown list.
* Ensure **TrustLogix users have SELECT access** to the department dimension table.

#### Derived Attribute Type

* Used when an attribute value is obtained by **joining a source column** with a value column in a dimension table.
* Example: Assigning a **Department Name** while storing **Department ID** in a fact table.

```sql
CREATE OR REPLACE TABLE DPM_POC.MASTER_DATA.DEPARTMENT (
    DEPARTMENT_ID NUMBER(38,0) NOT NULL,
    DEPARTMENT_NAME VARCHAR(100) NOT NULL,
    PRIMARY KEY (DEPARTMENT_ID)
);
```

* The **Department ID** is stored in the fact table but resolved to **Department Name** via a join.

#### Hierarchical Attribute Type

* Used when an attribute value is derived from **hierarchical columns** in a dimension table.
* Example: Assigning country access within a geographical hierarchy.

```sql
CREATE OR REPLACE TABLE DPM_POC.MASTER_DATA.GEO_HIERARCHY (
    GLOBAL_ZONE VARCHAR(255),
    CONTINENT VARCHAR(16777216),
    REGION VARCHAR(16777216),
    SUB_REGION VARCHAR(16777216),
    COUNTRY_NAME VARCHAR(16777216),
    COUNTRY_CODE VARCHAR(16777216)
);
```

* The hierarchy is displayed as a **tree structure**, allowing multiple selections.

#### Recursive Hierarchical Attribute Type

* Used when an attribute value is derived from a **recursive hierarchy**.
* Example: Employee reporting structure.

```sql
CREATE OR REPLACE TABLE DPM_POC.HR_DATA.EMPLOYEE (
    EMP_ID NUMBER(38,0) NOT NULL,
    EMP_EMAIL VARCHAR(100) NOT NULL,
    MANAGER_ID NUMBER(38,0),
    MANAGER_EMAIL VARCHAR(100) NOT NULL,
    PRIMARY KEY (EMP_ID),
    FOREIGN KEY (MANAGER_ID) REFERENCES DPM_POC.HR_DATA.EMPLOYEE(EMP_ID)
);
```

* Select **MANAGER\_EMAIL** as **Parent Column** and **EMP\_EMAIL** as **Child Column**.
* This allows an attribute value to be displayed in a **hierarchical tree**.

### Creating an Attribute Without Source Configuration

* Attributes can be created **without a source configuration**.
* The **value screen** will show an input text box for free-form text entry.

#### Steps:

* Click **Add Attribute**.
* Select **Target Datasource** and **Data Product**.
* Enter **Display Name**, **Description**, **Type** and **Group**.
* Select **Multiple Values** checkbox if needed.
* Click **Save**.
* Click **Provision** to push the attribute to the target datasource.

### Associating Attributes with Data Products

When creating an attribute in the TrustLogix platform, it is mandatory to **associate it with a Data Product**. Attributes associated with **"All"** are shared globally across all Data Products.

Each Data Product can maintain its own **distinct set of attributes and a designated Identifier**. These attributes are critical for defining **data access policies** tailored to individual Data Products.

> **Note:** An attribute can be associated with **one or multiple Data Products** based on the access control requirements.

When adding attribute values, the platform uses the selected **attribute and its associated Identifier** to populate the values correctly. This ensures precise mapping and enforcement of policies across different Data Products.

For more information on attribute value population, see [Attribute Value](https://docs.trustlogix.io/attribute-management/attribute-value-management)

### Configuring Identifier attribute

To add attribute values in the TrustLogix App, **one of the attributes must be designated as the Identifier**. This Identifier uniquely distinguishes each entity (e.g., a user, role, or group) and serves as the primary reference point for additional attributes.

Attributes such as **User Name**, **Role Name**, or **Group Name** are commonly used as Identifiers due to their unique and descriptive nature. All other attributes will be treated as supplementary characteristics associated with the Identifier.

To configure an attribute as an Identifier:

* Select the **"Use this as user identifier"** checkbox for the relevant attribute.
* This configuration can be applied during the initial creation of the attribute or updated later by editing an existing attribute.

Designating the correct Identifier is essential for accurate data representation and effective policy enforcement within the TrustLogix platform.

### Overriding Identifier attribute for a data product

In TrustLogix, you can assign different **Identifier attributes** for each **Data Product** to enable precise and context-aware access control. An Identifier uniquely distinguishes a user or entity within the context of a Data Product and plays a critical role in policy definition.

If no specific Identifier is configured for a Data Product, the attribute **"User Name"** (associated with the **"All"** Data Product) will be used as the default Identifier across all Data Products.

#### Example

Let’s consider three Data Products: **HR**, **Finance**, and **Health Care**.

If you do not configure an Identifier for any specific Data Product, the attribute **"User Name"** will be used as the default Identifier across **HR**, **Finance**, and **Health Care**.

However, for the **HR** Data Product, you may want to override this and use **"Employee ID"** as the Identifier since it more accurately reflects the internal HR systems.

To override the default:

> ✅ **Select** the checkbox **“Use this as user identifier”** for the attribute **Employee ID** when creating or editing the attribute.

This approach ensures that each Data Product uses the most appropriate Identifier, enhancing the accuracy and granularity of your data access policies.

> **Note:** Only one attribute can serve as the Identifier per Data Product, and it must be marked accordingly using the **"Use this as user identifier"** option during creation or by editing the attribute.

### Organizing Attributes Using Groups

Attributes in TrustLogix can be assigned to a **Group** during creation or later through updates. Grouping related attributes together provides better organization, especially when managing attributes across multiple data products or use cases.

Grouping attributes based on their function or context enhances usability and consistency. All attributes belonging to the same group are displayed together on the **Attribute Value** page, making it easier for users to populate values efficiently and accurately.

This approach supports streamlined configuration and improved clarity when working with complex attribute sets across different business domains.