Naming Conventions: Patterns and Principles

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 14, 2026 · 14 min read

Where This Article Sits#

References#

1) The Naming Conventions Landscape#

BTP naming conventions cover four distinct resource families. Each family has different technical constraints, different change-cost profiles, and different ownership models.

They are not substitutes. A subaccount name organizes the cockpit; a destination name is a runtime lookup key; a service instance name appears in APIs and billing; a role collection name surfaces in IdP group-mapping rules. Renaming any of them has a different blast radius. ( SAP Best Practices)

2) How It Connects to S/4HANA#

BTP naming conventions become operationally critical where SAP BTP connects to SAP S/4HANA. Three integration points are directly affected by naming decisions:

S/4HANA (ABAP system)
        |
        |  [Cloud Connector tunnel]
        |
BTP Subaccount  ──── Destination: "s4hana-prod"
        |                    ↑
        |             referenced by name
        |             in xs-app.json /
        |             CAP services /
        |             Integration Suite iFlows
        |
Service Instance: "connectivity-svc-integration-prod"
        |
Role Collection: "PROD_S4Integration_Viewer"

Key point: When an application deployed in a BTP subaccount calls destinationService.getDestination("s4hana-prod"), the string "s4hana-prod" is hardcoded in application logic. If operations renames the destination to "sap-s4hana-prod-eu" for consistency, every consumer must be updated simultaneously — or the connection silently breaks with a 404, not a configuration error.

The same lock-in exists for service instance names referenced in Kubernetes deployments, MTA descriptors, and CAP binding configurations. Establish naming before first deployment, not after. ( SAP Best Practices)

3) Maturity Map#

4) Requirements Checklist#

Subaccount and Directory Naming#

Service Instance Naming#

Destination Naming#

Role Collection Naming#

Label Governance#

5) Decision Criteria#

The three questions to ask first#

Q1. Do you have more than 10 subaccounts today, or will you reach 10 within the next 6 months?

If yes, naming conventions are not optional — they are infrastructure. Account Explorer search, cost reporting, and IAM reviews all depend on consistent, readable names. The threshold of 10 is not arbitrary: it is the point at which human memory fails to track which subaccount belongs to which project without consistent naming cues. ( SAP Best Practices)

Q2. Who owns the naming convention across teams, and can they enforce it?

Naming conventions fail when ownership is diffuse. Without a named owner — typically the Platform / Cloud Center of Excellence team — individual project teams create names that optimize locally but break globally. The owner must have the authority to reject subaccount creation requests that violate the convention, not just advise on it.

Q3. Is there executive sponsorship for naming governance?

Naming conventions touch developer autonomy (project teams want to name their own resources), operations tooling (automation scripts are brittle to name changes), and finance (cost attribution reports depend on consistent naming). Without a sponsor who can resolve cross-team disputes and fund retroactive cleanup, naming conventions degrade within one year.

Resource scope by project context#

Cost and licensing implications#

6) Common Failures#

Failure 1: No naming convention before the first production subaccount

The team creates DEV and TEST subaccounts using project-team names (HR-Portal-DEV, portal-hr-d, HumanResources_Dev) because no standard exists yet. By the time a PROD subaccount is created, three inconsistent patterns have been established and the team argues about which to standardize. Resolution requires manual audit and a governance decision under time pressure. ( SAP Best Practices)

Failure 2: Destination names that reflect the initial target, not the logical purpose

A developer creates a destination named s4hana-eu-central-1-system-001 because that is the specific system hostname at project start. Six months later the system is load-balanced across two nodes and the hostname is meaningless. The name is now incorrect and misleading — but cannot be changed without a code release. Correct approach: name the destination after its logical role (s4hana-prod), not its infrastructure identity.

Failure 3: Service instance names without environment qualifier in a multi-stage subaccount

A team manages DEV and TEST workloads in a single subaccount. They create service instances named xsuaa-app and xsuaa-app-v2. Three months later, operations cannot determine which instance is used by which deployment without reading bindings. The environment qualifier (-dev, -test) would have made the distinction immediate.

Failure 4: Role collection names that grow organically

A new application is onboarded. The developer creates role collections named MyApp_Admin and MyApp_User. The next project creates ProjectB_Administrator and ProjectB_ReadOnly. The IdP group-mapping rules accumulate a mix of formats. When a security audit requires reviewing all administrator-level role collections, the team must manually inspect each collection because the names do not encode the permission level consistently.

Failure 5: Label vocabulary drift after the first year

The global account starts with well-governed labels (Landscape: Dev, Landscape: Test, Landscape: Production). Six months in, a new team joins and creates Landscape: DEV and Landscape: development. Cockpit filters for Landscape: Dev now return only a subset of development subaccounts. Cost reports are split across three variants. Because labels are case-sensitive and have no governance enforcement mechanism, correcting this requires touching every subaccount.

Failure 6: Subdomain too long for URL constraints

A project creates a subdomain mycompany-human-resources-development-subaccount (50 characters). This fits the 63-character limit — but the CF API endpoint adds a region suffix, pushing the total URL beyond limits for some tooling. The failure is intermittent and environment-specific. Use abbreviations: mycompany-hr-dev achieves the same result in 16 characters.

Failure 7: CF space names differ across DEV/TEST/PROD

The DEV subaccount has spaces portal-dev while TEST uses portal-qa and PROD uses portal. The CI/CD pipeline requires three separate space-name configurations instead of one parameterized value. SAP explicitly recommends identical space names across all landscape stages because no system-level linkage connects spaces in different subaccounts.

FAQ#

Q: Does SAP enforce naming conventions for BTP resources?

SAP enforces technical constraints — subdomain character set and length, service instance character set — but not organizational naming patterns. The pattern and consistency discipline are the customer’s responsibility. SAP’s Best Practices Guide provides examples and principles; there is no cockpit validation that rejects abc123 versus HR Dev. ( SAP Best Practices)

Q: We have an on-premise SAP landscape with established naming standards. Can we reuse those?

Partially. On-premise conventions (SID three-character system identifiers) operate at the system level, not the BTP resource level. Reuse the environment taxonomy (DEV/QAS/PRD) and functional area taxonomy (HR, FI, MM) as building blocks in BTP names. Do not carry over cryptic BASIS abbreviations that require institutional knowledge to decode.

Q: When should we use labels instead of encoding information in the name?

Encode in the name what is operationally critical: environment, functional owner, and logical purpose. Use labels for cross-cutting metadata added after creation: cost center, compliance flag, data classification, and contacts. Labels are mutable; names are immutable for most resources.

Q: How do we handle naming when multiple subsidiaries share a global account?

Include a subsidiary prefix in subdomains and CF orgs: subsidiary-a-hr-dev, subsidiary-b-sales-prod. Group by subsidiary using directories with entitlement management enabled. This maintains clear billing, access control, and naming boundaries within a single global account.

Q: Should role collection names differ between environments?

Yes, for environment-specific collections. PROD_IntegrationSuite_Admin is distinct from DEV_IntegrationSuite_Admin — they contain roles pointing to different service instances. For landscape-wide read-only collections, use ALL_ to signal cross-environment scope.

Q: How do we document naming conventions so they survive personnel changes?

Store the convention as a corporate standard in your governance framework, not a personal wiki page. Include: the pattern for each resource family, the rationale, examples of correct and incorrect names, and the owner. Keep it alongside your BTP setup automation (Terraform, btp-setup-automator, MTA templates) so pipeline engineers can reference it directly.

Summary#

BTP naming conventions sit at the intersection of operations, governance, and architecture. Two resource types — subdomains and service instances — have SAP-enforced technical constraints. The remaining four — destinations, role collections, directories, and labels — require organizational discipline because the platform does not enforce them. ( SAP Best Practices)

The field pattern that consistently works: define the convention during architecture design, document it as a corporate standard, assign a named owner in the Platform team, and build it into your subaccount creation automation. Projects that establish naming after the landscape is live spend disproportionate time on cleanup instead of delivery. The 63-character subdomain limit is a fact; the 50-subaccount cognitive overload is a choice.

What to Read Next#