--- title: "Business application design" slug: "business-application-design" updated: 2026-10-29T11:13:41Z published: 2026-10-29T11:13:41Z canonical: "docs.turbo360.com/business-application-design" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.turbo360.com/llms.txt > Use this file to discover all available pages before exploring further. # Business application design ## Overview A Business Application in Turbo360 is a logical grouping of Azure resources that represent a single business capability, such as an order management workflow, a data pipeline, or a customer integration. How you design these groupings directly affects how clearly you can monitor health, isolate failures, and communicate operational status to stakeholders. This article describes the principles and patterns that produce well-structured, maintainable Business Applications. ### Business value Well-designed Business Applications reduce the time it takes to identify which component is responsible for a failure. They make it easier to delegate monitoring responsibility, apply targeted alert policies, and produce dashboards that reflect real operational context rather than raw infrastructure lists. ## How it works A Business Application is defined by the resources you include and the boundaries you set. Turbo360 does not enforce a particular structure; you decide what belongs together. The design decisions you make at creation time affect how monitoring rules, alerts, dashboards, and service maps behave throughout the application's lifecycle. ## Key practices Follow these practices when you create a Business Application and when you review it later. ### 1. Design around business capabilities, not resource types Group resources by what they collectively deliver, not by what type they are. A Logic App, a Service Bus namespace, and an Azure Function that together process customer orders belong in the same Business Application, even though they are different resource types. Separating them by type fragments the operational view and makes end-to-end health difficult to assess. Prefer one Business Application per business workflow or integration capability. Avoid grouping all Logic Apps together, all Service Bus namespaces together, and so on, across unrelated workloads. ### 2. Keep scope bounded A Business Application works best when its resource count is manageable and its purpose is specific. Overly broad applications, for example, one application containing every resource in a subscription, produce dashboards and service maps that are too large to interpret quickly during an incident. A useful boundary test: if two teams need to respond to failures in the same application, and neither team is responsible for the other's resources, the application should be split. ### 3. Use consistent naming conventions Name Business Applications so that their purpose is immediately clear to anyone with access to Turbo360. Include the workload name and, where relevant, the environment: - `Order Processing – Production` - `Customer Sync – UAT` - `Invoice Pipeline – Development` Avoid abbreviations that are not widely understood within your organization, and avoid names that duplicate subscription or resource group names without adding context. ### 4. Separate environments explicitly Do not mix production and non-production resources in the same Business Application. Create separate Business Applications for each environment. This ensures that: - Monitoring rules and alert thresholds can be tuned independently per environment. - Alerts from development or UAT do not create noise in production dashboards. - Access to production monitoring can be restricted to appropriate roles without blocking developer access to lower environments. ### 5. Plan resource association before configuring monitoring Monitoring rules and alert policies in Turbo360 are configured at the Business Application level and apply to the resources within it. If you add or remove resources after configuring monitoring, review your rules to confirm they still reflect the intended scope. Use the automated resource association feature to keep resource membership current when your Azure environment changes, but validate the results periodically to ensure no unintended resources have been included. ### 6. Use resource groups as a starting reference, not a hard boundary Azure resource groups are a useful starting point for identifying which resources belong together, but they do not always align with business capabilities. A single business workflow may span multiple resource groups. A single resource group may contain resources from multiple unrelated workflows. Use the resource group structure as input to your design, not as a constraint. ### 7. Document the purpose of each Business Application Use the description field to record what the application does, who owns it, and what the expected monitoring baseline is. This information is valuable when a team member who did not create the application needs to respond to an alert. ## Example scenario An Azure integration team manages three workflows: customer onboarding, order fulfillment, and invoice generation. Each workflow uses a combination of Logic Apps, Service Bus queues, and Azure Functions. Rather than creating one large Business Application for all integration resources, the team creates three separate Business Applications, one per workflow. Each application groups the Logic Apps, Service Bus topics, and Functions that belong to that specific workflow. Monitoring rules and escalation policies are configured independently for each, reflecting the different SLAs and on-call teams responsible for each workflow. The team's shared Service Bus namespace is added to all three Business Applications, since it is used by each workflow. Monitoring for the namespace is configured independently within each application to reflect that workflow's thresholds and escalation policies. When a failure occurs in order fulfillment, the alert fires only within that application's context. The on-call engineer sees exactly which resources are involved without needing to filter through unrelated components from other workflows. ## Limitations - Automated resource association uses resource group membership and resource tags as matching criteria. Resources that do not conform to your tagging convention may not be included automatically and will need to be added manually. - There is no built-in template or clone operation for Business Applications. You must configure each application's monitoring rules, dashboards, and alert policies individually. ## Related articles - [Managing Business Applications](https://docs.turbo360.com/docs/managing-business-applications) - [Automated resource association](https://docs.turbo360.com/docs/automated-resource-association) - [Configuring a service map](https://docs.turbo360.com/docs/configuring-service-map) - [Monitoring strategy](https://docs.turbo360.com/docs/monitoring-strategy) - [Resource association issues](https://docs.turbo360.com/docs/resource-association-issues) - [Unexpected alerts and service map issues](https://docs.turbo360.com/docs/unexpected-alerts-and-service-map-issues)