Multi-Tenancy and Team Models, Vortex IQ Documentation

Multi-tenancy is the question of “who can see what” inside an app. The answer differs across the seven Vortex Apps because each app serves a different operational shape. A Shopify single-merchant store has a different team model from a marketplace operator with twelve trading entities. An Adobe Commerce engineering org has a different team model from a single-merchant BigCommerce store. The Vortex Apps suite addresses these differences directly: each app is built around the team model that fits its primary use case, with cross-app coordination via the workspace abstraction. This page is the conceptual reference for the team and tenancy model across all seven apps. It explains the four primary tenancy patterns (CloudHub VendorDB, DryRunPro multi-project, single-store, and workspace-scoped), how permissions and visibility map to each pattern, and how the Profile (Settings) tab cross-references the tenancy model. For the per-app permissions UI, see each individual app’s settings page.

​

Why tenancy patterns differ across the suite

Every multi-tenancy model is a tradeoff between three properties: visibility (what data each user sees), control (what each user can change), and scaling (how the model handles growth from one tenant to many). A model tuned for a single-merchant Shopify store does not work for a marketplace operator running twelve trading entities. A model tuned for an Adobe Commerce engineering org with ten enterprise customers does not work for a single-merchant BigCommerce store. The Vortex Apps suite has four tenancy patterns because the seven apps cover four operational shapes: Each pattern is described in detail below with the role model, the visibility scope, and the typical merchant context.

​

Pattern 1, CloudHub VendorDB

The VendorDB pattern is built for marketplace operators: merchants who run a portfolio of trading entities across Amazon, eBay, Walmart, OnBuy, Cdiscount, FNAC, Rakuten, plus their own webstore. The defining property of this merchant is that one operator manages many entities, each with its own listings, inventory, pricing, and order workflow.

​

The model

VendorDB is a portfolio abstraction inside CloudHub. The user (the marketplace operator) holds the parent account. Under the parent account sit one or more vendors, each representing a trading entity. A vendor is a logical container for marketplace credentials, master SKU subset, pricing rules, and reporting scope. A user can see all vendors they have access to. Permissions can be vendor-scoped (Sarah can edit Acme Audio UK but only view Acme Audio DE) or global (Sarah can edit all vendors). Reporting can roll up across vendors or scope to a single vendor.

​

The visibility scope

Within VendorDB, the visibility model has three rings:

• Vendor-scoped data. Listings, inventory, pricing rules, orders, returns. Users see data for the vendors they have permission for.
• Channel-scoped credentials. Amazon SP-API tokens, eBay tokens, Walmart credentials. Stored per channel under each vendor. Channel credentials are visible only to users with edit-level access to the vendor.
• Cross-vendor reporting. Aggregate reports (total revenue across all my vendors this week) require global visibility. Users without global visibility see reports scoped to their accessible vendors.

​

The merchant context

VendorDB merchants are typically:

• Marketplace-led operators with five or more SKUs across three or more marketplaces.
• Multi-brand portfolios running several legal entities under one operations team.
• Aggregators managing inventory and listings on behalf of a portfolio of suppliers.

The pattern fits because the operator’s mental model is “I run several trading entities” rather than “I run one store with multiple sales channels”. Both patterns coexist: a single Shopify storefront can be one channel under one vendor in CloudHub, but the primary tenancy is the vendor abstraction.

​

Pattern 2, DryRunPro multi-project

The multi-project pattern is built for Adobe Commerce engineering orgs: agencies, integrators, and in-house engineering teams managing many Adobe Commerce projects at once. The defining property of this org is that one engineering team manages ten or more enterprise customers, each with its own multi-environment Adobe Commerce stack (production, staging, sandbox, integration, plus per-feature-branch environments).

​

The model

DryRunPro is structured around projects and environments. A project is one enterprise customer’s Adobe Commerce stack. An environment is one stack instance (production, staging, integration, plus on-demand feature branches). A user belongs to the org and is granted access to one or more projects. Within a project, the user can see all environments. Per-environment permissions (deploy production yes, deploy staging yes, edit infrastructure config no) are configured per project.

​

The visibility scope

DryRunPro visibility has four levels:

• Org-level. Org settings, billing, project list. Visible to org admins.
• Project-level. All environments under a project, environment topology, deploy history, snapshot history. Visible to users with project access.
• Environment-level. Per-environment configuration, code, and data. Visible to users with environment access (a subset of project access for sensitive environments).
• Snapshot-level. Each snapshot includes the data at the time of snapshot. Snapshot access follows environment access, with optional further restrictions for production snapshots.

​

The merchant context

Multi-project merchants are typically:

• Adobe Commerce agencies managing portfolios of enterprise client work.
• System integrators running Adobe Commerce as part of larger ecommerce stacks.
• In-house engineering teams at multi-brand companies running several Adobe Commerce stacks for different brands.

The pattern fits because Adobe Commerce projects are inherently multi-environment, multi-customer, multi-team. Trying to model this with a single-store pattern would require ten or more separate workspaces, each with its own settings; the multi-project model collapses them into one workspace with project-scoped data.

​

Pattern 3, single-store

The single-store pattern is built for the four storefront-safety apps: StagingPro, RollbackPro, Vortex Staging, and Vortex Backup. The defining property of these merchants is that one merchant runs one platform with one storefront (or a small handful of storefronts).

​

The model

The single-store pattern is the simplest of the four. A workspace owns one (or a few) storefronts. Users in the workspace have roles that determine what they can do. Most merchants run one storefront per workspace. Multi-storefront merchants (a US store and a UK store) typically have two storefronts per workspace, with per-storefront role overrides if needed.

​

The visibility scope

Single-store visibility has three levels:

• Workspace-level. Workspace settings, billing, integrations list. Visible to owners and admins.
• Storefront-level. Per-storefront data (theme, apps, settings, products, orders). Visible to all users with workspace access by default; per-storefront restrictions are available for multi-storefront workspaces.
• Action-level. Some actions (rollback, deploy, bulk edit) require elevated roles. Editors can perform most operations; viewers can read but not modify.

​

The merchant context

Single-store merchants are typically:

• Direct-to-consumer brands running one Shopify or BigCommerce store.
• Small to medium merchants with one to three storefronts.
• Marketing-led merchants focused on storefront optimisation rather than backend complexity.

The pattern fits because the merchant’s mental model is “this is my store” rather than “I have a portfolio of stores”. A larger merchant who graduates to a portfolio model often shifts from single-store to a combination of CloudHub (for the marketplace side) plus single-store apps for each storefront.

​

Pattern 4, App Builder workspace-scoped

The workspace-scoped pattern is built for App Builder. The defining property of App Builder is that the merchant builds custom apps that live inside their own workspace and only their workspace.

​

The model

App Builder is workspace-scoped because the apps the merchant builds are private to the workspace. A “Tuesday morning sales summary” app built by Acme Audio is not visible to or usable by any other workspace. Apps that are useful enough to share across the merchant base are promoted to the recipe catalogue (visible to Finding to Action translation) by the Vortex IQ team. The merchant who originated the app retains attribution. Most apps stay workspace-private.

​

The visibility scope

App Builder visibility:

• App-level. App definition, trigger, and run history visible to all workspace users with app access.
• Run-level. Each app run produces a record visible in the workspace’s Vortex Memory.
• Cross-app. Apps can compose: one app can trigger another. Cross-app composition is workspace-scoped; an app cannot trigger another workspace’s app.

​

The merchant context

App Builder is used by every merchant context (single-store, VendorDB, multi-project) for the long-tail of operational automations that the off-the-shelf apps do not cover. The workspace-scoped tenancy is what makes this safe: the merchant’s automations cannot accidentally affect another merchant’s workspace.

​

How the patterns interact

A typical Vortex IQ merchant uses several patterns at once. The patterns coexist because they cover different operational shapes. Marketplace operator with a webstore. CloudHub VendorDB for the marketplace side, Vortex Staging plus Vortex Backup for the Shopify webstore, App Builder for custom workflows. Three patterns, one workspace. Adobe Commerce agency. DryRunPro multi-project for client work, App Builder for in-house automations. Two patterns, one workspace. DTC brand on Shopify. Vortex Staging plus Vortex Backup for the storefront, App Builder for custom workflows. Two patterns (single-store plus workspace-scoped), one workspace. Multi-brand DTC on BigCommerce. StagingPro plus RollbackPro per storefront, App Builder for custom workflows. The single-store pattern repeats per storefront, with the workspace coordinating across storefronts. The workspace abstraction is what holds the patterns together. Each pattern has its own data model and visibility rules, but all patterns surface their data through the same workspace UI, the same role assignments, and the same Profile (Settings) tab.

​

How permissions cross-reference Settings

Per-app permissions live inside each app’s settings UI, but workspace-level permissions live in Settings -> Workspace admin. The two layers compose:

• Workspace-level role determines whether a user can access an app at all.
• App-level permissions determine what the user can do inside the app once granted access.

Common cross-references:

• A workspace owner has access to all apps and all data within each app.
• A workspace editor has access to all apps but with edit-or-view permissions per app.
• A workspace viewer has read-only access across apps.
• Custom roles (configured in Workspace admin) can grant access to a subset of apps with specific app-level permissions per app.

Profile-level settings (the user’s Profile tab) cover personal preferences (notification cadence, timezone, language) that apply across apps. App-level settings cover what the user can do inside an app. Workspace-level settings cover who can use the app.

​

Where it surfaces

The tenancy model is visible in five places.

• Each app’s settings page. Per-app permission UI for the apps the workspace uses.
• Workspace admin. Workspace-level role assignment, custom role configuration, user provisioning.
• Settings -> Profile. User-level profile settings.
• CloudHub vendor management. Vendor-scoped permissions for marketplace operators.
• DryRunPro project management. Project-scoped permissions for engineering orgs.

​

How it relates to other modules

The tenancy model is the substrate that determines how every other module behaves for each user. Actions cards are visible based on the user’s storefront and app permissions. Vortex Mind reports respect data scoping (a user without payment connector access does not see Payment Performance Intelligence reports). Nerve Centre cards filter by accessible storefronts and connectors. Vortex Memory records are scoped the same way as their originating module.

​

FAQ

Can a single user belong to multiple workspaces? Yes. Many users do, especially agency operators and consultants who manage workspaces on behalf of multiple merchants. The user identity is shared (one login, one profile) but the workspace memberships are independent (one role per workspace, separate data scoping per workspace). How does CloudHub VendorDB scale beyond ten vendors? CloudHub is built to handle a portfolio of fifty or more vendors. The vendor list paginates, vendor-scoped reporting is the default mode (cross-vendor reporting is opt-in), and bulk operations across vendors are explicit. Larger portfolios sometimes split into multiple CloudHub workspaces by geography or business unit. Can I run DryRunPro for non-Adobe-Commerce projects? No. DryRunPro is Adobe-Commerce-specific because the multi-environment model is tightly coupled to Adobe Commerce Cloud’s deployment surface. Non-Adobe-Commerce projects use the platform-specific apps (StagingPro for BigCommerce, Vortex Staging for Shopify) which use the single-store pattern. Are App Builder apps shareable across workspaces? No by default. Apps are workspace-private. Apps that are valuable across the merchant base are promoted (by the Vortex IQ team) to the recipe catalogue with the original author’s attribution. Within an organisation that has multiple Vortex IQ workspaces, App Builder apps can be exported and imported manually. How does multi-tenancy interact with billing? Billing is workspace-level. Each workspace pays for its own subscription. CloudHub VendorDB users pay one workspace fee plus per-vendor fees as the portfolio grows. DryRunPro users pay one workspace fee plus per-project fees. Single-store apps are workspace-fee only with usage-based limits per app. Can a user be limited to read-only access to one app while having edit access to another? Yes. Custom roles in Workspace admin allow per-app permission grants. A common pattern: an executive stakeholder has read-only access to all apps for visibility, but edit access only to the briefing-subscription preferences in App Builder. How does the model handle user offboarding? When a user is removed from a workspace, their access ends immediately across all apps in that workspace. Their user identity persists (so they retain access to other workspaces they belong to). The audit log retains the offboarding event. Apps that the offboarded user authored continue to run; ownership transfers to the workspace owner by default.

​

Cross-links

• Concept: When to use which Vortex App
• Concept: Multi-app workflows
• Concept: Comparison matrix
• Concept: Staging and rollback workflow
• App: CloudHub
• App: DryRunPro
• App: StagingPro
• App: RollbackPro
• App: Vortex Staging
• App: Vortex Backup
• App: App Builder
• Platform: Workspace admin
• Platform: Settings -> Profile
• Module: Actions
• Module: Vortex Mind
• Module: Vortex Memory