Overview
Resource grouping in Turbo360 determines which Azure resources are included in a Business Application and how they are organized within it. Grouping decisions affect the accuracy of monitoring coverage, the clarity of service maps, the relevance of dashboards, and the operational workload of maintaining the application over time.
This article describes the principles that produce well-structured, maintainable resource groupings within Business Applications.
Business value
Thoughtful resource grouping produces Business Applications that reflect real operational boundaries, making it faster to identify the source of a failure, easier to assign ownership, and simpler to maintain monitoring rules as your Azure environment evolves.
How it works
A Business Application in Turbo360 contains a set of Azure resources that you add manually or through automated resource association. The resources within an application share a monitoring context: monitoring rules, dashboards, and service maps are all scoped to the application's resource membership.
Turbo360 does not impose constraints on which resources can belong to the same application. A single resource can be associated with multiple Business Applications, allowing shared infrastructure to be monitored in context across all workflows that depend on it.
1. Group by workflow, not by resource type
The most effective groupings reflect the end-to-end flow of a business capability; all the components that must work together to deliver a single outcome. This means a single Business Application will typically contain multiple resource types.
Prefer grouping the Logic App, Service Bus queue, Azure Function, and API Management endpoint that together deliver the order submission flow, even though they are different resource types. Avoid grouping all Logic Apps across your subscription into one application, all Service Bus namespaces into another, and so on. This fragments operational context and makes incident triage slower.
2. Use Azure resource group boundaries as a starting reference
Azure resource groups often reflect the natural boundaries of a workload (resources that are deployed together, scaled together, and owned by the same team). Use resource group membership as an initial guide when deciding which resources belong in the same Business Application.
However, resource groups are infrastructure boundaries, not always operational ones. A single business workflow may span multiple resource groups, especially in larger organizations with shared infrastructure. Do not force a Business Application's shape to match a resource group if the operational boundary is different.
3. Manage shared infrastructure components intentionally
Some Azure resources are shared across multiple workflows (a Service Bus namespace used by several integration flows, or an API Management gateway fronting multiple services). Because a resource can belong to multiple Business Applications simultaneously, you have flexibility in how you model shared components.
Consider the following approaches depending on your monitoring goals:
- Include the shared resource in each dependent application. Each application monitors the resource independently with its own rules and thresholds. Use this when different workflows have different SLAs or alert requirements for the shared resource.
- Create a dedicated Business Application for shared infrastructure. Centralize monitoring of the shared resource in one place and document the dependency in each workflow application's description field. Use this when a single team owns and monitors the shared component across all workflows.
Choose the approach that makes ownership and incident response clearest for your team.
4. Apply consistent tagging before enabling automated association
Automated resource association in Turbo360 matches resources to Business Applications based on resource group membership and Azure resource tags. Before enabling automated association, ensure that:
- Resources belonging to the same workflow are tagged consistently using a shared workload identifier.
- Resources that should not be included in any Business Application are tagged or structured in a way that excludes them from association rules.
- Tags are maintained as part of your Azure deployment process, not applied manually after the fact.
Automated association is only as accurate as your tagging discipline. Inconsistent or missing tags result in resources being excluded or incorrectly included.
5. Keep resource membership current
Resource membership in a Business Application drifts over time as Azure resources are created, renamed, or decommissioned. Stale membership causes monitoring blind spots (for resources added but not included) or false alerts (for resources decommissioned but not removed).
Establish a process to review resource membership when:
- A new Azure resource is deployed to a subscription covered by Turbo360.
- A resource is decommissioned or replaced.
- Automated association runs and produces unexpected results.
6. Avoid excessive resource counts in a single application
Business Applications with very large resource counts become difficult to interpret in dashboards and service maps. If a single application contains dozens or hundreds of resources, consider whether it can be decomposed into smaller, more focused applications; each representing a distinct sub-workflow or component boundary.
A useful heuristic: if a new team member cannot understand what the application represents and what its critical resources are within a few minutes of looking at it, the scope is probably too broad.
7. Document grouping decisions
When resource grouping decisions involve trade-offs (shared resources, cross-resource-group workflows, deliberate exclusions), document the rationale in the Business Application's description field. This information is valuable when the original owner is unavailable and another team member needs to make sense of the structure during an incident.
Example scenario
An integration team runs three production workflows: customer onboarding, invoice generation, and order fulfillment. Each workflow uses a combination of Logic Apps, Service Bus queues, and Azure Functions.
All three workflows share a single API Management gateway, which fronts external API calls for all three. The team adds the API Management gateway to all three Business Applications so that each workflow's monitoring context includes the shared component. Each application applies its own monitoring rules to the gateway, reflecting that workflow's SLA and escalation policy.
For each workflow application, the team includes a note in the description field identifying the gateway as a shared resource monitored across multiple applications, so that engineers responding to an alert understand the broader context.
Limitations
- Automated resource association does not support complex matching logic. It operates on resource group membership and tag values. Workflows with resources that are difficult to tag distinctively may require manual curation.
- Renaming or restructuring Azure resources does not automatically update Business Application membership. Manual reconciliation is required after significant infrastructure changes.
Troubleshooting
-
A resource is missing from a Business Application after automated association ran
Cause: The resource does not match the tag or resource group criteria used by the association rule.
Fix: Verify the resource's tags against the association rule configuration. Add the missing tag or manually add the resource to the application. Update the tagging standard for future deployments to include this resource type. -
A decommissioned resource still appears in a Business Application
Cause: The resource was removed from Azure but not from the Business Application's resource list in Turbo360.
Fix: Remove the resource from the Business Application manually. If automated association is enabled, review the association rule to ensure it does not re-add decommissioned resources. -
Monitoring rules for a shared resource are firing in an unexpected Business Application
Cause: The resource has been added to multiple applications, each with independently configured monitoring rules; a rule in a lower-priority application is triggering alerts that belong in another context.
Fix: Review the monitoring rules configured for the resource in each Business Application. Adjust thresholds or rule scope per application to reflect that workflow's SLA. Remove the resource from any application where it does not have a genuine monitoring role. -
Service map does not reflect the expected workflow topology
Cause: Resources that participate in the workflow are not all included in the same application.
Fix: Review the resource membership of the Business Application against the end-to-end workflow. Add any missing resources. -
Dashboard widgets are not loading for a resource in the application
Cause: The resource was recently added to the Business Application and the dashboard has not yet refreshed, or the resource type does not support the selected widget.
Fix: Refresh the dashboard. Verify that the widget type is supported for the resource. If the issue persists, remove and re-add the resource to the Business Application.