Organisation Model#

Reply CMP organises cost ownership and automation scope through three orthogonal dimensions: Groups, Environments, and Projects. Resources are assigned to these dimensions automatically using tag-based rules — you never assign resources manually. Once defined, the same dimensions power both FinOps cost allocation and Automation policy scope.

Dimension 1: Groups (Organisation hierarchy)#

Groups represent your company’s structure as a tree of any depth:

Company (root)
├── Business Unit: Platform
│   ├── Team: Infra
│   └── Team: Security
└── Business Unit: Product
    ├── Product: Web Shop
    │   ├── Team: Frontend
    │   └── Team: Backend
    └── Product: Mobile App

  • Any depth is supported

  • Each node can have an owner (used for budget alerts and escalation notifications)

  • The root node is a system-level catch-all for unallocated costs — it is not a real business unit and is excluded from business-level cost reports

  • Groups are shared between FinOps (cost attribution, budgets) and Automation (policy scope)

Note

The number of Group nodes is limited by your tenant quota. View current usage in Tenant → Quota Drawer.

Dimension 2: Environments#

A flat list of runtime stages, independent of the Group hierarchy. Examples:

  • Development

  • Staging / QA

  • Production

  • Sandbox

A resource can belong to a Group node and an Environment at the same time.

Dimension 3: Projects#

A flat list of initiatives, applications, or workloads. Examples:

  • Web Shop

  • Mobile App

  • Data Platform Modernisation

  • Cloud Migration 2026

Like Environments, Projects are orthogonal to Groups. A resource can belong to all three dimensions simultaneously.

Allocation rules#

Resources are assigned to dimensions automatically through allocation rules. Each rule is a tag expression:

Rule

Assigned to

team=web AND environment=production

Group: “Team Frontend” + Environment: “Production”

project=data-platform

Project: “Data Platform Modernisation”

costcenter=1042

Group: “Business Unit: Finance”

  • Conditions within a rule are evaluated with AND logic

  • Rules are associated with a Group node, an Environment, or a Project

  • Resources that match no rule appear in the Unallocated bucket in Assess and Analyze

Tip

Start with your most important Group nodes and write rules for them first. You can add more rules over time. The Unallocated view in Assess shows exactly where gaps exist.

Worked example#

Scenario: Azure subscription with VMs tagged team=web and environment=dev.

  1. Create Group tree: Company → Platform → Team Web

  2. Create Environment: Dev

  3. Write rule on “Team Web” node: team=web

  4. Write rule on “Dev” Environment: environment=dev

  5. Any resource with tag team=web is now attributed to the “Team Web” group in FinOps

  6. Any resource with tag environment=dev is attributed to the “Dev” environment

  7. Analyze → filter by Environment = Dev shows all Dev costs across all providers

Connection to Automation policies#

Important

Group nodes defined in Allocate are the same groups available as scope targets in Automation policies. When you create a “Stop Dev after hours” policy, you select a Group or Environment from this hierarchy.

Creating, renaming, or deleting a group in Allocate immediately affects any running policies that reference it.