Org Structure

Overview

ID Dataweb uses a three-level structure: your organization contains one or more subtenants, and each subtenant contains workflows. The IDW team creates your organization during onboarding — you manage everything inside it.

flowchart TD
    O["<b>Organization</b><br/>Your top-level tenant"]
    S1["<b>Subtenant</b>"]
    S2["<b>Subtenant</b>"]
    W1["<b>Workflow</b>"]
    W2["<b>Workflow</b>"]
    W3["<b>Workflow</b>"]
    A1["<b>App ID</b>"]
    A2["<b>App ID</b>"]
    A3["<b>App ID</b>"]
    A4["<b>App ID</b>"]
    A5["<b>App ID</b>"]
    A6["<b>App ID</b>"]

    O --> S1
    O --> S2
    S1 --> W1
    S1 --> W2
    S2 --> W3
    W1 --> A1
    W1 --> A2
    W1 --> A3
    W2 --> A4
    W2 --> A5
    W3 --> A6

The Four Levels

Organization

Your organization is your top-level tenant in the ID Dataweb platform. It is created by the ID Dataweb team during your onboarding and serves as the container for everything — subtenants, workflows, users, billing, and reporting.

All Admin Console users belong to the organization and can be scoped to specific subtenants
Reporting and analytics are available at the organization level across all subtenants
Billing defaults to the organization level; subtenant-level billing is also supported
SSO with your existing identity provider can be configured at the organization level

Subtenants

A subtenant is a logical grouping inside your organization. When your account is provisioned, you receive one default subtenant named after your organization. You can create additional subtenants at any time.

Subtenants are how you separate workflows, reporting, billing, and admin access by use case, team, or customer. Each subtenant has its own set of workflows and its own scope for admin access — a user granted subtenant-level access sees only that subtenant's workflows and data. This means putting workflows into different subtenants is also how you control which Admin Console users can see and manage them. See User Management & Permissions for how to assign users to specific subtenants.

Subtenants inherit organization-level configurations, including authentication settings. Users and auth are managed at the organization level – SSO with your existing identity provider is configured once and inherited by all subtenants.

Subtenant-level configuration details

Billing at the Subtenant level for shared services scenarios
Bills can be created at the organization level or the subtenant level. Each subtenant has a system-generated billing code.

Vanity URLs
Each subtenant can include a white-labeled (vanity) URL – a customer-facing hosted URL that replaces the default platform URL in end-user flows. All workflows under a given subtenant automatically honor its vanity URL.
Vanity URL configuration is not available in Admin 2.0 MVP. This feature is managed through the legacy admin console for the time being.

User access
An organization can configure users to have access to a single subtenant or a specific list of subtenants. Key access rules:
All console data is filtered to show only the subtenants the user has access to
A user can have one role per subtenant, but different roles across multiple subtenants
There is no limit on how many subtenants a user can be assigned to, as long as the user and the subtenants belong to the same organization

Workflows

Workflows live inside a subtenant. Each workflow is one end-to-end verification journey (User Onboarding, Continuous Re-Authentication, etc.) with its own API keys and policy configuration. When a user goes through a verification flow, they are entering a specific workflow within a specific subtenant.

All step-level API keys belong to the workflow's subtenant. Workflows cannot be shared across subtenants.

App IDs

An App ID is a customer-defined string that identifies which application or touchpoint initiated a transaction. If a workflow serves multiple applications or entry points, each one passes its own unique App ID value – and every transaction is tagged accordingly. Unlike organizations, subtenants, and workflows, App IDs are lightweight identifiers rather than objects you configure in the Admin Console. They do not control access or permissions; they are strictly for tracking and reporting segmentation. Common use cases for multiple App IDs on a single workflow:

Distinguishing web vs. mobile transactions
Separating transactions by geography
Tracking transactions from different product lines or user touchpoints

App ID Best practices

Use consistent naming conventions (e.g., web_reset, mobile_signup) Align App IDs to meaningful business touchpoints Avoid overly generic values to ensure reporting clarity

How to Structure Your Org

Most teams start with one subtenant and expand as their needs grow. The right structure depends on how you want to separate use cases, billing, reporting, and access.

You need...	Approach
Simple setup, single use case	One subtenant — everything in one place
Separate account opening from ongoing authentication	Two subtenants, one per use case — independent reporting and billing
Many applications, minimal admin overhead	One subtenant + `appID` to identify each application — filter reporting by app without creating new subtenants
Chargeback or cost allocation by team or department	One subtenant per team — billing and reporting scoped accordingly
Reseller model — customers need isolated access and visibility	One subtenant per customer — customer admins see only their own subtenant

Setup Examples

FunBank — Two use cases, one org

FunBank is a financial institution with a single customer portal that uses ID Dataweb for both new account opening and ongoing login authentication.

They created two subtenants:

Account Opening — contains their User Onboarding workflow. Reporting and billing for new account verification is tracked here separately.
Adaptive Authentication — contains their Continuous Re-Authentication workflow. Login and step-up events are tracked independently from onboarding.

This separation gives their product and finance teams a clean view of costs and transaction volume per use case without any overlap.

GreenCorp — One subtenant, hundreds of apps

GreenCorp is a large enterprise with hundreds of internal applications that all use Continuous Re-Authentication for employee authentication.

Rather than creating a subtenant per application, they use a single Adaptive Authentication subtenant with one Continuous Re-Authentication workflow. Each application passes a unique appID value when calling the API — this lets them filter the Admin Console transaction report by application and run internal chargebacks by department, without any additional workflow or subtenant configuration.

This approach keeps admin overhead low while still providing per-application visibility and cost allocation.

ABC Corp — Reseller model

ABC Corp is a technology provider that resells ID Dataweb verification to multiple downstream customers, each of which needs isolated access and reporting.

They created one subtenant per customer. ABC Corp's internal admins have organization-level access and can see all subtenants. Each customer's admin is granted access only to their own subtenant — they can manage their workflows and view their own transaction data, but cannot see any other customer's configuration or results.

This enforces least-privilege access naturally through the subtenant structure, with no custom access control logic required.