Version: 2.4

Enterprise Workflow with Configuration Packages (SD-WAN example)

This page describes a scalable enterprise workflow for delivering tSM configuration with multiple independent teams, versioned Configuration Packages, and a cross-cutting SD-WAN solution.

The goal is to enable:

parallel work across teams without constant conflicts
repeatable installations into shared environments
clear ownership of configuration
predictable upgrades with a clear answer to:
- what changed
- what was deployed
- which version is installed

The SD-WAN example illustrates a common telco reality: SD-WAN affects CRM, product catalog, ordering, service catalog, provisioning, and ticketing, but is still best delivered as one coherent solution package.

Concepts

ConfigTypes

ConfigTypes define where configuration belongs.

Every configuration entity in tSM contains:

configType (String) — the ConfigType code of the owning configuration area

ConfigType codes are hierarchical:

a child code includes the full parent code as a prefix
example:
- BSS.Ordering
- BSS.Ordering.Fulfillment

In enterprise projects, ConfigTypes provide:

ownership
navigation
filtering
package scope

Configuration Packages

Configuration Packages define what is released and installed.

They are defined by:

packages/<PackageId>/package.yaml

A package contains:

package identity and version
dependencies
areas
policy

An area defines:

where content is stored in Git
which ConfigTypes belong there
whether a ConfigType includes its subtree

During sync, tSM Studio creates entity-type subfolders automatically inside each area.

So the design is:

ConfigType → ownership and taxonomy
Configuration Package → release boundary
Area → business-oriented storage in Git
entity-type subfolders → generated automatically by Studio

Ownership model

A typical enterprise ownership model looks like this:

Team	Owns ConfigTypes	Ships Configuration Packages
Platform core team	`System.*`	`System`
Platform / infrastructure team	`Infra.*`	`InfraCommon`
BSS team	`BSS.*`	`BSSBase`
OSS team	`OSS.*`	`OSSBase`
Ticketing team	`Ticketing.*`	`TicketingBase`
SD-WAN solution team	`SDWAN.*`	`SDWAN`

Rule: SD-WAN-specific configuration must live under the SDWAN.* root, even when it integrates with BSS, OSS, or Ticketing.

This is the key to avoiding package confusion:

base capabilities stay in their own roots
SD-WAN specifics stay in SDWAN.*
the SD-WAN package depends on the base packages rather than mixing its content into their trees

ConfigTypes for the enterprise SD-WAN example

Core and base ConfigTypes

Code	Name	Purpose
`System`	System	Core tSM baseline configuration delivered with the application and refined by the installation.
`Infra`	Infrastructure	Shared installation/platform configuration used across multiple business domains.
`BSS`	BSS	Business Support root.
`BSS.CRM`	CRM	CRM configuration.
`BSS.ProductCatalog`	Product Catalog	Product catalog configuration.
`BSS.Ordering`	Ordering	Ordering configuration.
`OSS`	OSS	Operations Support root.
`OSS.ServiceCatalog`	Service Catalog	Service definitions and service models.
`OSS.Provisioning`	Provisioning	Provisioning and orchestration configuration.
`Ticketing`	Ticketing	Ticketing configuration.

SD-WAN ConfigTypes

Code	Name	Purpose
`SDWAN`	SD-WAN	Root for SD-WAN-specific configuration.
`SDWAN.ProductCatalog`	SD-WAN Product Catalog	SD-WAN commercial offer specifics, mappings, and attributes.
`SDWAN.Ordering`	SD-WAN Ordering	SD-WAN ordering forms, validations, and process-specific behavior.
`SDWAN.ServiceCatalog`	SD-WAN Service Catalog	SD-WAN service templates and service models.
`SDWAN.Provisioning`	SD-WAN Provisioning	SD-WAN provisioning specifics.
`SDWAN.Ticketing`	SD-WAN Ticketing	SD-WAN incident types, workflows, and forms.

Why `SDWAN.*` is a separate root

The SD-WAN solution is cross-domain, but it should still be packaged as a coherent solution.

That means:

generic CRM stays under BSS.CRM
generic ordering stays under BSS.Ordering
generic service catalog stays under OSS.ServiceCatalog
generic ticketing stays under Ticketing
SD-WAN-specific assets go under SDWAN.*

This gives you:

clear ownership
clean package boundaries
simpler upgrade logic
fewer conflicts between teams

Repository layout

A typical enterprise workspace can look like this:

packages/
  System/
    package.yaml
    system/

  InfraCommon/
    package.yaml
    infra/

  BSSBase/
    package.yaml
    crm/
    product-catalog/
    ordering/

  OSSBase/
    package.yaml
    service-catalog/
    provisioning/

  TicketingBase/
    package.yaml
    ticketing/

  SDWAN/
    package.yaml
    product-catalog/
    ordering/
    service-catalog/
    provisioning/
    ticketing/

tsm-project.yaml

For the full project.yaml and package.yaml schema, see Configuration Reference.

Notes

each package contains one package.yaml
each package contains one or more areas
areas are business-oriented
inside each area, Studio creates entity-type subfolders automatically during sync

For example, after sync the SD-WAN package may contain:

packages/
  SDWAN/
    product-catalog/
      EntityCatalogCategory/
      EntityCatalogSpecification/
      EntitySpecification/
      Characteristic/
      Form/

    ordering/
      Form/
      Process/
      Script/

    service-catalog/
      EntityCatalogSpecification/
      EntitySpecification/
      Characteristic/
      Form/

    provisioning/
      Process/
      Script/
      Register/

    ticketing/
      Form/
      Process/
      Register/

The package defines the business areas. Studio handles the technical subfoldering automatically.

Package definitions

The enterprise example uses these packages:

System
InfraCommon
BSSBase
OSSBase
TicketingBase
SDWAN

1) `System`

The System package contains tSM baseline configuration delivered with the application and refined by the installation.

packageId: System
name: System
version: 1.0.0
description: Core tSM baseline configuration.
ownerTeam: PlatformCore

areas:
  - id: system
    path: system
    description: Core platform configuration.
    configTypes:
      - code: System
        includeSubtree: true

policy:
  managed: true
  allowDelete: false
  enforceDependencies: true

2) `InfraCommon`

The InfraCommon package contains shared installation/platform configuration used across multiple business domains.

packageId: InfraCommon
name: Infrastructure Common
version: 1.0.0
description: Shared installation and infrastructure configuration.
ownerTeam: PlatformInfra

dependencies:
  - packageId: System
    versionRange: ">=1.0.0 <2.0.0"
    kind: required

areas:
  - id: infra
    path: infra
    description: Shared platform and integration configuration.
    configTypes:
      - code: Infra
        includeSubtree: true

policy:
  managed: true
  allowDelete: false
  enforceDependencies: true

3) `BSSBase`

The BSSBase package contains the generic BSS foundation.

packageId: BSSBase
name: BSS Base
version: 1.0.0
description: Generic CRM, product catalog, and ordering configuration.
ownerTeam: BSS

dependencies:
  - packageId: System
    versionRange: ">=1.0.0 <2.0.0"
    kind: required
  - packageId: InfraCommon
    versionRange: ">=1.0.0 <2.0.0"
    kind: required

areas:
  - id: crm
    path: crm
    description: Generic CRM configuration.
    configTypes:
      - code: BSS.CRM
        includeSubtree: true

  - id: product-catalog
    path: product-catalog
    description: Generic product catalog configuration.
    configTypes:
      - code: BSS.ProductCatalog
        includeSubtree: true

  - id: ordering
    path: ordering
    description: Generic ordering configuration.
    configTypes:
      - code: BSS.Ordering
        includeSubtree: true

policy:
  managed: true
  allowDelete: false
  enforceDependencies: true

4) `OSSBase`

The OSSBase package contains the generic OSS foundation.

packageId: OSSBase
name: OSS Base
version: 1.0.0
description: Generic service catalog and provisioning configuration.
ownerTeam: OSS

dependencies:
  - packageId: System
    versionRange: ">=1.0.0 <2.0.0"
    kind: required
  - packageId: InfraCommon
    versionRange: ">=1.0.0 <2.0.0"
    kind: required

areas:
  - id: service-catalog
    path: service-catalog
    description: Generic service catalog configuration.
    configTypes:
      - code: OSS.ServiceCatalog
        includeSubtree: true

  - id: provisioning
    path: provisioning
    description: Generic provisioning configuration.
    configTypes:
      - code: OSS.Provisioning
        includeSubtree: true

policy:
  managed: true
  allowDelete: false
  enforceDependencies: true

5) `TicketingBase`

The TicketingBase package contains the generic ticketing foundation.

packageId: TicketingBase
name: Ticketing Base
version: 1.0.0
description: Generic ticketing configuration.
ownerTeam: Ticketing

dependencies:
  - packageId: System
    versionRange: ">=1.0.0 <2.0.0"
    kind: required
  - packageId: InfraCommon
    versionRange: ">=1.0.0 <2.0.0"
    kind: required

areas:
  - id: ticketing
    path: ticketing
    description: Generic ticketing configuration.
    configTypes:
      - code: Ticketing
        includeSubtree: true

policy:
  managed: true
  allowDelete: false
  enforceDependencies: true

6) `SDWAN`

The SDWAN package contains all SD-WAN-specific solution content.

packageId: SDWAN
name: SD-WAN Solution
version: 1.0.0
description: SD-WAN-specific solution configuration.
ownerTeam: SDWAN

dependencies:
  - packageId: System
    versionRange: ">=1.0.0 <2.0.0"
    kind: required
  - packageId: InfraCommon
    versionRange: ">=1.0.0 <2.0.0"
    kind: required
  - packageId: BSSBase
    versionRange: ">=1.0.0 <2.0.0"
    kind: required
  - packageId: OSSBase
    versionRange: ">=1.0.0 <2.0.0"
    kind: required
  - packageId: TicketingBase
    versionRange: ">=1.0.0 <2.0.0"
    kind: required

areas:
  - id: product-catalog
    path: product-catalog
    description: SD-WAN-specific product catalog configuration.
    configTypes:
      - code: SDWAN.ProductCatalog
        includeSubtree: true

  - id: ordering
    path: ordering
    description: SD-WAN-specific ordering configuration.
    configTypes:
      - code: SDWAN.Ordering
        includeSubtree: true

  - id: service-catalog
    path: service-catalog
    description: SD-WAN-specific service catalog configuration.
    configTypes:
      - code: SDWAN.ServiceCatalog
        includeSubtree: true

  - id: provisioning
    path: provisioning
    description: SD-WAN-specific provisioning configuration.
    configTypes:
      - code: SDWAN.Provisioning
        includeSubtree: true

  - id: ticketing
    path: ticketing
    description: SD-WAN-specific ticketing configuration.
    configTypes:
      - code: SDWAN.Ticketing
        includeSubtree: true

policy:
  managed: true
  allowDelete: false
  enforceDependencies: true

What “SD-WAN across all basics” means

All SD-WAN-specific assets stay under the SDWAN.* root, even when they work together with BSS, OSS, and Ticketing foundations.

Area	Example asset	`configType`
Product catalog	SD-WAN offer mappings and attributes	`SDWAN.ProductCatalog`
Ordering	SD-WAN order wizard, validations, and steps	`SDWAN.Ordering`
Service catalog	SD-WAN service template	`SDWAN.ServiceCatalog`
Provisioning	SD-WAN provisioning orchestration	`SDWAN.Provisioning`
Ticketing	SD-WAN incident type and workflow	`SDWAN.Ticketing`

The base packages provide the generic foundation. The SD-WAN package adds only the SD-WAN-specific solution layer.

Installability and dependency closure

Package scope defines what belongs to the package.

Installability additionally requires that:

required dependencies are installed
referenced foundation content is available
package versions are compatible

This is why dependencies are explicit and versioned.

An SD-WAN release should always say exactly which base versions it is intended to run with.

Workflow 1: Feature branch + Scratch environment

Experimental

Scratch environments are an experimental capability. They provide stronger isolation for parallel development but add environment management overhead. Evaluate whether the team benefits justify the additional complexity.

This workflow is optimized for parallel work with minimal conflicts.

A Scratch environment is a short-lived, isolated environment created for a single feature branch and rebuilt on demand.

Flow

Sync main from Git Developers start from the current mainline configuration.
Create a feature branch The branch becomes the unit of isolation and review.
Create a Scratch environment Scratch starts clean and is used only for this feature.
Install baseline packages into Scratch Install what is needed for the feature:
- System
- InfraCommon
- BSSBase
- OSSBase
- TicketingBase
- optionally SDWAN if the feature depends on an existing SD-WAN release
Develop Two equivalent modes are possible:
- filesystem-first — edit files, upload/apply into Scratch, verify
- scratch-first — configure in Scratch UI, download into tSM Studio, commit
Create MR (Merge Request) The MR contains file changes and package version updates where needed.
Merge After review and checks pass, merge into main.
Build and install The pipeline builds immutable package versions and installs or upgrades them into target environments.

Recommended Scratch checks

changed items use the correct configType
package areas contain only expected content
dependency validation passes
install simulation works from baseline to changed package set
post-install verification by download/diff shows only expected changes

Workflow 2: Feature branch on DEV

This workflow is used when Scratch isolation is not enough, typically because you must test:

real integration endpoints reachable only from DEV
shared data interactions
end-to-end flows across multiple systems

Flow

Sync main from Git
Create a feature branch
Modify configuration in DEV
- every changed or new item must have the correct configType
Download changes to tSM Studio
- download from DEV into the workspace
- review diffs locally
Create MR
Merge
Build and install/upgrade to target environments

Risks and controls

Risk on DEV	What can go wrong	Control
Multiple teams modify DEV in parallel	Changes collide; one team depends on another’s unfinished work	Keep changes small, download frequently, require MR review, prefer Scratch where possible
“It works in DEV but wasn’t committed”	PROD install misses critical changes	Git is the source of truth; releases happen only through package versions
Accidental edits to shared foundation	Breaks multiple domains	Strict ownership by ConfigType root; changes to `System.` and `Infra.` are controlled by the responsible teams
Hidden drift in DEV	DEV differs from known baseline	Periodic download-and-compare against mainline before release

Release order and upgrade pattern

A common stable installation order is:

System
InfraCommon
BSSBase, OSSBase, TicketingBase
SDWAN

For upgrades, install new versions in dependency order:

foundation first
solution packages afterwards

Versioning expectations

If a team changes only configuration inside its own ConfigTypes, it usually bumps only its own package.
If a change affects shared foundation behavior, the provider package must be bumped and dependent package version ranges reviewed.
SD-WAN-specific changes usually bump SDWAN.
Base packages bump only when their own behavior or contract changes.

Best practices

Keep package boundaries aligned to ConfigType roots

A package should usually follow one clear ConfigType subtree.

Keep areas business-oriented

Inside a package, use areas such as:

crm
ordering
service-catalog
provisioning

rather than technical areas like forms or processes.

Studio already creates entity-type subfolders automatically.

Keep SD-WAN specifics under `SDWAN.*`

Do not place SD-WAN-specific assets under BSS.*, OSS.*, or Ticketing.*.

Keep `System` separate

Core tSM baseline configuration should remain clearly separated from installation-owned and business-owned configuration.

Prefer dependencies over content mixing

If SD-WAN needs ordering, service catalog, and ticketing foundations, express that through dependencies, not by moving generic assets into SDWAN.*.

Summary

This enterprise model combines:

ConfigTypes for ownership and organization
Configuration Packages for release and installation
business-oriented areas inside packages
automatic entity-type subfolders created by Studio during sync

The SD-WAN example works well because:

base capabilities stay in their own package roots
SD-WAN specifics stay under SDWAN.*
dependencies make the release relationship explicit
teams can work in parallel with clearer boundaries

Two workflows are supported:

Scratch workflow for parallel, low-conflict development
DEV workflow when integration constraints require work in a shared environment

Concepts​

ConfigTypes​

Configuration Packages​

Ownership model​

ConfigTypes for the enterprise SD-WAN example​

Core and base ConfigTypes​

SD-WAN ConfigTypes​

Why SDWAN.* is a separate root​

Repository layout​

Notes​

Package definitions​

1) System​

2) InfraCommon​

3) BSSBase​

4) OSSBase​

5) TicketingBase​

6) SDWAN​

What “SD-WAN across all basics” means​

Installability and dependency closure​

Workflow 1: Feature branch + Scratch environment

Flow​

Recommended Scratch checks​

Workflow 2: Feature branch on DEV

Flow​

Risks and controls​

Release order and upgrade pattern​

Versioning expectations​

Best practices​

Keep package boundaries aligned to ConfigType roots​

Keep areas business-oriented​

Keep SD-WAN specifics under SDWAN.*​

Keep System separate​

Prefer dependencies over content mixing​

Summary​

Concepts

ConfigTypes

Configuration Packages

Ownership model

ConfigTypes for the enterprise SD-WAN example

Core and base ConfigTypes

SD-WAN ConfigTypes

Why `SDWAN.*` is a separate root

Repository layout

Notes

Package definitions

1) `System`

2) `InfraCommon`

3) `BSSBase`

4) `OSSBase`

5) `TicketingBase`

6) `SDWAN`

What “SD-WAN across all basics” means

Installability and dependency closure

Flow

Recommended Scratch checks

Flow

Risks and controls

Release order and upgrade pattern

Versioning expectations

Best practices

Keep package boundaries aligned to ConfigType roots

Keep areas business-oriented

Keep SD-WAN specifics under `SDWAN.*`

Keep `System` separate

Prefer dependencies over content mixing

Summary