Developer GuideMulti-Tenancy
Developer Guide

Multi-Tenancy

Tenant isolation, RBAC, brand access control, feature flags, and subscription management.

Multi-Tenancy

Neostra is built as a multi-tenant platform where each tenant operates in an isolated environment with its own users, data, configurations, and subscription plans. A single user credential can belong to multiple tenants, and access within each tenant is controlled through a hierarchical RBAC model scoped to brands, processes, and sub-processes.

Architecture Overview

Tenant Model

Each tenant represents an isolated organization on the platform. The tenant document stores core identity and configuration fields.

Tenant Fields

FieldTypeDescription
nameStringDisplay name of the tenant organization
activeBooleanWhether the tenant is currently active
domainsList<String>Email domains associated with the tenant
logoStringURL to the tenant logo
subscriptionRefObjectIdReference to the tenant's subscription plan
senderNameStringName shown on outbound emails
senderEmailStringEmail address used for outbound communications

Tenant Settings

Each tenant has a TenantSetting document that controls localization, feature availability, notifications, and DSAR (Data Subject Access Request) configuration.

{
  "supportedLocales": ["en", "de", "fr", "es", "pt"],
  "globalLanguages": ["en", "de"]
}

Neostra supports 58 languages through its i18n system. Each tenant can configure which locales are available to their users and which languages are used for global content like consent banners and privacy notices.

Tenant Isolation

All database queries are automatically scoped to the authenticated user's tenant. The tenantId is extracted from the JWT and applied as a filter condition on every query. There is no cross-tenant data access at the application layer.

Tenant isolation is enforced at the query level. Direct database access bypasses these controls. Always use the application APIs for data access.

Role-Based Access Control (RBAC)

Brand Access Model

Within a tenant, user access is further scoped by a hierarchical model of brands, processes, and sub-processes. Each user has a BrandAccess list that defines exactly which parts of the organization they can interact with.

BrandAccess Structure

{
  "brandAccess": [
    {
      "brandId": "brand-marketing-001",
      "brandName": "Marketing",
      "processes": ["email-processing", "social-media"],
      "subProcesses": ["newsletter", "ad-campaigns"]
    },
    {
      "brandId": "brand-sales-002",
      "brandName": "Sales",
      "processes": ["crm-processing"],
      "subProcesses": ["lead-tracking", "pipeline"]
    }
  ]
}

RBACQueryBuilder

The RBACQueryBuilder automatically applies brand, process, and sub-process filters to database queries based on the authenticated user's access list.

// Internally, RBACQueryBuilder constructs filtered queries:
Query query = RBACQueryBuilder.build(userDetails);
// Equivalent to:
// { tenantId: "tenant-abc", brandId: { $in: ["brand-marketing-001", "brand-sales-002"] } }

Admin users with full access do not have brand-level restrictions. The RBACQueryBuilder detects this and omits brand/process filters for admin roles.

Multi-Tenant User Support

A single UserCredential (email + password) can be associated with multiple tenants. During sign-in, the user receives a list of all tenants they belong to and selects one to receive a tenant-scoped JWT.

User signs in

The sign-in endpoint returns a temporary JWT and a list of all tenants associated with the credential.

Tenant selection

The user selects a tenant. A new Core JWT is issued scoped to that specific tenant, including the user's roles, permissions, and brand access for that tenant.

Switch tenants

To switch tenants, the user repeats the sign-in flow or uses the tenant selection endpoint with a valid temporary JWT.

Subscription Plans

Subscriptions control feature limits and quotas per tenant. The system uses a two-tier plan model.

Plan Tiers

Neostra offers five subscription tiers, each enabling different modules and feature limits.

FeatureStartupBasicGrowthEnterpriseDeveloper
DSAR--IncludedIncludedIncludedIncluded
Consent ManagementIncludedIncludedIncludedIncludedIncluded
Privacy NoticesIncludedIncludedIncludedIncludedIncluded
Assessments------IncludedIncluded
Data Discovery------IncludedIncluded
Data Mapping------IncludedIncluded

The Developer plan is used for internal development and demos. It enables all modules with no limits and is not available to customers.

Plan Fields

FieldDescription
maxUsersMaximum number of users allowed in the tenant
maxBrandsMaximum number of brands
maxAssessmentsAssessment quota
featureGroupsWhich feature groups are included in the plan
storageLimitMaximum file storage in GB
apiRateLimitRequests per minute

Tenant Provisioning

New tenants are provisioned through the astra-core service, which handles the administrative control plane.

Create tenant

Use the TenantController to create a new tenant record with name, domains, and configuration.

Provision resources

The TenantProvisionController initializes the tenant's default data: roles, permissions, default settings, and subscription plan.

Invite initial user

An invitation is sent to the tenant administrator to complete registration and begin configuration.

curl -X POST https://api.neostra.io/v1/admin/tenants \
  -H "Authorization: Bearer <admin_jwt>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "New Organization",
    "domains": ["neworg.com"],
    "senderName": "New Org Privacy",
    "senderEmail": "privacy@neworg.com",
    "subscriptionPlanId": "plan-enterprise-001"
  }'

The initial password provided during provisioning should be reset by the tenant administrator on first login. Never reuse provisioning passwords across tenants.

Feature Flags Reference