# Tenancy

## Overview

#### 🏙️ What is a Tenant in DIGIT?

A **tenant** in DIGIT is a **logical container** that isolates and manages data and configurations for an administrative unit such as a **city, department, or state**. It ensures **data isolation**, **independent configurations**, and **secure multi-tenancy** even when all tenants are hosted on the same DIGIT instance.

#### 🔹 What Does a Tenant Isolate?

<table><thead><tr><th width="225.4375">Type</th><th>Examples</th></tr></thead><tbody><tr><td>Reference Data</td><td>Service types, boundaries</td></tr><tr><td>Configuration Data</td><td>Workflows, SLAs</td></tr><tr><td>Transactional Data</td><td>Complaints, user records, audit logs</td></tr></tbody></table>

***

#### 🔹 Hierarchical Multi-Tenancy (DIGIT 2.9 LTS)

DIGIT supports a **hierarchical tenant structure**, allowing inheritance of data and configuration.

**Example Tenant Hierarchy**:

```
State: StateA
├── CityA → tenantId: statea.citya
├── CityB → tenantId: statea.cityb
└── CityC → tenantId: statea.cityc
```

Each tenant can:

* Use its own master/config data.
* Inherit from the parent tenant (e.g., state-level).

***

## Example Tenancy&#x20;

* **State-level tenant**: e.g., `statea`
* **City-level tenants**: e.g., `statea.citya`, `statea.cityb`

Each tenant has metadata:

* Contact info, address, logo
* District, ULB grade, region
* Coordinates (latitude/longitude)

{% hint style="info" %}
📌 **Tenants ≠ Boundaries**\
Tenants can also represent ministries, departments, or agencies, not just geographical units.
{% endhint %}

{% hint style="info" %}
Tenancy needs to be decided based on the use-case. The sample data for the product comes with a two level hierarchy. This need not be followed for implementations.
{% endhint %}

***

## Tenant Isolation in API Requests

<table><thead><tr><th width="210.59765625">Aspect </th><th>Detail</th></tr></thead><tbody><tr><td>Tenant ID</td><td>Must be passed in every API request (e.g., <code>statea.citya</code>)</td></tr><tr><td>Validated By</td><td>Gateway Service</td></tr><tr><td>Scope of Data Access</td><td>Only within that tenant — no cross-tenant access permitted</td></tr><tr><td>Defined In</td><td><code>tenants</code> master (MDMS module)</td></tr></tbody></table>

***

## External Integrations

* Always **maintain the tenant context** when integrating with 3rd-party systems.
* If external systems lack multi-tenancy support, **handle tenant-specific routing carefully**.

***

## Summary

<table><thead><tr><th width="193.9140625">Feature</th><th>Purpose/Detail</th></tr></thead><tbody><tr><td>Tenant ID</td><td>Identifies the tenant (e.g., <code>pg.citya</code>)</td></tr><tr><td>Scope</td><td>Data, configuration, workflows are tenant-bound</td></tr><tr><td>Defined In</td><td><code>tenant</code> module → <code>tenants</code> master (MDMS)</td></tr><tr><td>Required In APIs</td><td>All requests must include <code>tenantId</code></td></tr><tr><td>Validated By</td><td>Gateway Service</td></tr></tbody></table>

***