Understanding the SAP BTP Tenant Hierarchy: Global Accounts, Directories, and Subaccounts
Introduces the core SAP BTP tenant model - what a global account is, how directories organize subaccounts, and why subaccounts are the actual unit of work for deploying integration content and services.
Explanation
Every SAP BTP customer landscape starts with a global account. This is the commercial contract container that SAP provisions when an organization purchases BTP - it holds the overall entitlements (the services and quotas a customer is allowed to consume, such as Integration Suite capacity units, Cloud Foundry runtime memory, or Kyma resources) that were negotiated in the contract. The global account itself is not where you deploy applications or build integration flows; it is a governance and licensing boundary. Beneath the global account, SAP BTP offers an optional organizational layer called directories. Directories let administrators group related subaccounts together - for example, grouping all subaccounts belonging to a specific business unit, project, or region. Directories can have their own entitlements assigned to them, which are then distributed further down to the subaccounts they contain. Directories are optional: a small landscape might have a global account with subaccounts directly underneath it, while a large enterprise typically uses multiple layers of directories to reflect organizational or regional structure. The subaccount is where real technical work happens. It is the unit in which you enable services (such as Integration Suite, Cloud Integration, API Management, or Event Mesh), assign entitlements and quotas, configure Cloud Foundry orgs/spaces or Kyma namespaces, set up destinations and connectivity, and deploy integration artifacts like iFlows. Each subaccount is tied to a specific region (a data center location), which matters because connectivity, data residency, and latency depend on where a subaccount physically runs. Why does this hierarchy matter for an integration consultant? First, entitlements are finite and are consumed as they flow downward - a global account has a total quota of, say, Integration Suite capacity, and this must be distributed across directories and subaccounts. If a subaccount runs out of quota, you cannot deploy new integration flows or scale existing ones until quota is reassigned. Second, security boundaries follow this hierarchy - user role collections, trust configuration for identity providers, and API access are typically configured at the subaccount level, meaning that a poorly planned subaccount structure can lead to duplicated security setup or inconsistent access control across projects. Third, because subaccounts are regionally bound, integration scenarios connecting on-premise systems (via Cloud Connector) or other cloud services must be planned per subaccount region - a subaccount in one region cannot directly share a Cloud Connector instance with a subaccount in another without explicit configuration. In practice, when a new integration project begins, a consultant does not create a global account - that is typically owned by a central BTP administrator or Basis/cloud platform team. Instead, the consultant works within an existing subaccount, or requests that an administrator provision a new subaccount under the correct directory with the right entitlements (for example, requesting Integration Suite entitlement with enough capacity units for expected message volume). Understanding this hierarchy helps consultants ask the right questions early: which global account and directory should this subaccount belong to, what region should it be in, what entitlements does it need, and how does it relate to other subaccounts used for development, test, and production stages of the same integration landscape. Finally, it's worth distinguishing this BTP-native concept from anything in ECC or classical S/4HANA on-premise landscapes, where there is no equivalent multi-tenant subscription hierarchy - those systems use clients and system landscapes (DEV/QA/PRD) managed via transport, not commercial entitlement trees. S/4HANA Cloud Public Edition tenants are themselves often provisioned as BTP subaccounts or linked to BTP subaccounts for extension scenarios, making this hierarchy directly relevant even to functional consultants doing side-by-side extensibility.
Real project scenario
A retail company onboarding SAP Integration Suite for the first time receives one global account from SAP. Their cloud platform team creates a directory named 'Supply-Chain-Integrations' and, under it, three subaccounts: DEV, TEST, and PROD, each in the same EU region to satisfy data residency requirements. The integration consultant is given developer access only to the DEV subaccount and must formally request promotion of tested iFlows to TEST and PROD through a change process, since entitlements and connectivity (Cloud Connector instances, destinations) are configured independently in each subaccount.
Common mistakes
• Assuming a subaccount is the same as a 'system' in the ABAP sense and expecting client-like copy operations between them. • Requesting new subaccounts without checking whether sufficient entitlements remain at the global account or directory level, leading to failed enablement. • Placing DEV and PROD subaccounts in different regions unintentionally, causing inconsistent latency or data residency issues when they should mirror each other. • Not documenting which directory a subaccount belongs to, making later entitlement audits difficult. • Confusing global account administrators' responsibilities with subaccount-level administrator responsibilities, causing delays when access or quota changes are needed.
Best practices
• Treat the global account as a licensing boundary managed by a central platform team, not a working area for consultants. • Use directories to mirror organizational or project structure so entitlement management and reporting stay clear. • Keep DEV, TEST, and PROD subaccounts in the same region unless there is a specific business reason not to. • Document entitlement allocation per subaccount so teams can proactively request more quota before hitting limits. • Clarify early in a project who owns global account, directory, and subaccount administration to avoid delays in provisioning.
Interview angle
Interviewers commonly ask candidates to explain the BTP account hierarchy and why subaccounts are the deployment unit rather than the global account. A strong answer distinguishes commercial/entitlement scope (global account, directories) from technical/operational scope (subaccounts, spaces, namespaces) and explains the practical impact of regional binding and entitlement flow on real integration project planning.