What must exist before the Integration Platform works: in Azure and Entra ID, in the network and in the repositories. This
page is for the platform team. Workload teams find their own short list at the end.
| Prerequisite |
Why |
Who provides it |
| MCP hub and spokes |
The platform runs on spokes and uses the hub for network, firewall and DNS (Architecture reference) |
Platform team (MCP) |
| A shared services spoke per environment |
Holds the shared services. In the reference design the base deployment is only the container registry. |
Platform team |
| Shared services deployed as needed |
The Service Bus namespace (Premium), Event Hubs, API Management. Their resource IDs go in the shared_services block of the platform configuration (Spoke extensions). |
Platform team |
| Spoke extensions enabled per integration spoke |
Give the spoke access to the shared services. See the checklist. |
Platform team |
| Entra ID administrative unit per environment |
Isolates the groups that the automation creates. A separate unit per environment is strongly advised (ADR-004). |
Customer identity team |
| Groups Administrator on that unit for the automation identity |
Lets the automation create and manage groups, but only inside the unit |
Customer identity team |
| Platform readers group |
A group with read access to the Service Bus namespace, created by the Service Bus spoke extension. Its object ID is an input of the automation. |
Created by the spoke extension |
| Azure roles of the automation identity |
Owner or Contributor on the resource group of the namespace. Access to the Terraform state storage account. |
Platform team |
| Terraform state backend |
The root configuration uses an azurerm backend with Entra ID authentication |
Platform team |
| Pipeline runners inside the network |
Private resources can only be deployed from inside the network. The reference design shares self-hosted runners between the MCP and the integration workloads (Build agents). |
Platform team |
| DNS resolution for private endpoints |
From your own networks, name resolution of the private endpoints needs forwarding (Private endpoint DNS) |
Customer network team, platform team |
| Defender for APIs |
The platform enables Defender for APIs on the integration subscriptions |
Platform team |
| Tool |
Version in the code |
| Terraform |
Service Bus automation: 1.10.1 or later. Module repository: 1.9 or later, below 2.0. The reusable workflow defaults to a pinned version, see Deploy integration resources. |
| Providers |
azurerm 4.x, azuread (3.x in the automation, 2.x in the module repository), azapi 2.x in the module repository |
| Azure CLI |
Used for authentication and by one module that approves a managed private endpoint |
Check the versions against the code you run. They change with releases.
Network
- Every spoke virtual network is peered with the hub. By default the firewall allows traffic within a spoke only.
- A connection from an integration workload to a shared service, or to an on-premises or external system, needs a firewall
rule (Firewall rules and IP groups).
- Spoke subnets for private endpoints and for outbound VNet integration must exist before modules can use them. The
modules read subnets from the spoke configuration by name (Modules).
For workload teams
| What you need |
How to get it |
| An integration spoke |
Request a spoke. Ask for the extensions of the shared services you need (Shared services). |
| The spoke outputs file |
Holds the details of your spoke (resource group, subnets, Key Vault, storage account, Log Analytics workspace). Your platform provides it, see Deploy integration resources |
| A workload repository with the deployment workflow |
From your platform team |
| Firewall rules to the systems you integrate |
Request |
| Names of the Entra ID groups for your entities |
From your platform team, after the entities are created |