Anypoint Business Groups (BGs) are a way to structure, manage, and govern resources within our Anypoint Platform. They allow us to segregate their environments, control access, allocate costs, and enforce compliance policies efficiently.
Organizations, normally large organizations, use Business Groups to create a hierarchical structure where different teams, departments, or geographic regions can work independently while maintaining centralized governance at the organization level.
But what exactly are Business Groups? And what precisely is defined on each Business Group? In this post, we’ll take a comprehensive look at what’s in an Anypoint Business Group
How Business Groups work
Each MuleSoft Organization (the highest level) can contain multiple Business Groups. Business Groups can have nested (child) Business Groups, forming a hierarchical structure where the top-level business group is the Root or Master Org. Each business group you create has one direct parent and can have multiple children.
Each Business Group has its own resources, access control and Control Plane services.
What Exactly Does each Business Group Contain?
Each Business Group, including the Master Org contains:
Environments
- Each Business Group has its own set of environments (e.g., Development, QA, Production).
- These environments are completely independent from other Business Groups.
- You cannot share an environment across Business Groups.
- Example:
- The Retail Business Group has:
- Dev
- QA
- Production
- Meanwhile, the Finance Business Group has separate environments with the same names but different API gateways and applications.
Design Center
- Each Business Group has its own Design Center instance. This means each Business Group has its own set of API Projects.
- So, Projects, APIs or Business Units of our organization that need to use the same API Specification should belong to the same Business Group, otherwise the same project would be duplicated.
- However, this does not apply to API Fragments. Notice that, in an API Project we can import API Fragments from any Business Group of the organizations
- Best Practices:
- Try to modularize as much as you can your API specs using API Fragments (Datatypes, traits, examples, libraries). This will allow us to update only one API Fragment and get it updated in all API Specs where it’s been imported
- Use the Root Org Business Group as the central repository of common API Fragments for your entire Org
Runtime Manager
- Each Business Group has its own Runtime Manager instance, which controls:
- CloudHub 1.0 deployments (applications and VPCs/DLBs)
- CloudHub 2.0 deployments (applications and Private Spaces)
- On-Premise Mule Runtime deployments (applications and Servers/Server Groups/Clusters)
- Runtime Fabric deployments (applications and RTF instances)
- 💡 Example: The Healthcare Business Group can deploy APIs in its own Mule runtime clusters without affecting the E-commerce Business Group.
Private Exchange
- Each Business Group has its own Exchange instance, where it stores:
- APIs
- API Specifications, API Fragments
- Connectors
- Custom Policies
- Templates
- The Exchange instance at the root org will be shared across all BGs. This means, at minimum, each Business Group has access to the assets in its own private Exchange instance and the root org Exchange. This allows us to use the Exchange instance at the root org as the common Exchange repository for all BGs
- By default, assets are isolated to a specific Business Group but APIs and connectors can be shared between Business Groups if needed. Example: The HR Business Group has an "Employee Management API", but it won’t be visible in the Marketing Business Group's Exchange unless explicitly shared.
Access Management (Users & Teams)
- Each Business Group has its own access control setup, meaning:
- Each Business Group will have its own list of Users
- Each Business Group will have its own set of permissions to control the resources and services managed within the same Business Group. Example: We’ll find permissions like Exchange Contributor or Cloudhub Network Admin on each Business Group. That permission will apply only to the Exchange or Runtime Manager instance managed by each Business Group
- Users in one Business Group don’t automatically get access to another
- Anypoint Teams can be used to grant permissions within each Business Groups
Runtime Resources
- Each Business Group has separate runtime resources
- Allocated vCores for Prod, Non-Prod, Design (can be sliced to 0.1 fragments)
- Static IPs, VPCs and Load Balancers (only CH1.0)
- Network Connections (only CH2.0)
- This way, each Business Group has its own subscription entitlements and usage tracking, meaning:
- Resource usage is tracked separately for billing and cost allocation.
- Separate CloudHub & Runtime usage reports
- 💡 Example: The Banking Business Group can have dedicated vCores for high-security APIs, while the HR Business Group uses fewer resources for internal applications.
API Manager
- Each Business Group gets its own API Manager instance, allowing it to:
- Create and manage APIs independently
- Apply security policies at Environment level
- Track analytics and usage reports separately
- Each API instance or gateway is created at environment level. For the same app, we can have multiple API instances or gateways, for production or non-production but all of them will share the same Exchange asset.
- Here, it’s very important to understand the relationship with Exchange. When we create an API gateway we will use an asset from Exchange - it can be an API Specification or an HTTP/REST/SOAP API. This means two things:
- One, the same API Specification or HTTP/REST/SOAP API will be used for an API instance in sandbox and production environments. There’s no one API spec in dev, and one API spec in prod. They refer to the same asset
- Only the API Specifications in the Private Exchange instance of the current Business Group are available for API Manager. We will not be able to define an API Gateway from an API Specification of a different Business Group.
- 💡 Example: The E-commerce Business Group can apply OAuth2 policies to its APIs, while the Customer Support Business Group can enforce IP whitelisting without affecting each other.
Cloudhub 2.0 Private Spaces
- Each Business Group has its own set of CloudHub applications and Private Spaces.
- A private space is a dedicated deployment target with its own network
- Private Spaces can be created at any level of the Business Groups hierarchy (Root Org, Parent or Child).
- However, when we create a PS, it will be created as a resource of the Business Group where it is created and automatically available to that BG. You can then extend the availability of that PS:
- To a list of specific existing BGs in the same BG hierarchy (only children, can’t extend a PS to the parent BG)
- To the current BG and its children - this is a dynamic, meaning, using this option you make sure that new BGs created in the future under the existing one will have the PS available
- Best Practice - Unless there’s a good/justified reason to create Private Spaces in specific Business Groups, create the PS at the root org level. This way you will always be able to make the Private Space available to any Business Group
Runtime Fabric Clusters
- Similarly to CH2.0 Private Spaces, RTF clusters can be created in any Business Group of the organization hierarchy. However, as we’ve seen with Private Spaces, to make an RTF cluster created in BG available to other business groups, the business groups must fall under the scope of the business group the Runtime Fabric is registered to. In other words, it can be made available to the children BGs.
- Best Practice - Same as Private Spaces. Unless there’s a good/justified reason to create the RTF clusters in specific Business Groups, create the RTF clusters at the root org level. This way you will always be able to make the RTF cluster available to any Business Group
Logging
- For Titanium Users, Anypoint offers a Log Search panel where all the apps’ logs of the same environment are consolidated.
- This means we need to plan carefully our environments structure and make sure all the apps in every end-to-end transaction fall into the same environment. Otherwise we’d not be able to see all the logs of each transaction under the same consolidated view.
Monitoring - Custom Dashboards
- For Titanium Users, Anypoint offers Custom Dashboards, which allow us to bring metrics of different applications to the same dashboard. And, same as we’ve seen with Logging, only applications belonging to the same environment can be used in the same dashboard
- So, same rule applies here - plan carefully our environments structure and make sure all the apps you need a consolidated metrics view fall into the same environment. Otherwise we’d not be able to create custom dashboards combining the metrics of the apps we need visibility
Anypoint MQ
- Anypoint MQ is scoped at the Business Group level, meaning each Business Group gets its own isolated instanceof Anypoint MQ.
- Access to Anypoint MQ within a Business Group is controlled via Anypoint Access Management.
- Users from one Business Group cannot see or access MQ queues in another Business Group.
- Environment-specific resource - Within each Business Group, MQ queues, Message Exchanges, FIFO Queues and Dead Letter Queues are tied each specific environment. This ensures isolation between production and non-production workloads.