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.

Service principal troubleshooting

  • 4 minute(s) read
Prev Next

Overview

This article covers common issues with service principal configuration in the Business Activity Monitoring (BAM) Pull Model. It addresses validation failures, permission errors, authentication problems, access policy gaps, and data source selection issues that prevent the Pull Model from querying Azure resources correctly.

Business value

Service principal failures in the Pull Model are often silent — the configuration saves without error but tracking data never arrives. This article helps you distinguish between authentication failures, permission gaps, and access policy misconfiguration so you can resolve the root cause directly.

How it works

Pull Model service principals authenticate Turbo360 against your Azure subscriptions using OAuth 2.0 client credentials. Once validated, each principal is assigned an access policy that determines which subscriptions and Business Process groups it can reach. The principal also determines which Azure data source (Application Insights or Log Analytics) is queried for each business process. Failures in any of these three areas — authentication, access policy, or data source selection — result in missing or empty transaction data.

This article covers issues that arise after initial setup. For step-by-step setup guidance, see Managing service principals in Pull Model.

Note:

Service principals in the Pull Model operate exclusively within the Data Queries type of tracking. Custom Logging deployments do not use service principals.

FAQs

  1. The service principal validates successfully but transaction data does not appear after configuring a business process.
    Cause: The service principal was validated and saved, but the access policy was not configured to include the subscription containing the Azure resource being queried. Turbo360 can authenticate to Azure but cannot reach the target resource.
    Fix: Open the service principal in Business Activity Monitoring > Service principals and edit it. On the Access policy screen, confirm the subscription that contains your Application Insights or Log Analytics workspace is selected and scoped to the correct Business Process group. Save the updated policy and wait for the next query evaluation cycle to run.

  2. The data source selection dropdown shows no Azure resources for the configured subscription.
    Cause: The service principal does not have the required reader permissions on the target Azure resource. Without read access, Turbo360 cannot enumerate available Application Insights or Log Analytics resources during data source selection.
    Fix: In the Azure portal, open the target Application Insights instance or Log Analytics workspace and navigate to Access control (IAM). Assign the Application Insights Reader role for Application Insights resources, or the Log Analytics Reader role for Log Analytics workspaces. The service principal also requires Reader access at the subscription level to enumerate available resources. See Environment setup for the full permission requirements.

  3. The client secret expires and tracking stops without any visible error in the Turbo360 interface.
    Cause: When a client secret expires, the service principal silently fails to authenticate on subsequent query evaluation cycles. BAM does not surface a visible alert when a service principal's secret expires — tracking simply stops producing new data.
    Fix: Rotate the client secret in the Azure portal, then immediately edit the service principal in BAM and update the Client secret and Client secret expiration date fields. Validate and save. To prevent future silent failures, set a calendar reminder before the current expiration date and update BAM proactively when you rotate the secret in Azure.

  4. Scope automation ran but a new subscription was not added to the access policy.
    Cause: The subscription name does not satisfy any configured automation rule condition. Scope automation matches subscriptions by name using the conditions defined in the Configure rule screen — if no rule matches, the subscription is skipped.
    Fix: Navigate to Business Activity Monitoring > Service principals, edit the relevant principal, and review the automation rules on the Access policy screen. Check whether the new subscription name matches at least one rule condition. If not, add a rule that matches it or manually add the subscription to the access policy. Scope automation runs daily at 12:00 AM UTC — if the rule is correct, the next run will apply the policy automatically.

  5. The service principal is configured correctly but query results return no data for a business process.
    Cause: The data source selected for the business process does not contain data matching the query. This can occur when the wrong Application Insights instance or Log Analytics workspace was selected during business process configuration, or when the Azure resource has no ingested data for the query window. Every BAM data query must also include the correct time field — TimeStamp for Application Insights and TimeGenerated for Log Analytics — otherwise the query returns no results regardless of what data exists.
    Fix: Open the business process configuration and confirm the data source points to the correct Azure resource. Verify directly in the Azure portal that the resource contains data for the time range the query covers. Confirm the query includes the appropriate time field for the data source type. See Top tips for data queries for required query fields.

  6. Validation fails with an "insufficient privileges" error even though the correct credentials are entered.
    Cause: The Azure AD application registration associated with the service principal does not have sufficient permissions. The service principal requires at minimum Reader access at the subscription level to pass validation, plus Log Analytics Reader or Application Insights Reader on the target resources depending on your data sources.
    Fix: In the Azure portal, navigate to the target subscription > Access control (IAM) and confirm the service principal has the Reader role. Then open the specific Application Insights or Log Analytics resources and confirm the appropriate reader role is assigned. Re-validate in BAM after correcting the permissions.

Related articles