@syndew/oluso-admin-ui 0.0.0-stage → 1.30.1

package/help/en/admin.experience.journeys.builder.md

@@ -0,0 +1,115 @@
+---
+title: Journey Builder
+relatedTopics:
+  - User Journeys | admin.experience.journeys
+  - Plugins | admin.experience.plugins
+  - Data Collection | admin.experience.submissions
+---
+
+The journey builder is a visual editor for creating and editing multi-step authentication and data collection flows. The left panel shows the journey configuration and step list; the right panel shows settings for the selected step.
+
+## Journey Settings
+
+### Basic Properties
+
+- **Name** — identifies the journey in the admin portal and API
+- **Type** — the journey category (Sign In, Sign Up, Data Collection, etc.)
+- **Priority** — lower numbers take precedence when multiple journeys match
+
+### UI Customization
+
+Customize the look of the authentication screens:
+
+- **Theme** — light, dark, or minimal
+- **Login Template** — Standard, Social First, Passkey First, or Combined (Tabs)
+- **Logo URL** — your brand logo
+- **Page Title** — heading text
+- **Primary / Background Color** — brand colors with a color picker
+- **Custom CSS** — override any style with free-form CSS
+
+### Data Collection Settings
+
+Available for data collection journey types (Waitlist, Survey, Contact Form, etc.):
+
+- **Save form submissions** — persist submitted data for review
+- **Require authentication** — users must sign in before submitting
+- **Allow duplicate submissions** — whether users can submit more than once
+- **Max submissions** — cap the total number of submissions (0 = unlimited)
+- **Success redirect URL** — where to send users after submission
+- **Success message** — confirmation text shown on completion
+
+### Embed Settings
+
+Control how the journey can be embedded on external sites:
+
+- **Allowed Origins** — domains permitted to embed the journey (use `*` for all)
+- **Require API key** — protect public access with an API key
+- **API Key** — generate a `pk_` prefixed key for embedding
+
+## Steps
+
+Steps are the building blocks of a journey. They execute in order and can branch based on conditions.
+
+### Step Types
+
+| Category | Steps |
+|---|---|
+| **Authentication** | Sign In, Social Login, Combined Login, MFA, Consent |
+| **User Interaction** | Custom Form, Terms Acceptance, CAPTCHA |
+| **User Management** | User Registration, Password Reset |
+| **Verification** | Business Verification (company registry check or the provider's hosted flow, plus the applicant's right to act for the business; resumes where an earlier attempt left off; branches verified / not verified / pending / provider unavailable; outputs `kyb_status`, `kyb_business_id`, `kyb_applicant_id`, `kyb_business_name`, `kyb_registration_number`, `kyb_country`, `kyb_relationship`) |
+| **Flow Control** | Conditional Logic, Data Transformation |
+| **Logic** | HTTP Request (API Call) |
+| **Plugins** | Custom WASM Plugin |
+
+### Step Configuration
+
+Every step has:
+
+- **Step ID** — unique identifier within the journey
+- **Display Name** — label shown in the builder and optionally to users
+- **Optional** — if checked, the journey continues even if this step fails
+
+### Flow Control
+
+Control what happens after each step:
+
+- **On Success** — which step to go to next (default: next in list)
+- **On Failure** — which step to go to on error (default: fail the journey)
+- **Branches** — named conditional paths for complex routing
+
+### Execution Conditions
+
+Make steps conditional. A step can check journey data, user claims, or context values using operators like equals, contains, starts_with, regex, exists, and more. Combine multiple conditions with AND/OR logic.
+
+## Key Step Types
+
+### Custom Form (DynamicForm)
+
+Build forms with fields of any type — text, email, number, date, select, radio, checkbox, textarea. Each field can:
+
+- Map to a **claim type** for downstream use
+- Be marked **required** with validation rules (min/max length, regex pattern)
+- Be **saved to the user profile** (maps to standard or custom user properties)
+- Include **help text** and **placeholder** guidance
+
+**File upload** fields take documents and photos. Choose the accepted kinds (PDF, JPEG, PNG, HEIC, WebP, GIF), the largest file (MB, 10 by default) and how many files (1 by default). Files are checked by their content, not their name or the type the browser claims, and a file whose name doesn't match its content is refused. They're stored privately with the submission (never at a public URL): the person who uploaded them, and administrators who can read submissions, open them through the signed-in file endpoint. The field's value is the uploaded files' ids. Turn on **Take a photo** to also offer the phone's camera; when the journey is embedded in another site, the host's iframe needs `allow="camera"`.
+
+### API Call
+
+Make HTTP requests to external services during the journey:
+
+- Configure URL, method, headers, and request body with **placeholders** like `{claim:email}` or `{state:userId}`
+- Set authentication (Bearer, Basic, API Key)
+- Map response fields to claims for use in later steps
+- Configure retry logic and error handling
+
+### Conditional Logic
+
+Branch the journey based on data. Evaluate conditions on claims, journey state, or context, then route to different steps based on the result.
+
+## Validation and Saving
+
+- Click **Validate** to check for configuration errors before saving
+- Click **Save** to create or update the journey
+- Validation errors are shown inline if the journey has issues

package/help/en/admin.experience.journeys.md

@@ -0,0 +1,54 @@
+---
+title: User Journeys
+relatedTopics:
+  - Journey Builder | admin.experience.journeys.builder
+  - Data Collection | admin.experience.submissions
+  - Plugins | admin.experience.plugins
+---
+
+User Journeys are configurable multi-step flows that define how users authenticate, register, and interact with your application. They are similar to Azure AD B2C user flows and custom policies.
+
+## Journey Types
+
+### Authentication Journeys
+
+| Type | Purpose |
+|---|---|
+| **Sign In** | Authenticate existing users |
+| **Sign Up** | Register new users |
+| **Sign In / Sign Up** | Combined flow — sign in or register on one screen |
+| **Password Reset** | Self-service password recovery |
+| **Profile Edit** | Let users update their profile information |
+| **Link Account** | Connect an external identity to an existing account |
+| **Consent** | Collect user consent for scopes or terms |
+
+### Data Collection Journeys
+
+| Type | Purpose |
+|---|---|
+| **Waitlist** | Collect interest before launch |
+| **Contact Form** | Gather inquiries from visitors |
+| **Survey** | Collect structured feedback |
+| **Feedback** | Free-form user feedback |
+| **Data Collection** | General-purpose form submission |
+
+## Journey List
+
+The table shows each journey's name, type, status, number of steps, and priority. **Priority** determines which journey is used when multiple match — lower numbers take precedence.
+
+## Global vs Tenant Journeys
+
+- **Global journeys** (globe icon) are system-provided templates. They cannot be edited or disabled directly, but you can **clone** them to create a tenant-specific copy.
+- **Tenant journeys** (building icon) are created by you and fully editable.
+
+Toggle **Show global policies** to include system templates in the list.
+
+## Creating a Journey
+
+Click **Create Journey** to open the journey builder. You will define the journey type, configure its steps, and optionally customize the UI appearance.
+
+## Managing Journeys
+
+- Click a journey row to edit it in the builder
+- Use the **clipboard icon** to clone a global journey
+- Toggle the **status switch** to enable or disable a journey

package/help/en/admin.experience.plugins.md

@@ -0,0 +1,83 @@
+---
+title: Plugins
+relatedTopics:
+  - User Journeys | admin.experience.journeys
+  - Journey Builder | admin.experience.journeys.builder
+---
+
+Plugins are custom WebAssembly (WASM) modules that extend journey functionality with your own business logic. Use them to validate data, enrich user profiles from external systems, integrate with third-party services, or trigger custom workflows.
+
+## Plugin List
+
+The table shows all registered plugins:
+
+- **Plugin** — display name and internal identifier
+- **Scope** — **Global** (system-provided, read-only) or **Tenant** (created by you)
+- **Version** — semantic version number
+- **Size** — compiled WASM file size
+- **Status** — whether the plugin is loaded and ready to execute
+- **Updated** — last modification date
+
+## Uploading a Plugin
+
+Click **Upload Plugin** and provide:
+
+- **WASM File** — the compiled `.wasm` file (max 10 MB)
+- **Plugin Name** — internal identifier (defaults to filename)
+- **Display Name** — human-readable name shown in the admin portal
+- **Description** — what the plugin does
+- **Version** — semantic version (e.g., 1.0.0)
+- **Author** — who created the plugin
+
+## Plugin Details
+
+Click the **info icon** on any plugin to view its full configuration across four tabs:
+
+### Info
+
+Plugin metadata including name, version, author, scope, size, and description. Also shows:
+
+- **Required Claims** — claims the plugin expects as input
+- **Output Claims** — claims the plugin produces
+- **Config Schema** — JSON schema describing the plugin's configuration options
+
+### Hook Bindings
+
+Hooks define **when** a plugin executes. Each hook binds to a domain event:
+
+- **Domain** — the system area the hook targets
+- **Entity Type** — which entity triggers the hook (use `*` for all)
+- **Event Type** — which event triggers the hook (use `*` for all)
+- **Function Name** — the WASM function to call
+- **Order** — execution priority (lower runs first)
+- **On Failure** — whether to **Continue** (ignore errors) or **Reject** (fail the operation)
+
+You can add, edit, enable/disable, and delete hook bindings.
+
+### Network
+
+Control the plugin's ability to make HTTP requests:
+
+| Mode | Description |
+|---|---|
+| **None** | No network access |
+| **Self** | Can only call your own API endpoints |
+| **Whitelist** | Can call specific allowed hosts |
+| **All** | Can call any host (requires approval) |
+
+For Whitelist mode, specify allowed hosts one per line. Configure **timeout** and **max requests per execution** to prevent abuse.
+
+### Executions
+
+View recent execution logs showing when the plugin ran, which event triggered it, how long it took, and whether it succeeded or failed. Use this tab to debug issues.
+
+## Using Plugins in Journeys
+
+After uploading a plugin, add a **Custom Plugin** step in the journey builder. The step will execute your WASM function as part of the journey flow, with access to claims and journey data.
+
+## Tips
+
+- Global plugins cannot be deleted — they are maintained by the system
+- Use the **reload** button to hot-swap a plugin without restarting
+- Start with **None** or **Self** network access and only expand if needed
+- Check the **Executions** tab when debugging plugin issues

package/help/en/admin.experience.submissions.md

@@ -0,0 +1,71 @@
+---
+title: Data Collection
+relatedTopics:
+  - User Journeys | admin.experience.journeys
+  - Journey Builder | admin.experience.journeys.builder
+---
+
+Review and manage form submissions from data collection journeys — waitlists, surveys, contact forms, and other custom forms. The left panel lists your data collection policies; the right panel shows submissions for the selected policy.
+
+## Viewing Submissions
+
+Select a data collection policy on the left to load its submissions. Each policy shows its name, submission count (relative to the max limit), and active/inactive status.
+
+The submissions table displays:
+
+- **Submitted** — when the submission was made (with relative time)
+- **Data Preview** — the first few fields submitted
+- **Source** — country and IP address of the submitter
+- **Tags** — labels applied during review
+- **Status** — the current review status
+
+## Submission Statuses
+
+| Status | Meaning |
+|---|---|
+| **New** | Just received, not yet reviewed |
+| **Reviewed** | Looked at by an admin |
+| **Processing** | Being acted on |
+| **Approved** | Accepted |
+| **Rejected** | Declined |
+| **Follow Up** | Needs further action |
+| **Archived** | Filed away, no longer active |
+
+Change a submission's status directly from the table dropdown or from the detail view.
+
+## Filtering
+
+Use the filter bar to narrow submissions:
+
+- **Search** — free-text search across submitted data
+- **Status** — filter by review status
+- **Date range** — filter by submission date
+
+Click **Apply** to run filters or **Clear** to reset.
+
+## Submission Details
+
+Click the **eye icon** on any row to open the full submission view:
+
+- **Collected Data** — all fields and values submitted
+- **Metadata** — IP address, country, locale, referrer, user agent, device, browser, and OS
+- **Tags** — add, remove, and manage labels. Suggested tags from other submissions appear for consistency.
+- **Notes** — free-text notes for internal review
+- **Review info** — who reviewed it and when
+
+## Bulk Actions
+
+Select multiple submissions using the checkboxes, then use the bulk action bar to:
+
+- **Approve** — mark selected as approved
+- **Reject** — mark selected as rejected
+- **Archive** — move selected to archived
+- **Delete** — permanently remove selected submissions
+
+## Exporting
+
+Click **CSV** or **JSON** in the header to export the current policy's submissions. Exports respect any active filters.
+
+## Journey URL
+
+The **Journey URL** shown in the header is the public link for the data collection form. Click the copy icon to copy it to your clipboard for sharing or embedding.

package/help/en/admin.feedback.detail.md

@@ -0,0 +1,36 @@
+---
+title: Feedback Details
+relatedTopics:
+  - Beta Feedback | admin.feedback
+  - Webhooks | admin.webhooks
+---
+
+View the full details of a feedback submission including the description, metadata, and any attached screenshot.
+
+## Description
+
+The user's full feedback text, exactly as submitted.
+
+## Details
+
+Contextual information captured automatically at submission time:
+
+- **Submitted By** — user name and email
+- **Portal** — Admin or Workspace
+- **Page URL** — the page the user was on when they submitted
+- **Element** — CSS selector of a highlighted UI element (if the user selected one)
+- **Viewport** — the user's screen resolution
+- **Browser** — the user agent string
+
+## Screenshot
+
+If the user captured a screenshot, it is displayed at the bottom of the page. Click the image to view it at full size.
+
+## Updating Status
+
+Click **Update Status** to change the triage state. Available statuses:
+
+- **New** — default for incoming submissions
+- **Reviewed** — you've seen it and are considering action
+- **Resolved** — the underlying issue or request has been addressed
+- **Dismissed** — closed without action (e.g., duplicate, out of scope)

package/help/en/admin.feedback.md

@@ -0,0 +1,42 @@
+---
+title: Beta Feedback
+relatedTopics:
+  - Webhooks | admin.webhooks
+  - Activity Logs | admin.audit-logs
+---
+
+Review and manage feedback submissions from users in every tenant, across both the admin and workspace portals. During beta testing, this page collects bug reports, feature requests, and general notes submitted via the in-app feedback widget.
+
+## Feedback List
+
+The table shows all submissions with:
+
+- **Title** — a short summary of the feedback (camera icon indicates a screenshot is attached)
+- **Category** — Bug, Feature Request, or Note
+- **Status** — current triage status (new, reviewed, resolved, dismissed)
+- **Tenant** - the tenant the user submitted it from
+- **Portal** — whether it was submitted from the Admin or Workspace portal
+- **Submitted By** — the user who submitted the feedback
+- **Date** — when the feedback was submitted
+
+Click any row to view the full details.
+
+## Filtering
+
+Use the dropdowns to narrow results by:
+
+- **Category** — show only bugs, feature requests, or notes
+- **Status** — show only items in a specific triage state
+
+## Statuses
+
+| Status | Meaning |
+|---|---|
+| **New** | Just submitted, not yet reviewed |
+| **Reviewed** | Acknowledged by an admin |
+| **Resolved** | The issue has been addressed or the feature shipped |
+| **Dismissed** | Closed without action |
+
+## Webhooks
+
+When feedback is submitted, a `feedback.submitted` webhook event is fired. Configure a webhook to forward submissions to Slack, email, or your issue tracker.

package/help/en/admin.grants.md

@@ -0,0 +1,42 @@
+---
+title: Grants & Sessions
+relatedTopics:
+  - Users | admin.users
+  - Clients | admin.clients
+  - Activity Logs | admin.audit-logs
+---
+
+Manage persisted grants and active user sessions. This page gives you direct control over the tokens and sessions that keep users authenticated.
+
+## Persisted Grants
+
+Persisted grants are long-lived tokens stored by the authorization server, including refresh tokens, authorization codes, and reference tokens.
+
+The table shows:
+
+- **Type** — the grant type (RefreshToken, AuthorizationCode, ReferenceToken, etc.)
+- **Client** — the application the grant was issued to
+- **Subject** — the user the grant belongs to
+- **Created** — when the grant was issued
+- **Expires** — when the grant will expire
+
+Click **Revoke** to immediately invalidate a grant. This forces the user to re-authenticate with that client.
+
+## Active Sessions
+
+Server-side authentication sessions that track logged-in users.
+
+The table shows:
+
+- **Subject** — the user's identifier
+- **Display Name** — the user's name
+- **Scheme** — the authentication scheme used (e.g., local, Google, OIDC)
+- **Created / Renewed / Expires** — session timestamps
+
+Click **Terminate** to end a specific session, or use this page to audit which users are currently signed in.
+
+## When to Use This
+
+- **Compromised account** — revoke all grants and terminate sessions for a user
+- **Client rotation** — revoke grants for an old client after migrating to a new one
+- **Debugging** — verify that tokens and sessions are being created as expected

package/help/en/admin.identity-providers.detail.md

@@ -0,0 +1,46 @@
+---
+title: Identity Provider Details
+relatedTopics:
+  - Identity Providers | admin.identity-providers
+  - Clients | admin.clients
+---
+
+Configure or view the full settings of an external authentication provider. The form adapts to the selected provider type.
+
+## Basic Information
+
+- **Provider Type** — the protocol (set at creation, cannot be changed)
+- **Scheme Name** — unique identifier used in authentication URLs (set at creation)
+- **Display Name** — label shown on the login page
+- **Enabled** — toggle the provider on or off
+
+## Provider Configuration
+
+Each provider type has specific fields:
+
+- **Google / Microsoft / GitHub / Facebook** — Client ID and Client Secret from the provider's developer console, plus provider-specific options (hosted domain, tenant ID, allowed organizations, etc.)
+- **OIDC** — Authority URL, client credentials, scopes, and optional endpoint overrides for non-standard providers
+- **OAuth2** — Manual endpoint configuration (authorization, token, userinfo) with custom claim mappings
+- **SAML2** — Entity ID, metadata URL, SSO service URL, signing certificate, and security settings
+- **LDAP** — Server address, bind credentials, search base DN, user filter, and attribute mappings
+
+## Proxy Mode (Federation Broker)
+
+Advanced settings for pass-through federation:
+
+- **Proxy Mode** — forward tokens from the external provider without re-issuing
+- **Store User Details Locally** — cache user profile data
+- **Token Pass-through** — include the external provider's access or ID token in your tokens
+- **Claim Filtering** — control which claims from the external provider are included or excluded
+
+## Setup Instructions
+
+Each provider type shows context-specific setup steps, including:
+
+- The **Callback URL** to register with the external provider
+- The **Discovery URL** for OIDC providers
+- **ACS URL** and **Entity ID** for SAML2 providers
+
+## Testing
+
+Click **Test Connection** to verify that the provider is reachable and credentials are valid before enabling it for users.

package/help/en/admin.identity-providers.md

@@ -0,0 +1,39 @@
+---
+title: Identity Providers
+relatedTopics:
+  - Clients | admin.clients
+  - Users | admin.users
+  - Settings | admin.settings
+---
+
+Configure external authentication providers to enable single sign-on (SSO) and social login. Users can authenticate with a third-party identity provider instead of (or in addition to) a local username and password.
+
+## Provider List
+
+The table shows all configured providers with:
+
+- **Provider** — icon, display name, and scheme identifier
+- **Type** — the protocol or service (Google, Microsoft, OIDC, SAML2, LDAP, etc.)
+- **Status** — Enabled or Disabled
+- **Clients** — how many clients are configured to use this provider
+
+Click a row to view or edit the provider's configuration. Use the play/pause button to quickly enable or disable a provider without opening the detail page.
+
+## Supported Provider Types
+
+| Type | Protocol | Use Case |
+|---|---|---|
+| **Google** | OAuth 2.0 | Google Workspace / Gmail users |
+| **Microsoft** | OAuth 2.0 | Azure AD / Microsoft 365 users |
+| **GitHub** | OAuth 2.0 | Developer teams using GitHub |
+| **Facebook** | OAuth 2.0 | Consumer-facing social login |
+| **Apple** | OAuth 2.0 | Apple ID sign-in |
+| **LinkedIn / Twitter** | OAuth 2.0 | Professional / social networks |
+| **OIDC** | OpenID Connect | Any standards-compliant IdP |
+| **OAuth2** | OAuth 2.0 | Custom OAuth providers |
+| **SAML2** | SAML 2.0 | Enterprise SSO (Okta, ADFS, etc.) |
+| **LDAP** | LDAP/LDAPS | On-premises Active Directory |
+
+## Adding a Provider
+
+Click **Add Provider**, select the provider type, and configure the required credentials (client ID, secret, endpoints). Each provider type has its own setup instructions shown on the configuration page.

package/help/en/admin.identity-resources.md

@@ -0,0 +1,47 @@
+---
+title: Identity Resources
+relatedTopics:
+  - API Scopes | admin.api-scopes
+  - Resources | admin.resources
+  - Clients | admin.clients
+---
+
+Identity resources are the OIDC identity scopes — `openid`, `profile`, `email`, `phone`, and any custom scopes you define. Each one declares the set of user claims it releases into the ID token and the userinfo response when a client is granted that scope.
+
+## Resource List
+
+The table shows all configured identity resources with:
+
+- **Name** — the scope name clients request (e.g., `profile`, `email`)
+- **Display Name** — human-readable label shown on consent screens
+- **Status** — Enabled or Disabled
+- **Claims** — the number of user claims this scope releases
+
+Click a row to view or edit the resource.
+
+## Standard scopes and overrides
+
+The standard OIDC scopes have built-in default claim sets (for example `profile` releases `name`, `given_name`, `family_name`, and `picture`). Those defaults apply automatically — you do not have to configure anything.
+
+If you add user claims to a standard scope here, your configured list **replaces** the built-in default for that scope. This lets you tighten or redefine exactly what a standard scope releases.
+
+## Creating a Resource
+
+Click **Add Identity Resource** and provide:
+
+- **Name** (required) — the scope name used in `scope` parameters
+- **Display Name** — what users see on the consent screen
+- **Description** — additional context shown during consent
+- **Enabled** — whether clients can request this scope
+- **Required** — automatically include in every token
+- **Emphasize** — highlight this scope on the consent screen
+- **Show in Discovery** — include in the `.well-known/openid-configuration` document
+
+## User Claims
+
+Use **Edit Claims** to manage which claims the scope releases. Custom claim types resolve from the user's standard profile fields or custom properties; if a user has no value for a claim, it is simply omitted.
+
+## Tips
+
+- Platform claims such as `tenant_id` and `role` are always issued and are not controlled here.
+- Standard OIDC scopes cannot be deleted.

package/help/en/admin.module-seats.md

@@ -0,0 +1,45 @@
+---
+title: Module Seats
+relatedTopics:
+  - Users | admin.users
+  - Roles & Permissions | admin.roles
+  - Subscription | admin.billing.subscriptions
+---
+
+Manage which users have access to each licensed module. Each module enforces its own seat limit based on your subscription, and only users assigned to a module can sign in to its features.
+
+## Module List
+
+The page lists every module enabled for your tenant. Each card shows:
+
+- **Module name** and short description
+- **Seats used** vs **seats licensed** (e.g. 12 / 25)
+- **Status** — whether the module is at capacity or has free seats
+
+Click a module to open its detail view and manage its assigned users.
+
+## Module Detail
+
+Selecting a module reveals:
+
+- **Assigned Users** — users who currently consume a seat on this module
+- **Add User** — search across all tenant users and grant a seat
+- **Remove** — revoke a user's seat (frees it for someone else)
+
+When all licensed seats are taken, **Add User** is disabled until you remove someone or upgrade the plan.
+
+## Adding a User
+
+1. Click **Add User** on the module card.
+2. Search by name or email.
+3. Select the user and confirm. The seat is consumed immediately and the user gains access on next sign-in.
+
+## Removing a User
+
+Click the **Remove** action next to a user, then confirm. The user keeps their account and other module seats — only this module's access is revoked.
+
+## Tips
+
+- Seat counts are enforced at the API layer, not just the UI — a removed user is locked out immediately.
+- If you're at capacity, check **Last Login** in the user list to identify dormant users you can reclaim seats from.
+- Module seat consumption is reflected on the billing **Subscription** page so you can see usage trending into the next renewal.

package/help/en/admin.organizations.detail.md

@@ -0,0 +1,51 @@
+---
+title: Organization Details
+relatedTopics:
+  - Organizations | admin.organizations
+  - Tenants | admin.tenants
+---
+
+Manage a single organization's settings, features, tenants, and members. The detail page is organized into tabs.
+
+## General
+
+Two sections side by side:
+
+- **Identity** — Name, Slug (read-only), Description, and Enabled toggle
+- **Configuration** — Logo URL, Website URL, Max Members, and Max Tenants limits
+
+Changes are saved when you click **Save Changes**.
+
+## Features
+
+A grid of feature cards representing the modules and capabilities available to this organization. Each card shows:
+
+- **Feature name** and description
+- **Granted at / Expires at** dates (if time-limited)
+- **Toggle** to enable or disable the feature
+
+Enabling a feature here makes it available for the organization's tenants to activate. Disabling it hides the feature from all tenants under this organization.
+
+## Tenants
+
+A table of all tenants belonging to this organization, showing Name, Identifier, Status, and Created date.
+
+Click **Add Tenant** to create a new tenant with:
+
+- **Name** and **Display Name**
+- **Identifier** — unique tenant slug
+- **Environment** — Development, Staging, or Production
+- **Description**
+
+Use the settings icon on each row to jump to that tenant's configuration page.
+
+## Members
+
+Organization members are users with administrative access to this organization. The table shows each member's User, Role, and Joined date.
+
+Click **Add Member** and provide:
+
+- **User ID** — the user to add
+- **Role** — Member, Admin, or Owner
+
+Owners have full control over the organization. Admins can manage tenants and members. Members have read access.