TestInspector multi-tenant organization model separates test suites, variables, and execution permissions by organization boundary, with three distinct roles - owner, admin, and member - that control who can create, edit, run, or delete tests and configure org-level settings. Each organization maintains its own encrypted variable store with a three-level hierarchy (test, suite, org) so that credentials and secrets are never shared across organizations inadvertently. This structure is designed for two common scenarios: software consultancies that test on behalf of multiple clients who each require data isolation, and product engineering teams where multiple squads share the same platform but need independent environments for their services.

This guide explains how the TestInspector organization model is architected, what each role can and cannot do, how variable scoping works in team contexts, and practical patterns for structuring organizations and test suites across large QA teams. If you are evaluating whether TestInspector fits your team access control requirements, the role matrix and variable hierarchy sections provide the clearest comparison points.

How TestInspector Organization Model Works

An organization in TestInspector is the top-level boundary for all resources: tests, test suites, variables, scheduled runs, and user memberships. Every user account can belong to multiple organizations simultaneously, and switching between organizations gives access to a completely separate set of tests and configuration. There is no cross-organization visibility by default - a member of Organization A cannot see or execute tests owned by Organization B, even if they share the same email domain.

Within an organization, tests are grouped into suites. Suites serve two purposes: logical grouping for execution ordering and variable inheritance. A test can belong to exactly one suite, and a suite belongs to one organization. Execution permissions follow this hierarchy - a user who can run a suite can run all tests within it, subject to their role-level permissions.

Scheduling and CI/CD trigger endpoints are also organization-scoped. The API token used to trigger runs via the CI/CD API belongs to a specific organization, which means a token generated for one client org cannot accidentally execute tests in another client org. This boundary enforcement is particularly relevant for software testing teams managing parallel client projects with strict data separation requirements.

Understanding Owner, Admin, and Member Role Permissions

TestInspector uses three roles at the organization level. Each role is a fixed permission set applied to all tests and suites within the organization. There is no per-suite or per-test role assignment - role scope is always the entire organization.

The owner role is assigned to the account that creates the organization and cannot be revoked as long as the owner remains the sole owner. An organization can have at most one owner at any time; transferring ownership requires the current owner to promote another admin to owner, which automatically downgrades the previous owner to admin.

The admin role is suited to senior QA engineers and team leads who need to create and maintain the test library but should not be able to restructure the organization membership hierarchy or delete the organization. Admins can do everything except change member roles above their own level and delete the org.

The member role is a read-and-run permission level suited to developers, product managers, or stakeholders who need to trigger test runs and review results without the ability to modify test definitions. This is the recommended role for engineering team members who consume test results as part of their CI/CD workflow but do not write or maintain tests themselves.

For QA teams managing testing across multiple products, the member role is the safest default for anyone outside the core QA function - it prevents accidental modification of tests while still allowing on-demand execution and result review.

Variable Hierarchy and Encrypted Storage in Team Contexts

Variables in TestInspector follow a three-level inheritance hierarchy: test-level variables override suite-level variables, which override organization-level variables. When a test step references a variable, the runner resolves the value by checking test-level first, then suite-level, then org-level. The first matching definition wins.

This hierarchy allows teams to define shared credentials and environment configuration once at the org level and override specific values at the suite or test level for different environments or test scenarios. For example, a QA team might store a staging API base URL at org level and override it at suite level for tests targeting different environment builds.

Special variable types available in TestInspector include:

• TIMESTAMP - injects the current Unix timestamp at run time, useful for generating unique identifiers in test data
• ALPHANUMERIC - generates a random alphanumeric string, useful for email addresses or usernames in test accounts
• TOTP with secret - generates a time-based one-time password from the provided secret, enabling automated login flows that require MFA without storing recovery codes in plain text

All variables marked as sensitive are encrypted at rest. Encrypted variables are write-only once saved - their value is never displayed in the UI or returned via the API, only consumed at run time by the test runner. This matters in multi-member organizations where admins can create variables without exposing the underlying credentials to members who have view access to variable names but not values.

Variable conflicts where the same variable name is defined at multiple levels are resolved deterministically by the precedence order above. Teams should document which level each variable is intended to live at to avoid confusion. A common convention is to define all environment-specific configuration at org level, all test-data seeds at suite level, and any single-test overrides at test level. This keeps the org-level variable list as the single source of truth for environment configuration while allowing targeted overrides lower in the hierarchy.

For teams adopting automated testing at scale, structured variable management is often the difference between a maintainable test suite and one that becomes brittle when environments change. TestInspector encryption and hierarchy enforce good variable hygiene without requiring custom tooling.

Practical Patterns for Structuring Organizations and Suites

How you map organizations to teams depends on your company structure and your isolation requirements. There are three common patterns.

One organization per client (agency model). Software testing agencies and QA consultancies typically create one organization per client engagement. This ensures that credentials, test libraries, and results are fully isolated - a team member added to one client org cannot see tests from another client even if they also work on that project. API tokens are scoped per org, so automation pipelines for different clients are independently managed.

One organization per product (internal teams). Product companies with multiple independent products often create one organization per product team. QA engineers assigned to a product are members of that product org. Engineers who move between teams are added to new orgs and removed from old ones. This model works well when products have independent CI/CD pipelines and separate staging environments.

One shared organization (small teams). Small teams with a single product and a shared codebase often use a single organization for all tests. Suites provide sufficient logical separation by feature area or service. Admin roles are assigned to senior QA engineers, and member roles to the broader engineering team. This reduces administrative overhead at the cost of full isolation.

A note on suite design: suites should group tests that logically belong together in execution order and share common setup state. If two tests always run independently and reference different parts of the system, placing them in separate suites makes variable management cleaner. If tests share authentication state or session variables, grouping them in a suite and using suite-level variables is more maintainable.

For organizations using the CI/CD trigger API, per-suite API calls are often more practical than triggering full organization runs - they allow pipelines to run only the tests relevant to the service that changed. See testing documentation best practices for guidance on how to document variable schemas and org structures for onboarding new team members.

Frequently Asked Questions

Can a user belong to multiple TestInspector organizations at the same time?

Yes. A single user account can be a member of multiple organizations simultaneously. Switching between organizations in the UI changes the active context, showing only the tests, suites, variables, and schedules belonging to that organization. There is no stated limit on the number of organizations a user can join.

What happens to tests and data if the organization owner leaves the team?

Organization ownership must be transferred before the owner account is removed. If the owner promotes another admin to owner and then removes themselves, all data remains intact under the new owner. If an owner account is removed without transferring ownership, remaining admins retain access to tests and results, but operations that require owner-level permission remain unavailable until ownership is reassigned.

Are encrypted variables accessible to TestInspector support staff?

Encrypted variables are stored using one-way encryption and are not recoverable or viewable outside of run-time execution. Only the test runner has access to the decrypted value at execution time. If a variable value needs to be changed, it must be re-entered. This design prevents credential exposure through support channels or API responses.

How do API tokens interact with the organization boundary?

Each API token is generated within a specific organization and can only trigger test runs within that organization. A token cannot cross organization boundaries. Teams with multiple organizations should generate one token per organization and store each token in the CI/CD secret store of the corresponding pipeline or repository.

Is there a way to copy tests or suites between organizations?

TestInspector does not currently support direct copy or export of tests between organizations. Tests need to be recreated manually or via the browser extension recording workflow in the target organization. For teams that frequently reuse test logic across client organizations, maintaining a documented test template library and re-building in each org as needed is the current recommended approach.

What is the recommended role for a developer who needs to run tests as part of their pull request workflow?

The member role is the appropriate choice. It allows the developer to trigger test runs and view results without the ability to modify test definitions. Combined with the CI/CD trigger API in TestInspector, developers can initiate runs automatically through their pipeline without logging into the UI directly.