Understanding Telemetry Pricing for Dynamics 365 Finance & Operations (D365FO)

UNDERSTANDING TELEMETRY PRICING FOR DYNAMICS 365 FINANCE AND OPERATIONS (D365FO)

CONTENT Introduction D365FO Telemetry Capabilities Key Pricing Components (Billing Categories) for D365FO Telemetry Pricing and Average Monthly Costs Conclusion

INTRODUCTION 

Telemetry plays a vital role in managing and optimizing Dynamics 365 Finance & Operations (D365FO). Microsoft collects system events, user activities, and performance data, then streams them into Azure Monitor (Log Analytics) so administrators and auditors can gain insights.

For many organizations, telemetry is not only a technical tool but also a compliance requirement and a cost driver. SOX auditors rely on telemetry to confirm system integrity, IT teams use it for performance troubleshooting, and business leaders depend on it to measure adoption.

While telemetry is powerful, it’s important to understand that it isn’t free. Azure Monitor charges for the storage and analysis of this data, and without proper planning, costs can escalate quickly. This article explains which pricing components actually apply to D365FO telemetry, removing the noise from general Azure Monitor capabilities.

D365FO TELEMETRY CAPABILITIES

When you enable telemetry streaming in Dynamics 365 Finance & Operations (FO), the system sends diagnostic data to Azure Application Insights. This data allows administrators, developers, and auditors to analyze performance, troubleshoot issues, and even measure user adoption.

However, the telemetry that FO sends is not unlimited — it’s predefined into several categories that you can enable or disable in system parameters. Each category corresponds to a type of activity or event inside the system.

Below we break down each category in detail, how it works, and why it matters.

1. Metrics (Custom Metrics)

Numeric values that represent performance or system activity.

The system or custom code emits counts, averages, or durations. Unlike page views or errors, metrics aren’t descriptive logs but structured numbers.

Examples:

• Number of records processed in a batch job.
• Duration of a purchase order posting routine.
• Throughput of data integrations (rows per second).

Metrics allow you to set performance baselines. For instance, you can measure how long posting a sales order takes and detect when it suddenly slows down.

App Insights equivalent: customMetrics.

2. Form Runs (Page Views)

Logs every time a user opens a form in FO.

When the form lifecycle starts, FO generates a telemetry event.

Examples:

• User opens the All vendors form.
• User navigates to the Customer invoice journal form.

Helps identify which forms are used most often → supports licensing and role design.

Helps measure form performance → slow load times can be traced to SQL queries or customizations.

App Insights equivalent: pageViews.

3. User Sessions

Tracks when users log in, start a session, and when their session ends.

FO automatically generates events tied to user session lifecycle.

Examples:

• Session started for user contoso\david.
• Session ended after 30 minutes of inactivity.

Useful for audit trail of activity (who logged in and when). Helps estimate active user counts and adoption.

In App Insights, these look like custom events, but FO does not support free-form trackEvent() like a custom Azure app. You only get session tracking, not button clicks or arbitrary user actions.

4. X++ Exceptions (Failures)

Captures errors and exceptions thrown by X++ code.

Whenever business logic fails unexpectedly, FO logs it.

Examples:

• Null reference exception during invoice posting.
• Divide by zero error in a custom calculation.

Identifies coding issues or customization bugs. Essential for SOX and ITGC monitoring — recurring errors may indicate risk in financial postings.

App Insights equivalent: exceptions.

5. Custom Traces (Traces)

Developer-added messages for debugging or monitoring.

Developers call Trace::WriteLine("message") in X++ code. These messages then appear in telemetry.

Examples:

• “Workflow approval reached step X.”
• “Batch job: 500 records processed successfully.”

Lets you track business events that FO does not log by default. Can be used as a workaround to monitor button clicks or process checkpoints (since FO does not capture clicks out-of-the-box).

App Insights equivalent: traces.

6. DMF Errors

Errors from the Data Management Framework (DMF), used for imports/exports.

DMF job execution is instrumented, and failures generate telemetry.

Examples:

• Import failed because a required column was missing.
• Export timed out due to large file size.

Critical for monitoring integration pipelines. Helps teams react quickly when a nightly job fails.

App Insights equivalent: Stored as exceptions, flagged under DMF context.

7. Warehouse Events

Telemetry from warehouse operations, primarily mobile device workflows.

Warehouse mobile device activities generate structured telemetry.

Examples:

• Worker started a picking list.
• Barcode scanning failed.
• Work step “Put” completed at location A-101.

Provides visibility into warehouse execution performance. Helps identify bottlenecks (e.g., scanning errors, slow work completion).

App Insights equivalent: Shows up as customEvents or traces with warehouse metadata.

Key Takeaways

• FO telemetry ≠ Full App Insights
• FO sends only a subset of Application Insights data: metrics, form loads, sessions, traces, exceptions, DMF errors, and warehouse events.
• Detailed tracking like button clicks, field changes, or custom workflows must be customized manually.
• Telemetry systems identify which queries or processes are causing performance issues by collecting and analyzing a combination of metrics, logs, and traces (often called the "pillars of observability"). By correlating this data, they can pinpoint the source of a problem, such as a slow database query or a struggling application service.
• Telemetry monitors batch jobs for failures and unexpected durations by collecting data points like start/stop timestamps, logging events, and process status codes. The system analyzes this information against established benchmarks to generate alerts when a job deviates from its normal behavior. 
• Telemetry understands what activities users are performing in a system by collecting, transmitting, and analyzing multiple types of data, often categorized as Metrics, Events, Logs, and Traces (MELT). Software agents or instrumentation embedded within the system capture this data, which is then sent to a centralized location for analysis.
• Telemetry creates an audit trail for SOX compliance by automatically collecting, storing, and analyzing system data related to financial reporting processes. This data is essential for proving the integrity and reliability of financial information during annual audits. By continuously logging events and activity, telemetry provides a secure and verifiable history of system behavior that auditors can review.

All of these insights come from telemetry data stored and analyzed in Azure Monitor. Understanding the pricing model ensures you can keep this capability under control and align costs with compliance needs.

KEY PRICING COMPONENTS (BILLING CATEGORIES) FOR D365FO TELEMETRY

Azure Monitor pricing page lists every monitoring feature, but only a handful are directly relevant for D365FO.

1. Log Ingestion: D365FO telemetry data (errors, traces, diagnostics, performance counters) flows into an Azure Log Analytics workspace.

How pricing works: You are billed per GB ingested. This is the single largest cost driver, especially if you capture detailed telemetry across production, UAT, and development environments.

Every user action, performance event, or error written to telemetry is billed as ingestion:

• Form runs: Opening forms like All vendors or Customer invoice journal.
• System events: SQL wait times, service call performance, batch durations.
• User actions: Button clicks, navigation, error messages. (CUSTOM)
• Environment health: AOS or database performance warnings.

2. Log Retention: By default, telemetry is stored in Log Analytics for a limited free period (commonly 30–90 days depending on the log type).

How pricing works: Short-term storage is included without extra cost. If you need to keep logs for compliance (e.g., SOX requires longer audit trails), you pay a monthly fee per GB beyond the free retention period.

Costs apply when keeping telemetry longer than the free retention period:

• Keeping page view history for adoption analysis.
• Retaining batch job logs for SOX audits.
• Storing error traces for a fiscal year as part of audit evidence.

3. Queries & Dashboards: Queries on certain tables are charged per GB of data scanned. All queries in Log Analytics are written using KQL (Kusto Query Language).

D365FO telemetry data in Log Analytics is queried using Kusto Query Language (KQL) (Microsoft Docs – Log queries overview). KQL is the standard way to search, filter, and visualize telemetry in Azure Monitor dashboards.

How pricing works: According to Microsoft’s pricing model, charges for queries are based on the volume of data scanned. Larger queries or longer time ranges mean more data scanned, and therefore higher costs.

Costs depend on the amount of data scanned during analysis:

• Querying most viewed forms in the last 90 days.
• Filtering failed batch jobs across multiple legal entities.
• Reviewing SQL performance traces for optimization.

4. Alerts: Alerts help you detect issues in real time—for example, if a batch job fails or a performance counter exceeds a threshold or a vendor bank account is created.

How pricing works: You are charged for the alert rule execution, the data processed, and sometimes the notification channel.

Email notifications are free, but SMS, voice calls, or webhook integrations may generate additional charges.

Charges apply for rules and certain notification types:

• Metric alert: SQL DTU usage > 80%.
• Log alert: >10 errors in a 5-minute window.
• User activity alert: Spike in usage of Vendor bank accounts form.

5. Data Export (Optional): Some organizations export telemetry data from D365FO into other systems for compliance, SIEM integration, or long-term archiving.

How pricing works: Continuous export to Azure Storage, Event Hub, or third-party tools incurs data transfer charges. This cost is optional—you only pay if you configure exports.

Costs apply if data is exported out of Log Analytics:

• Exporting all telemetry to Azure Storage for 7-year SOX compliance.
• Streaming error logs into Event Hub for Splunk integration.
• Forwarding page view data to corporate BI teams.

PRICING AND AVERAGE MONTHLY COSTS

Telemetry pricing for D365FO is based on Azure Monitor Log Analytics rates:

• Log ingestion: ~$2.76 per GB ingested
• Data retention: First 31 days free; ~$0.12 per GB per month beyond that
• Queries: ~$0.002 per GB of data scanned
• Alerts: ~$0.10 per metric alert rule per month; log alerts depend on frequency and complexity

Typical D365FO Environment (per month) Example

Assumptions:

• 50 GB telemetry ingested (production + sandbox)
• 90-day retention (60 days beyond free)
• Moderate querying (20 queries/day, scanning 1 GB each)
• 10 active alerts

Estimated Monthly Cost

• Log ingestion: 50 GB × $2.76 ≈ $138
• Retention: 50 GB × 2 months × $0.12 ≈ $12
• Queries: 20 × 30 × 1 GB × $0.002 ≈ $1.20
• Alerts: 10 × $0.10 ≈ $1.00

📌 Total: ~$152 per month

CONCLUSION

When you enable telemetry streaming in Dynamics 365 Finance & Operations (FO), diagnostic data flows into Azure Application Insights, giving administrators, developers, and auditors the visibility they need to analyze performance, troubleshoot issues, and measure user adoption.

However, it’s important to recognize that telemetry in FO is not unlimited or arbitrary. Instead, it is structured into predefined categories that you can enable or disable through system parameters. Each category corresponds to a specific type of activity in the system:

• Metrics capture structured performance values, such as processing counts or posting durations.
• Form Runs (Page Views) show which forms users open and how they perform.
• User Sessions provide a record of logins and activity periods.
• X++ Exceptions highlight runtime errors in business logic.
• Custom Traces let developers embed diagnostic checkpoints into processes.
• DMF Errors expose problems in data imports/exports.
• Warehouse Events track operational activity in mobile workflows.

From a pricing perspective, all these categories ultimately roll into Log ingestion, Retention, Queries, and Alerts in Azure Monitor. For example, a form run is billed as a PageView event, an exception as a Failure event, and a custom trace as a Trace event — all metered under Azure Monitor’s Log Analytics pricing.

For customers, this means telemetry pricing is not just about “logs in general,” but about understanding which categories you enable, how much data each generates, and how long you choose to retain it. A compliance-heavy environment may need to retain session and exception logs for extended periods, while a performance-focused environment may emphasize metrics and traces for optimization.

By carefully choosing telemetry categories, controlling retention, and optimizing queries, you can achieve the right balance: enough visibility to meet audit and performance needs, without unnecessary ingestion and storage costs.

Designing Approval Workflows in Dynamics 365 Finance with a SOX-Compliance Lens

DESIGNING APPROVAL WORKFLOWS IN DYNAMICS 365 FINANCE WITH A SOX-COMPLIANCE LENS

CONTENT Introduction Why Every SOX Control Framework Must Include Robust Approval Workflows How D365FO Workflow Maps to SOX Control Objectives Control Design Choices That Auditors Will Question Test of Design (TOD) - Configuring a SOX-ready Purchase Order Approval Test of Effectiveness (TOE) - Executing a Sample Purchase Order Workflow Extra: Workflow Escalation: Ensuring Control Continuity Conclusion

INTRODUCTION 

In today’s regulatory landscape, internal controls are no longer optional—they are an operational necessity. For organizations subject to the Sarbanes-Oxley Act (SOX), especially Section 404, demonstrating that transactions are properly authorized, reviewed, and traceable is critical to passing an external audit. Dynamics 365 Finance and Operations (D365FO) offers built-in workflow capabilities that, when thoughtfully configured, can enforce these control requirements directly within the system. This article explores how to design and implement approval workflows in D365FO that satisfy SOX compliance expectations, with a focus on practical configuration guidance, control alignment, and audit-readiness.

WHY EVERY SOX CONTROL FRAMEWORK MUST INCLUDE ROBUST APPROVAL WORKFLOWS

Section 404 of the Sarbanes-Oxley Act (SOX) requires management to assert—and external auditors to attest—that the company maintains effective internal control over financial reporting. In practice that means every financially significant transaction must be:

1. Authorized by the right people,

2. Executed in line with documented policies, and

3. Evidenced so that an auditor can reconstruct who approved what, when, and why.

Dynamics 365 Finance & Operations (D365FO) contains a flexible workflow engine that can satisfy all three conditions—if you design it properly. Approvals, when combined with Segregation of Duties (SoD) rules, prevent the classic “create and approve my own transaction” scenario that violates SOX assertions.

HOW D365FO WORKFLOW MAPS TO SOX CONTROL OBJECTIVES

To effectively support SOX compliance, organizations must align system capabilities with specific control objectives—and Dynamics 365 Finance offers the features needed to do just that.

CONTROL DESIGN CHOICES THAT AUDITORS WILL QUESTION

Even with strong workflow tools, poorly structured configurations can raise red flags during audits; understanding what auditors scrutinize helps avoid preventable issues.

CONFIGURING A SOX-READY PURCHASE ORDER APPROVAL (TEST OF DESIGN - the parts auditors ask for)

The steps below follow a purchase order (PO) scenario because POs hit multiple SOX-sensitive accounts—Commitments, Accruals, and ultimately COGS. Replicate the same pattern for vendor invoices, journal vouchers, or project change orders.

Scenario

• Every PO must be approved by a Procurement Manager who is not the originator.
• POs ≥ USD 25 000 receive a second approval from Finance.

Step 1 Enable change management for POs

1.Navigate to Procurement and sourcing > Setup > Procurement and sourcing parameters.

2.On the General tab, activate Enable change management.

3.Set Allow override of settings per vendor to No to prevent policy bypass.

Step 2 Create a new workflow

1.Navigate to Procurement and sourcing > Setup > Procurement and sourcing workflows.

2.Click New > Select Purchase order workflow.

3.Click Run.

4.Workflow editor is loaded.

5.Workflow editor pops-up.

Step 3 Add approval elements

1.In the graphical editor, drag Approve purchase order onto the canvas.

2.Double click on the approval element.

3.Select the sub-approval step and go to step properties.

Step 4 Approval step configuration

Basic settings: Directives for the approver.

Assignment: Approver assignment.

Select participant.

Switch to Role based tab.

Select User group participants in the type of participant.

Select Purchase order approvals in the participant field.

Let's add another approval step ford the Director review & approval.

Basic settings: Directives for the approver director.

Assignment: Approver assignment. Select the director's name here.

Condition: Indicate if this step will be executed under a certain condition.

According to our scenario, order needs to be approved by the director if purchase order's total amount is equal or greater than $25K. 

Save and activate the workflow.

New workflow is ready.

Note that first level approval will be sent to "Purchase order approval" user group. Let's make sure that the user group has the correct users.

Navigate to System administration > Users > User groups

Make sure that approvers are in the correct users.

Another important workflow control is to prevent the submitter from approving the workflow.

Navigate to System administration > Workflow > Workflow parameters.

Note: I will not activate this parameter for the demo purpose.

EXECUTING A SAMPLE PO APPROVAL  TO DEMONSTRATE EVIDENCE (TEST OF EFFECTIVENESS - the parts auditors ask for)

Go to Procurement and sourcing > Purchase orders > All purchase orders and create a new PO.

I've created a purchase order and submitted it to workflow approval.

Click Workflow > Submit

Enter a justification comment.

Workflow approval step 1 has been created.

Log in as Approver user. In the work items assigned to me section, open the record.

 

Let's approve the order by selecting Workflow > Approve.

The next step is to check workflow history to see if there is an action item. Note that there is another approval pending, the director approval due to the total amount is greater than $25K.

Let's approve the order, again. 

Check the workflow history now. Note that the approval workflow is now completed. 

AUDIT NOTE: Retrieving evidence is the most important point here. Take necessary screenshots of workflow history that shows approver user IDs, timestamps, comments and system/workflow version - exportable to excel for auditors.

Note that order status is now Complete.

NOTE: Demonstrate at least two additional edge cases

• Requester tries to approve own PO—system throws an error and says submitter cannot be approver;
• Approver misses 1-day SLA—workflow escalates automatically. Details have been explained below.

EXTRA: Workflow Escalation: Ensuring Control Continuity

In a SOX-compliant environment, timeliness of approvals is just as critical as the approval itself. Workflow escalation ensures that if an approver does not take action within a defined time frame, the task is automatically reassigned to another authorized user—typically a control owner. 

In Dynamics 365 Finance, escalation is configured within the workflow step properties:

Navigate to the approval step in the workflow editor and find the related step, open the properties.

Under "Time limits", set a duration (e.g., 1 day).

Go to Escalation tab.

My configuration says:

▶️ If the workflow step is not approved in 1 day, then it will be assigned to user admin,

▶️ If the workflow step is not approved in 4 hours, then it will be assigned to user Dadiyaman,

▶️ If the workflow step is not approved in 2 hours, then it will be automatically Rejected.

This mechanism ensures control continuity, avoids bottlenecks, and demonstrates that the organization has safeguards against delayed approvals—an important consideration during SOX audits.

CONCLUSION

Designing effective approval workflows in Dynamics 365 Finance is not just a matter of system configuration—it is a control activity that directly supports SOX compliance. When implemented with a clear understanding of control objectives, approval workflows can enforce proper authorization, support Segregation of Duties, and generate the audit evidence needed to validate financial governance.

This article demonstrated how to design and execute a SOX-compliant purchase order approval process in D365FO, from activating change management to enforcing dual-level approvals and workflow escalation. Each workflow design choice—such as preventing self-approvals, using value-based conditions, or defining time-bound escalation paths—should be mapped back to a specific control objective in your organization’s risk and control matrix (RCM).

Ultimately, the goal is to move beyond simply routing transactions for approval. A properly designed workflow provides assurance to management and auditors that transactions are reviewed by the appropriate personnel, decisions are logged and traceable, and control breakdowns are systematically prevented. With D365FO’s workflow engine, compliance teams can build these safeguards directly into the business process—creating a strong line of defense against financial misstatements and audit findings.