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.

Strengthening Internal Controls with User Termination in D365FO

CONTENT Introduction Importance of User Termination in a SOX Environment Terminate User and Remove Their Security Roles Alternative: Disable User and Remove Their Security Roles Address Workflow Delegations Monitor Batch Jobs Monitor Disabled and Deleted Users via Database Logging Conclusion

STRENGTHENING INTERNAL CONTROLS WITH USER TERMINATION IN D365FO

Introduction

User lifecycle management is one of the most critical aspects of securing any ERP system, and Microsoft Dynamics 365 Finance and Operations (D365FO) is no exception. From the moment a user is onboarded to the time their access must be revoked, organizations must ensure that system access aligns with employment status and compliance requirements.

In a Sarbanes-Oxley (SOX) regulated environment, user termination becomes more than just a technical activity—it is a key internal control. When employees, contractors, or consultants leave the organization, their access to the system must be promptly revoked to prevent unauthorized activities, reduce fraud risk, and maintain the principle of least privilege.

This article explains the steps, options, and considerations for terminating users in D365FO. It provides practical instructions, highlights SOX compliance implications, and points out potential pitfalls if termination is not handled effectively.

Importance of User Termination in a SOX Environment

SOX Section 404 requires companies to establish and maintain adequate internal controls over financial reporting. One of these controls is ensuring that only authorized personnel have access to financial systems like D365FO.

Failure to properly terminate users creates several risks:

• Unauthorized Access: Former employees may still be able to log into the system.
• Segregation of Duties (SoD) Violations: Inactive but enabled accounts could be exploited, creating audit findings.
• Workflow Disruption: Unattended approvals may remain pending if workflow delegations are not reassigned.
• Batch Job Failures: Critical scheduled processes may stop running if they are tied to a disabled user account.

Therefore, an effective user termination process in D365FO must include technical steps (role removal, account disabling, workflow reassignment) as well as compliance checks to verify that no residual risks remain.

Terminate User and Remove Their Security Roles

The preferred approach is to terminate users directly in D365FO using the HR framework. If your environment integrates HR and system access, user termination can be initiated from the Employees form.

1. Navigate to Human Resources > Workers > Employees.

2. Select the employee record.

3. In the Action Pane, under Personnel actions, click Terminate.

4. Select the termination action, enter the termination date, and save the record.

If personnel actions workflows are enabled under HR Shared Parameters, the termination can be routed for approval before becoming effective.

5. OPTIONAL: Execute the termination workflow if selected personnel action type requires a workflow approval.

Workflow submission

  Workflow approval  

Workflow completion

Employee determination

Once the termination is processed, you should also ensure the user’s security roles are removed. This step is critical because it directly revokes system privileges and ensures compliance with SOX. 

NOTE: A standard termination workflow in Dynamics 365 for Finance and Operations (D365FO) does not automatically disable a user account. The standard workflow process in Human Resources primarily handles the worker's employment status, moving them from active to terminated. The user account and security roles must be handled separately.

6. User termination and security role removal 

User termination and security role removal - Before

User termination and security role removal - After

Alternative: Disable User and Remove Their Security Roles

In some organizations, HR and IT systems are not fully integrated, or there may be licensing constraints preventing full use of the HR module. In these cases, you can directly disable a user account in D365FO.

1. Go to System Administration > Users > Users.

2. Select the user record.

3. Toggle the Enabled field to Off.

4. Remove all assigned security roles as shown in the previous section.

This approach is faster but less structured compared to personnel action termination. However, it still meets the SOX requirement of revoking access promptly.

Address Workflow Delegations

Terminated users may still be assigned workflow tasks or delegation rules. If these are not reassigned, business processes (such as vendor invoice approvals, purchase requisition approvals, or journal approvals) could stall. There isn’t any screen that shows all delegations in D365FO, but there is a workaround — a table stores that information: WorkflowWorkItemDelegationParameters

To identify active delegations, use the following link in your environment:

<yourD365FOurl>/?mi=SysTableBrowser&tablename=WorkflowWorkItemDelegationParameters

This opens the table browser to review current workflow delegation records.

Any delegations tied to the terminated user should be reassigned to active employees.

Monitor Batch Jobs

Another critical check is to monitor background batch jobs. Many automated processes in D365FO—such as periodic invoicing, financial consolidations, or integrations—run under a specific user account. If a terminated user owns a batch job, the process may fail after their account is disabled.

To monitor this:

1. Go to System Administration > Inquiries > Batch Jobs.

2. Review the Run by field for each job.

3. Recreate critical jobs with a valid service account or another active user.

This review is especially important during offboarding to prevent system disruptions.

Monitor Disabled and Deleted Users via Database Logging

As a detective control, organizations can enable Database Logging in D365FO to track changes to user accounts. This ensures auditability of user termination activities and provides evidence during SOX testing.

Recommended logging events include:

• User creation
• User deletion
• User enabled/disabled changes
• Security role assignments and removals

For example user activation/deactivation can be followed as below:

Note that the above screen shows enabled and disabled users, giving admins full visibility to take necessary actions.

Database logging not only provides assurance but also strengthens the organization’s ability to demonstrate compliance during external audits.

Conclusion

User termination in D365FO is not just about removing access—it is about safeguarding financial data, preventing fraud, and ensuring compliance with SOX requirements. By following a structured process that includes terminating or disabling users, removing security roles, reassessing workflow delegations, monitoring batch jobs, and tracking changes through database logging, organizations can significantly reduce risk.

An effective termination process bridges the gap between IT operations and compliance, providing assurance to management, auditors, and regulators. Whether you use the HR-driven personnel action approach or the direct disablement method, what matters most is consistency, timeliness, and proper documentation.

In short, closing the door properly when a user exits is just as important as granting them access in the first place.

Enabling the Three Lines of Defense in Dynamics 365 Finance & Operations - LINE3: Internal Audit Assurance

ENABLING THE THREE LINES OF DEFENSE IN DYNAMICS 365 FINANCE & OPERATIONS - LINE3: INTERNAL AUDIT ASSURANCE

CONTENT Introduction Line 3 Internal Audit in a D365FO-Centric Environment Independent Assurance Through System Evidence Reviewing Transaction and Ledger Integrity Validating Control Execution and Effectiveness Sampling and Testing High-Risk Transactions Auditing Configuration Changes and Access History Leveraging Reporting and Data Extraction Tools A Third Line Scenario: From Audit Request to Finding Conclusion

INTRODUCTION 

The Third Line of Defense within the Three Lines of Defense (3LoD) model is responsible for independent assurance. Unlike Line 1 (which executes controls) and Line 2 (which monitors and oversees), Line 3 evaluates whether the control framework is designed appropriately, operating effectively, and aligned with the organization’s compliance obligations.

In a Microsoft Dynamics 365 Finance & Operations (D365FO) environment, Line 3 does not create workflows, assign roles, or approve transactions. Instead, Internal Audit uses the system’s data, logs, and reports to test and verify that Lines 1 and 2 are performing their responsibilities and that risks are being managed within tolerance.

This article focuses on how internal audit teams can use D365FO’s capabilities—alongside standard audit methodologies—to perform independent reviews and produce evidence-based assurance for stakeholders such as the audit committee, regulators, and external auditors.

LINE 3 | INTERNAL AUDIT IN A D365FO-CENTRIC ENVIRONMENT

Internal Audit’s primary value lies in its objectivity. It operates separately from both operations and compliance functions, ensuring that its assessment is unbiased and evidence-driven. In D365FO, this objectivity is enhanced by the system’s ability to generate immutable records of transactions, changes, and approvals.

Typical responsibilities of Line 3 include:

• Assessing whether controls designed by Line 1 and monitored by Line 2 are functioning as intended
• Reviewing the completeness and accuracy of transaction data
• Identifying process gaps or control weaknesses not previously detected
• Recommending improvements to strengthen the overall control environment

INDEPENDENT ASSURANCE THROUGH SYSTEM EVIDENCE

1. Reviewing Transaction and Ledger Integrity

Internal auditors frequently begin by validating the accuracy and completeness of financial transactions. In D365FO, this involves:

• Using General ledger > Inquiries > Voucher transactions to trace transactions from source documents to ledger postings
• Verifying that subledger entries (e.g., Accounts Payable, Accounts Receivable, Fixed Assets) reconcile to the general ledger
• Checking for manual journal entries that bypass standard workflows

View of subledger journal of a purchase order invoice (Voucher transactions inquiry showing linkage between subledger and ledger entries)

2. Validating Control Execution and Effectiveness

Line 3 evaluates whether preventive and detective controls are consistently applied. This includes:

• Reviewing workflow history to ensure approvals occurred as designed
• Checking whether SoD violations identified by Line 2 were remediated or mitigated
• Confirming that exception handling processes were documented and followed

D365FO’s workflow history logs and exported SoD violation reports are primary data sources for these validations.

View of workflow history screen with an invoice approval chain

3. Sampling and Testing High-Risk Transactions

Internal Audit applies sampling methods (statistical or judgmental) to test transactions for compliance with policy. Examples include:

• Testing a sample of vendor changes to verify proper approval and supporting documentation
• Reviewing high-value payment transactions for dual authorization evidence
• Confirming that purchase orders over threshold values received required managerial approvals

Sampling can be done by exporting data from D365FO using Data Management > Export into Excel or Power BI for analysis.

4. Auditing Configuration Changes and Access History

Unauthorized or undocumented configuration changes can weaken controls. Internal Audit reviews:

• Database Log entries for high-risk tables (e.g., posting profiles, vendor bank accounts)
• Historical user role assignments to detect privilege escalation
• Removal of access for terminated employees

While D365FO’s native tools provide much of this data, external solutions like Fastpath or Guardian may enhance visibility, especially for historical access reporting.

View of database log entries showing a change to a vendor’s bank account.

5. Leveraging Reporting and Data Extraction Tools

To streamline evidence collection, Line 3 can leverage:

• Task Recorder to document test steps for re-performance by external auditors
• Data entities to pull standardized datasets for repeatable audits
• Power BI integration to visualize trends in control exceptions and workflow performance

By using system-generated evidence, Internal Audit reduces reliance on manual screenshots or user attestations, improving both efficiency and credibility.

A THIRD LINE SCENARIO: FROM AUDIT REQUEST TO FINDING

Imagine Internal Audit is performing a quarterly review of vendor master data changes:

1. Audit extracts vendor bank account changes from the Database Log for the last 90 days.

2. A sample is selected focusing on changes made outside normal business hours.

3. One entry shows a bank account change by a user whose role assignment was supposed to be temporary.

4. Further investigation reveals the role removal was delayed, allowing the user to make changes after their project ended.

5. Audit issues a finding recommending stricter monitoring of role deactivations and improved coordination between HR and IT.

This example illustrates how Line 3 moves beyond detection—providing recommendations that close process gaps and strengthen Lines 1 and 2.

CONCLUSION

The Third Line of Defense in D365FO is not about running the business or overseeing it—it’s about independent validation that both are working as intended. By leveraging D365FO’s inquiry screens, workflow histories, database logs, and data exports, Internal Audit can perform efficient, evidence-based reviews without disrupting daily operations.

When Lines 1 and 2 perform their roles effectively, Line 3’s job becomes one of confirmation and continuous improvement—ensuring that the organization’s control environment is not only compliant, but resilient.

This completes the three-part series on enabling the Three Lines of Defense in Dynamics 365 Finance & Operations. Together, these articles provide a blueprint for embedding operational control, compliance oversight, and independent assurance into your ERP system.