For a more simple overview see at the bottom of this blog, that also includes a calculator.

Microsoft is changing how infrastructure works in F&O apps. In unified environments, elastic compute replaces fixed environment tiers with a shared-capacity model that automatically scales based on actual usage. Instead of choosing a Tier 2, Tier 3, or similar size up front, sandbox and production environments draw from a common Power Platform capacity model.

In practical terms, this means customers no longer plan around fixed infrastructure sizes in the same way. The AOS tier remains the core compute layer, but the number of AOS instances can increase as demand grows. Microsoft describes this as a model where compute scales with real workload rather than with a preselected environment tier.

Microsoft’s published reference points are important. Each AOS instance aligns with 650,000 Power Platform Requests, or PPRs. Sandbox and production environments have a minimum of two AOS instances, and an environment can scale up to 80 AOS in total, split across up to 40 interactive and 40 batch instances. Unified Developer Environments are the exception and stay fixed at one AOS.

Why this is simpler

The big shift is that capacity is no longer something you buy as a named infrastructure tier. Instead, capacity comes from a tenant-wide PPR entitlement. Microsoft defines that entitlement as 500,000 base PPRs, plus 5,000 PPRs for each assigned user license, with optional 50,000-PPR add-on packs when more headroom is needed.

That makes the model easier to explain to customers. The old question was, “Which environment tier do we need?” The new question is closer to, “How much workload do we expect, and how much shared capacity do we want available?” That is a simpler model operationally, but it also means customers need to think more about usage patterns across the tenant.

Cost follows workload

PPRs are not presented by Microsoft as a direct per-request price list, but Microsoft does sell 50,000-PPR add-on packs. That gives customers a practical reference point for understanding what extra headroom may cost, even though the exact commercial price can vary by region and agreement.

The important change is conceptual. Under the old model, customers often paid for fixed capacity whether they used it fully or not. Under elastic compute, idle baseline capacity becomes less of a planning problem, while heavy activity becomes much more visible. High concurrency, API bursts, Dataverse-driven traffic, and large batch workloads are now the things that matter most.

There is also no rollover concept here. Power Platform request limits are measured over a rolling 24-hour period, so unused request headroom is not something customers can bank and carry forward into a later spike. That reinforces the idea that this is a live consumption model rather than a stored monthly allowance.

The most important thing to understand: 5,000 and 40,000 are not the same number

This is where many people get confused. Microsoft uses one model for elastic-compute capacity and another for licensed-user request limits. For elastic compute, the number is 5,000 PPR per assigned user license, added to the tenant-wide base of 500,000. That number helps determine how far environments can scale.

Separately, Microsoft documents licensed-user Power Platform request limits. For paid Dynamics 365 Enterprise users, the documented request limit is 40,000 requests per user per 24 hours in the request-limits model. That number is relevant for request-limit behavior and throttling, but it should not be added into the elastic-compute AOS calculation. These are two different mechanisms answering two different questions.

A useful way to explain it is this. The 5,000 figure helps answer, “How much elastic-compute capacity does this license contribute to the tenant?” The 40,000 figure helps answer, “How many Power Platform requests can this licensed user make in a 24-hour period before request limits become relevant?” They are related, but they are not interchangeable.

Example: 100 Supply Chain Management users

Take a customer with 100 assigned Supply Chain Management users. For elastic compute, Microsoft’s formula gives 500,000 base PPR plus 100 × 5,000 PPR, which equals 1,000,000 PPR. Microsoft’s own example table maps that to 2 AOS of capacity.

So the way customers should think about this is not, “100 users means 4,000,000 PPR for scaling.” That would be mixing the user request-limit model with the environment capacity model. For elastic compute, the relevant number is the 1,000,000-PPR tenant entitlement, not the 40,000-per-user request-limit figure.

It is also important to remember that attach licenses do not create extra platform entitlements. Microsoft’s licensing guide states that attach licenses do not include additional platform entitlements and instead use the entitlements of the assigned base license. So customers should not assume that a base license plus an attach license doubles their elastic-compute accrual.

Multiple environments still matter

Even though sandbox and production now use the same elastic-compute model, customers still need to think at tenant level. Test, UAT, Golden, and other environments are no longer planned as isolated fixed tiers. They sit within the same overall capacity model, and operational demand across them can still matter when testing, refreshes, migrations, integrations, and batch processing happen in parallel.

This becomes especially relevant during implementation. At that stage, customers often have several active environments before the final production licensing position is fully established. If those environments need to scale during migration, test cycles, or parallel workload periods, extra 50,000-PPR add-on packs may need to be purchased temporarily until the final licensing model is in place.

What gets cheaper, and what gets harder

The part that likely becomes cheaper is unused infrastructure. Customers no longer have to overbuy fixed tiers just to be safe. Baseline environments and idle capacity become less wasteful, and sandbox-versus-production planning becomes simpler because both follow the same capacity model.

The part that can become more expensive is sustained activity. Heavy integrations, API traffic, Dataverse calls, and large batch workloads now translate more directly into visible capacity demand. The model is more efficient, but it also makes cost more sensitive to actual usage.

That also makes budgeting a bit harder. Under fixed tiers, infrastructure cost was easier to predict even if it was inefficient. Under elastic compute, customers may need to adjust PPR capacity over time, especially in projects with fluctuating demand or several active environments. The model is cleaner technically, but less static financially.

So if you don’t have more PPR capacity available and want to add a second sandbox environment, expect to buy 40 PPR add-on packs at approx 50 USD each = approx 2.000 USD/month.

And if you need additional DB capacity remember to pick up some Dataverse Database Capacity add-on at 40 USD/GB/Month.

A few important limits to keep in mind

Not all compute is fully covered by this model today. Components such as Commerce Scale Unit and eCommerce-related workloads are not clearly described as part of the same elastic-compute model in the public documentation, so customers should be careful not to assume full alignment there yet. This is still a moving area.

It is also worth noting that unified environments are managed through the Power Platform Admin Center, not through Lifecycle Services. Microsoft’s current documentation explicitly positions finance and operations unified environments as PPAC-managed with zero LCS footprint.

Final thoughts

Elastic compute is a meaningful shift for F&O. It replaces fixed tiers with a shared, PPR-driven capacity model, gives sandbox and production the same compute framework, and allows customers to add capacity without going through the old infrastructure process.

The simplest customer takeaway is this: stop thinking in tiers, start thinking in workload. If the workload is light, the model is simpler and often more efficient. If the workload is heavy or unpredictable, the model is still flexible, but it requires closer attention to capacity, integrations, and budgeting.

PS: AI helped with parts of this post, but I’m the author.

References :
Licencing information : https://www.microsoft.com/en-us/licensing/product-licensing/dynamics365
Microsoft documentation on elastic compute with F&O: https://learn.microsoft.com/en-us/power-platform/admin/unified-experience/elastic-compute

And I got this from a friend (if he want’s to share his name, he can comment 🙂 ):

In D365 Commerce, product attributes are commonly used to store information that is shown or used for filtering in eCommerce. These attributes are linked to the product (not the released product) and can support multiple languages.

For background on attributes, see Microsoft documentation.

How Attribute Values Are Stored

The data model behind attributes is quite complex. It follows a normalized database structure (Third Normal Form), which ensures clean and consistent data.

For text-based attributes, two main tables are involved:

• EcoResValue → stores the actual attribute value
• EcoResTextValueTranslation → stores translations of that value

How Search Uses Attribute Values

Azure AI Search primarily uses values from:

• EcoResTextValueTranslation

If no translation exists, it falls back to the system language (typically en-us).

However:

• If no translation record exists at all, the attribute value may not be indexed or searchable

The Core Issue

There is a method in the system intended to create a default translation:

But in practice:

• This method is never automatically called
• The EcoResTextValue table does not even have an insert method

This means that when a new attribute value is created:

• No translation record is created
• Azure AI Search may therefore not pick up the value

Manual Workaround

When opening attribute values from a product, you will see a “Translate” button:

Using this button:

• Creates the required record in EcoResTextValueTranslation
• Ensures the value is available for search

Important detail:

• If you update an existing attribute value, the translation record is updated correctly
• The issue only occurs during initial creation

Status

This behavior has been reported to Microsoft. A fix is expected, but no confirmed timeline is available.

Summary – Customer Impact

This issue affects how product attributes appear in search and filtering:

• Attribute values may not be searchable in eCommerce
• Filters based on attributes may not work as expected
• Missing translations can lead to inconsistent or incomplete product data in storefront

What this means for customers:

• Products may be harder to find
• Filtering and navigation can be unreliable
• Additional manual steps (translations) are required to ensure correct behavior

In the first “ping” test blog post, we tested the response time of the SQL. This time we will use the “performance test” feature to test the AOS/Web Server response time.

Open up the “Performance test” form, and only perform record count to test to 10 records, and only test insert:

Then you click “F12” to open the DevTools, and filter on “ProcessMe”.

As you click “Run” 10-30 times and look at the “time column”:

If you are on average between 100ms and 200ms, I think that the response time from the AOS are OK. A few spikes may happen.

But if your number are sometime seconds:

This means you are in trouble, and should probably create a support request. There is a high probability that something is not right, and a lot of users are not happy about the respons time of their application.

When I know the reason why I sometimes see such behavior, I’ll let you know.

Update 06/02/2026: It’s AOS memory! Ask for more, and the delays disappear 🙂 Normally we get 16Gb. 32Gb is much better.

In Unified pricing you can define the base price both for sales, inventory and for purchase. If you choose to use purchase price as the base price, you will probably activate a base purchase price like this:

For the system to use this purchase price in your purchase orders you need to specify this on the released product:

This will ensure that when you create a purchase order line, then it will fetch the purchase price from the base active purchase price:

If you still see that the purchase price is fetched from trade agreement, it means that you also need to disable the trade agreement activations:

This can also applied to sales orders. So disable trade agreements you don’t need when using Unified pricing.

Another benefit you get from this is better performance, as the searching for price have several loops, and by disabling the search on different trade agreements you also get a better performance.

The following documentation is important when implementing Unified Pricing Management : https://learn.microsoft.com/en-us/dynamics365/supply-chain/unified-pricing-management/upm-base-price-determination-rules

Thanks to Vegard for figuring out this detail.

I see 2 new parameters in 10.0.46, that I think can improve the usability when searching for sales orders.

The “Max. number of sales orders in list” is maximum number of sales orders that can be displayed in the All sales orders and Sales order details pages. A value of zero disables the limit. Microsoft is recommending setting this up to 200 for optimal performance and usability.

The “Disable sales order details grid” is also a great new feature, as it removes the left side order grid

The latter have been a pain, and made the sales table screen lagging and with this improvement, the sales order screen should be easier and faster to navigate in.

There are one thing I still feel is missing, and that is that when performing a refresh “Shift-F5” I still see that delayed datasources are loaded, and this load can be slow. Especially the outerjoin towards CUSTINVOICETRANS that I see in many cases can take seconds when performing a refresh.

I see there is a flight named SalesTableFormExcludeCustInvoiceTransFlight, but this does not seem to have any effect when doing Shift-F5 refresh.

So… Navigating Sales order can be faster in 10.0.46 👍

We in Scandinavia love our “Æ,Ø,Å”. They enrich our language, but they can cause issues in Dynamics 365 F&O. Here are one specific example; When using Unified Pricing Management we can have attributes controlling pricing. Often the attributes have values containing “Æ,Ø,Å”. Like Vendor in EN-US = “Leverandør” in NB-NO. To speed up things, Microsoft have implemented hashing. To do this, the key is encoded like this:

The issue with System.Text.Encoding::Default.GetBytes(_hashKey) is that

• Depends on server locale (That is often Windows-1252 or similar)
• Breaks Scandinavian characters
• Causes non-deterministic hashes across environments
• Can change after OS updates

It is recommended to rather use UTF-8, explicitly. basically :
System.Byte[] hashKeyBytes = System.Text.Encoding::UTF8.GetBytes(_hashKey);

I did a search through all X++ code and there are 13 times that Encoding::Default is used:

I have alerted Microsoft already, but if you struggle with “Æ, Ø, Å”, then please look into if Encoding::Default is used somewhere.

“Blåbærsyltetøy- og småbåtshavnstøtte behandles som et avvik i Dynamics 365″

“A picture can tell more than a 1000 words.” But a video can tell even more.(Unless it is fake AI generated).

When implementing Dynamics 365 we often use DevOps to document requirements, tasks and bugs. But did you know there is a very quick and easy way to attach a small video to you work items ?

I use the “Snipping Tool” a lot to take screenshots, but this can also record video’s within a specified area.

Start the process by clicking: Windows logokey + Shift + S

Then select the video tool:

The select the area you want to record, and start/stop recording. Also use Zoomit to make marks.

So far so good… But here are the super trick. In the Snipping Tool that pops up click on “GIF”:

And then select “Copy”:

This allows you to paste(CTRL-V) a video into DevOps, documents, emails etc. And even into blogs:

Small things matter also 🙂

If you look into where your DB is going, then in some cases the following two views pop’s up as occupying quite a lot of space:

PERF_INVENTDIM_INVENTSUM, and PERF_INVENTDIM_WHSINVENTRESERVE

At one customer they took :
AXDB.PERF_INVENTDIM_INVENTSUM 106.74 GB
AXDB.PERF_INVENTDIM_WHSINVENTRESERVE 96.33 GB

In 2021 -> 2022 Dynamics 365 went trough some major inventory performance redesign introduced around version 10.0.25–10.0.27. Eliminating the need to join InventSum ↔ InventDim for most queries Improved on-hand calculation performance, especially for:

• Reservation hierarchy queries (WHSInventReserve)
• Recalculation jobs (InventSumRecalcItem)
• On-hand queries via InventOnHand* views
• Simplified indexes: Each denormalized InventSum row now carries its own dimension attributes.

But in the process of improvements, there where some workflows that created these tables. But they are of no use any more.

Just create a support case, and Microsoft will remove them, and you regain your Gig’s 🙂

Hopefully Microsoft will also flush out these views in a future update.

In many projects, we lose momentum not because people resist change — but because we wait too long for consensus. We keep discussing until everyone agrees. And then time flies by, costs accelerate and we fail on success criteria’s. Chasing the perfect decision means often results in winning the fight, but loosing the war. Project resources are not endless and most often have constrains we commercially must respect.

But real progress often starts when we shift our goal from consensus to consent, where we move from “everyone says yes” to “no-one says no“.

In any projects, there are a lot to clarify, but we cannot wait for everybody to agree. We need to speed up, and on some cases take a chance on direction. Things get more clear as we move on one direction. Doing something is most often better (and cheaper), than doing nothing. (playing the costly waiting game)

So how do we implement a consent model ?

1. Start with a proposal
2. Establish ownership
3. Set a due date
4. Ask for input
5. Resolve objections
6. Decide and document
7. Revisit if necessary

What you will experience is that decisions accelerate, and the projects starts getting momentum and speed. Try it 🙂

If you use D365 Commerce, then you are most likely also have some CSU (Commerce Scale Units). Sending and receiving data frequently can quickly take a lot of preciouses GB of storage, that you want to use for other purposed.

To see if you need to clean up, go into download sessions in the “Retail and Commerce” module, and see if you have a lot of old stuff like this:

If you do, then setup go into Commerce Scheduler parameters, and specify your retention period and then click on the “Purge history data”:

This will purge upload session, download sessions and a few other elements. You do not need to run his on a high frequency, and typically set it up for weekly or monthly.

Every ‘bit’ removed becomes savings down the road.

Microsoft has now published a new FastTrack use case for the Sales Order Agent in D365 . This shows how AI is becoming an integrated part of ERP—automating order intake and reducing manual effort.

What is the Sales Order Agent?

The Sales Order Agent acts as a virtual assistant. It can read customer emails, create sales quotes, check stock availability, and convert quotes to sales orders. The agent can also handle follow-up questions if the request is unclear.

The goal is simple: reduce repetitive data entry, speed up processing, and let people spend more time on value-adding tasks.

See the use case here

If you are working with D365, the Sales Order Agent is worth exploring. It shows where ERP is going—towards more automation, more intelligence, and less manual work.

(Chatty helped with writing these complex sentences, but the Sales Order Agent does still seem cool)

In my chase for millisecounds, here are a small one. If you are not using the TMS – Transportation Management module, but are using the WMS, then there are some costly validations on the sales order header. There is a hardcoded x++ parameter you can extend to prevent some heavy queries. The effect is that the following menu items is “deactivated”:

The query code you are skipping is a quite heavy 100 ms select with a join between WHSLoadTable and WHSWorkTable. In my world, 100ms is a lot for a query, and it is executed each time you select a sales order.

As seen, you need to create a small extension to the class TMSGlobal::skipTMS(). The forms/tables using this check is the following:

I would hope that instead of a hard-coded extension, Microsoft could make a parameter instead.

As others have written, the 10.0.44 preview is now made available, and it gives a glimpse of what is to come in June. A lot have already been shared in blogs and LinkedIn feeds. But I like to go deeper, and this time I found a jewel that I think will have a noticeable performance impact. See https://fix.lcs.dynamics.com/Issue/Details/?bugId=976894&dbType=3

What is issue are explaining is that when a record is inserted on another AOS, then the cache is flushed on the table in question. In essence, this means that each AOS have to recache the data. Two tables that are quite recognizable that have Cache Lookup = found is SalesTable and SalesLine.

So one of the issue I have seen, when looking for performance, is that data that should be cached, the kernel are performing queries towards the DB, while the expectation is that the data should be fetched from cache.

I don’t have any clear measurements on what the actual impact will be, but I know for sure that caching is one of the main mechanisms for improved performance and user experience.

Good catch Microsoft! We need more of these generic performance improvements.

Some time ago, the export to datalake and was deprecated, and the it’s time to do some more house cleaning.  Also, the Power BI embedded reports seams to struggle keeping up in the latest version. Especially if you have played with the Entity store available as a Data Lake.

In our own PROD, the BIINCREMENTALTABLEMODIFICATIONS was 326 Gb.  Dataverse Database Capacity at 40 $ / GB would mean an additional cost of 156.480 $ per year for us, so we had to clean up.

More specifically on the table BIINCREMENTALTABLEMODIFICATIONS, in contains 3 fields, and keeps track of incremental updates to entity store.

To see if you have a lot of data you may open in in F&O by using this URL: &mi=SysTableBrowser&Tablename=BIINCREMENTALTABLEMODIFICATIONS.

Or checkout your Capacity here, and see it your installation is affected https://admin.powerplatform.microsoft.com/resources/capacity#summary

If you see that the you are consuming a lot of DB capacity towards the table BIINCREMENTALTABLEMODIFICATIONS, I would suggest that you create a support ticked to get it flushed out. 

Keep your PROD “trimmed” and healthy, and you are rewarded with performance and reduced licensing costs.

EventCUD is a table normally used for handling change based and due dates alerts in Dynamics 365 F&O.  The details of this process is available here : https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/fin-ops/get-started/alerts-managing

But up until 10.0.38, there was a bug, that could led to orphan “triggers”

The fix from Microsoft does not fix orphan triggers originating from before this fix, so you have to open a support ticket to get it fixed, and also to get the EventCUD table truncated

The way you can identify if you are affected by orphan triggers is to open the D365 with the following URL parameters &mi=SysTableBrowser&Tablename=EventCUD. Then look for lines with old created dates:

You should also look for CUDTableId’s not matching your table ID’s on the alerts and database logging.

If you have a “full “ EventCUD and “orphan triggers”, and clean them up, you should experience some performance gains.

And last comment.  Please avoid logging and alerting on high frequency transaction tables.  Take care 😊

You often hear phrases like:

• “The system is slower today.”
• “Nothing is working!”

Performance in Dynamics 365 is a critical aspect for both users and system owners. For end users, poor performance can lead to frustration, while system owners face challenges in identifying and resolving performance issues. To help streamline this process, I’ve created a practical checklist that outlines steps to quickly diagnose and discuss sudden performance issues.

Below is a step-by-step guide to find the root cause of performance issues and take appropriate action.

Step 1: Check Azure Status

Even if you don’t fully understand what’s causing the slowdown, there are some quick first checks you can do:

1. Microsoft health status: https://status.cloud.microsoft/ give a short summary status of Microsoft Cloud
2. Azure speed test: https://azurespeedtest.azurewebsites.net/ let’s you see the current ping times to Microsoft data centers.
3. Azure Status: Visit the Azure Status page to see if there are any global issues that affect performance.
4. DownDetector: Use DownDetector for real-time reports of problems from users globally.
5. Twitter: Check Azure Support on Twitter for any recent announcements of issues.
6. Power Platform: Visit Power Platform Help and Support for service health reports and known issues.

If these resources show global issues, it’s likely that the problem is already being addressed. Inform your users and take a short break, knowing Microsoft engineers are working to resolve the issue.

Step 2: Use Lifecycle Services (LCS) for Telemetry Data

Once you’ve ruled out Azure-wide issues, the next step is to analyze your environment’s performance data.

1. Environment Monitoring: In LCS, navigate to environment monitoring to get an overview of your system’s status.
2. Check SQL Utilization: Look for any long-lasting peaks in SQL utilization that show performance bottlenecks.
3. Analyze AOS Performance: Check if any of the Application Object Servers (AOS) are struggling.

If no clear issues are identified, proceed to:

4. SQL Insights: Look for any heavy queries or blocks in the system. This will help you spot any ongoing processes causing delays.
5. Review Activity Logs: Check for long-running queries or errors in the telemetry data.

At this stage, you’re looking for general indicators of system stress or inefficiency.

Step 3: Collect Detailed Information from Users

If telemetry doesn’t reveal the problem, gather more specific details from the user experiencing the issue.

Key questions to ask:

• What were you doing when the performance issue occurred?
• Are other users facing the same issue?
• Is it related to a specific form or process?
• Is the problem consistent or does it happen randomly?
• Can you record a short video to demonstrate the issue?
• Can you provide a copy/paste of session information (Activity ID, Session ID, AOS name)?
  

This information will allow you to zero in on the problem and cross-check it with LCS environment monitoring.

Step 4: Reproduce the Issue

Once you’ve gathered preliminary information and checked system telemetry, it’s essential to try to reproduce the issue yourself. This is a critical step, as it lets you confirm the problem and analyze it in a controlled environment.

Why Reproducing the Issue is Important:

• Validation: Verifying that the issue can be recreated helps make sure that it’s not an isolated user-specific problem, but rather something systematic that can be investigated further.
• Visibility: Being able to see the performance issue firsthand will give your insight into how the system behaves under the problematic conditions, enabling a deeper analysis.
• Communication: If you plan to escalate the issue to developers or support, showing that the issue can be replicated provides a solid starting point for others to troubleshoot.

Steps to Reproduce the Issue:

1. Ask Access to the User’s System or Environment: If you don’t already have access, ask permission to log into the affected user’s environment. Make sure you are using the same permissions and roles as the user to avoid discrepancies.
2. Follow the User’s Steps: Once logged in, replicate the exact actions the user took when the issue occurred. This include:
   • Navigating through specific forms.
   • Running reports or transactions.
   • Performing specific searches or filtering data.
3. Use Telemetry for Assistance: If the user provided session information (e.g., Activity ID, Session ID, AOS name), use that to find the timeframe of the issue and see if any telemetry logs or queries can help in reproducing it.
4. Consider Different Scenarios: Sometimes, performance issues only occur under certain conditions. Test a variety of scenarios to see if the problem persists:
   • Load Variation: Does the issue only occur when multiple users are logged in and performing heavy tasks at the same time?
   • Data-Specific Issues: Does the issue happen when working with certain records or larger datasets?
   • Time-Sensitive Issues: Are there specific times of day when the issue occurs (e.g., during peak hours)?
5. Simulate a Clean Environment: If you’re can’t reproduce the issue directly, try testing the same functionality in a non-production (e.g., test or sandbox) environment to see if it still occurs. Differences in performance between production and non-production environments can often point to configuration or data issues.

What to Do If You Can’t Reproduce the Issue:

• Ask for More Details: If you still can’t replicate the problem, circle back with the user and ask for more context or detailed steps. They may have missed providing key details that could help pinpoint the problem.
• Collaborate with Other Users: Ask other users if they are experiencing the same issue. If the problem is user-specific, it could be related to personalization, permissions, network connections, or local device configurations.

Document Your Findings:

Whether you successfully reproduce the issue or not, it’s essential to document your findings. This documentation will be useful if you escalate the issue to another team, like:

• A support ticket with Microsoft.
• An internal report to the development or IT teams.
• Communication with the affected user to manage expectations.

By attempting to reproduce the issue yourself, you not only confirm the problem but also narrow down potential causes, making it easier to do with troubleshooting or escalate the issue with confidence.

Step 5: Do a simple F12 Network analysis

Using Chrome or Edge’s developer tools (F12), do a network analysis:

1. Track Load Times: Analyze how long various UI elements take to load.
2. Find Cryptic Delays: Look for traces that are taking an unusually long time.

You can save the network data (like the header, payload, and response times) for deeper analysis or support cases with Microsoft.

You can then record/save the header, payload and response times.  It will give hints and deeper insights.

If you can “pinpoint” the exact menu item when the performance issue occur, also save a HAR-file, as this may be needed later if you need to create support case with Microsoft.

Step 6: Perform a small Performance timer in D365 F&O

After attempting to reproduce the issue and gathering more information, the next step is to utilize the Performance Timer in D365 F&O. This will help you pinpoint where performance bottlenecks may be occurring in the user interface.

What is the Performance Timer?

The Performance Timer tool lets you monitor the duration of specific actions within the system. This is a valuable tool for isolating whether performance issues are related to particular tasks, forms, or processes.

Steps to Run the Performance Timer:

1. Enable the Performance Timer: In D365 F&O, simply append &debug=develop to the URL you’re using. This will activate developer mode, which includes the Performance Timer. There should be an icon you can click on to see the timers.
2. Run the Process: Now that the Performance Timer is enabled, carry out the process that is causing performance issues (e.g., navigating through forms, running reports, or completing a transaction).
3. Analyze the Results: The Performance Timer will display detailed information about the time each step takes. Focus on processes that show unusually high times, as these may indicate where the issue lies.
4. Save the Data: Save the timer output, which may include SQL query timings, network delays, and any computational lags. This data will be valuable if the issue needs to be escalated to developers or support teams.

Why Use the Performance Timer?

By using the Performance Timer, you can gain a clear understanding of the system’s behavior and identify specific steps or components that are underperforming. This allows you to target your troubleshooting efforts and avoid a “needle in a haystack” approach.

Step 7: Trace Parsing for Deeper Analysis

Once you have exhausted surface-level checks, it’s time to delve deeper using trace parsing. This step will give you a granular view of what is happening behind the scenes, such as which SQL queries or X++ code is contributing to performance degradation.

What is Trace Parsing?

Trace parsing involves generating and analyzing detailed logs of system activity, focusing on SQL execution times, compute times, and overall process flows. This is typically a task for experienced developers familiar with X++ and SQL.

Steps for Effective Trace Parsing:

1. Activate Tracing: Enable tracing within the specific environment where the performance issue occurs. Be mindful to limit the tracing to just a few seconds around the time when the issue happens, as traces can quickly become very large and difficult to manage.
   
2. Analyze the Trace File: Once tracing is complete, you’ll receive a detailed log of system events, including:
   • SQL Execution Times: Pinpoint how long individual SQL calls are taking.
   • Compute Times: Understand how much CPU time is being consumed during specific processes.
   • Call Stack: See the entire process flow, showing which methods and queries are running.

Example: A healthy SQL query might take less than 25 milliseconds, but a problematic query could take several seconds, indicating where optimization is needed.

3. Identify Bottlenecks: Look at the Top 5 X++ Calls and Queries—these can often be related to the main contributors to performance issues. Look for patterns such as repeated heavy queries or inefficient code paths that might be slowing the system down.

What to Do if the Trace is Inconclusive:

If no obvious bottleneck is detected, you may be dealing with an aggregated performance issue caused by the cumulative effect of many small, efficient processes. This type of issue can be particularly challenging to resolve, as it requires rethinking broader architectural elements.

For example, if performance issues arise from standard code, extensions or customizations, it could take weeks or even months to resolve fully, especially if multiple layers of custom code are involved.

Step 8: Fixing the Issue

Once you have identified the root cause of the performance issue through telemetry, reproduction, and trace parsing, the next step is to involve the appropriate resources to fix it.

1. Determine Responsibility:
   • If the issue stems from Microsoft code, open a support case with Microsoft.
   • If the problem lies within an ISV solution, contact the ISV for support.
   • If custom partner extensions are responsible, reach out to the team that developed those extensions.
2. Check Version and Patches:
   Ensure that your environment is running the latest version of the software, as many performance issues are resolved in later patches or hotfixes. Check LCS Hotfixes and the Release Planner for any upcoming features or fixes that could address the issue.
3. Evaluate Parameters and Configurations:
   Performance can often be tied to configurations. Check the system’s parameters, as enabling too many features or processes can bog down performance. Disable unnecessary options to streamline the system’s operation.
4. Optimize Data Management:
   Check if transactional or outdated data (such as completed sales orders or old inventor/WMS transactions) is accumulating in the system. Regularly archiving old data and keeping the system clean can significantly improve performance. Also take a look at the F&O capacity is some data is “exloding”.
5. Community Support:
   Don’t hesitate to reach out to the broader Dynamics 365 community. Platforms such as Yammer, community forums, and even tools like CoPilot or ChatGPT often provide valuable insights and workarounds shared by other users who have encountered similar issues.
6. Hire a 10X developer to fix it?  Sorry, but they are myths.  Just like unicorns and Bigfoot.

Step 9: The blame game

Hopefully you have now a deep insight into root cause if the performance issue, and now there is a feeling someone must “pay” because of the pain inflicted on the end-users.  A customer may start with their implementation partner, ISV’s and Microsoft.  But I’m not sure how advisable this would be, as the fundamental issue is not the bug/code/data that caused the performance problems. No developer, partner or Microsoft can deliver flawless code that handles every combination of complexity.  I’m arguing that in the project there should be more investments of quality procedures and customer testing of their used combinations of system, people and data. The implementation guide chapter 14 gives a very good overview of how to run the testing strategy. My recommendation is to allocate +50% of the implementation effort to testing and training

• Unit testing and integration testing: 10-15%
• User acceptance testing (UAT): 5-10%
• Performance and security testing: 5% and 15% to training
• End-user training: 5-10%
• Administrator and power-user training: 3-5%
• Training materials development: 2-3%

Step 10: Reflections and adjusted expectations

As I hope this blogpost reflects, is that the path of performance issues is complex, and does involve a lot of knowledge from many parties.  But the good thing is that we do have access to a lot of tools, processes and telemetry to pinpoint root case.  It may take time, but the more exact and detailed we are, the faster an issue can be resolved.

Also keep in mind that ERP systems are complex. As Michael P posted in Linked in it is estimated that Dynamics 365 X++ codebase (Application Suite consists of 27,7 M code lines and 430K methods).  But if you take the entire codebase of all customers, we have crossed more than 1 billion lines of code.   That is a lot of complexity, and the result is that performance issues will be popping up now and then.

Last comments:

1. Sales Order processes and Price calculations are slow.  Get used to it!
2. Dual Write can be a pain. Do you really need it ?
3. Customizations are most likely the reason. Did you push the developers to be done by Monday?
4. Scaling of the PROD-environment is tightly related to licensing. Lots of heavy transactional integrations and automations combined with a small 20 users licenses is a recipe for performance issues.
5. Dynamics 365 is just making sure you enjoy some well-deserved coffee breaks. It’s not a bug, it’s a feature—designed to give you more time to reflect.
6. Dynamics 365 is also teaching you the virtues of mindfulness and patience. It’s not slow, it’s just showing its respect for all the data you’re processing.

If you have looked into your D365 F&O capacity, you sometimes see a lot of data being stored in the tables EventEntitySyncTables and BIIncrementalTableModifications.

I see in the code, that there are things in place to clean them up, but there be situations where this code for some reason is not executed.

The contents of the EventEntitySyncTables are basically just a table that stores CRUD changes for incremental power BI/datalake updates. It is basically just storing change type, table and recid reference

If you see that this table is exploding it would be worth to check and see if you have a batch job named Purge Incremental Changes History (Class BIIncrementalChangesHistoryPurgeJob) and if you don’t, you create it manually in the batch job screen. (I have not found a menu item for it)

It deletes records in EventEntitySyncTables that is more than 3 days old in chunks of 1.000.000 records. (See class BIIncrementalChangesHistoryPurgeJob)

About BIIncrementalTableModifications, I actually don’t see any clear code that cleans up this table. But there are some code in the class EventActionEntitySyncRefresh that cleans up. Maybe it is on the Microsoft backlog? But there are indications that a full refresh may clean things up, when you go to the entity store menu-item. (You have to do it for all)

What is very important is that Export to Data Lake is announced deprecated, and you should transition to Synapse Link. So checkout this documentation : https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/finance-data-azure-data-lake

The transition from LCS to Power Platform admin center is steaming ahead, and I would like to put a spotlight into the “known issues” that is available in PPAC.  If you go into the support menu in LCS, you are now directed to PPAC:

Then you now have a known issues tab, where you can filter, search and look for status on known issues.

This can help a lot, as running a support case can be time consuming. You can also click on the known issue to see if there are any workarounds:

The known issues cover the entire D365 stack, and it is a highly welcomed new feature to further strengthen the support to our customers.

Have you ever wondered about the versioning numbering in the Dynamics 365 Commerce? Here is a small explanation.

If you have a version like 9.49.24030.9, this means

9 – Main release number
.49 – This is the number that increments for each service release. Like 10.0.39, 10.0.40 etc.
.24 – This is the year of the release
030 – This is day number. 030 means 30 January
.1 – Just an incremental counter

So now you can understand the versioning of the CSU/Commerce 🙂

PS! This also means that a quality update on the previous release can be further than a service release, and then the systems will complain about “downgrading not allowed”, even when selecting a newer Service update.

The setting of the correct time zone for service accounts in Microsoft Dynamics 365 is crucial for accurate business logic execution, particularly when dealing with time-sensitive functionalities like order deadlines. Given your interest in Dynamics 365, eCommerce, and Supply Chain, this topic is indeed pertinent.

Hidden within the user accounts in Dynamics 365, you’ll find service accounts like RetailServiceAccount, which is vital for real-time calls between the Cloud Scale Unit (CSU) and Finance & Operations (F&O). To locate these accounts, navigate to the user section and apply the isMicrosoftAccount = true filter.

Then you get the following list:

Each service account has a default preferred time zone, sometimes set to GMT-8 for RetailServiceAccount. This becomes crucial when you’re building features that rely on date and time calculations. For example, order deadlines for same-day or next-day deliveries are often determined based on the time zone. Within the code, you may encounter instances where DateTimeUtil::getUserPreferredTimeZone() is used, as in the SalesCalcAvailableDlvDate class. This function fetches the time zone from the user executing the code, which for retail calls is typically RetailServiceAccount.

If the time zone isn’t set correctly for service accounts, time-sensitive calculations like order deadlines could be inaccurate. This method appears 430 times in the standard codebase, making its impact substantial. To modify these settings, you can simply add the preferred time zone column to the user account, click ‘Edit,’ and make the necessary adjustments. This is also applicable to other settings like language and number format.

It’s imperative to set the correct time zone for service accounts executing system jobs or batches in Dynamics 365. This ensures that your business logic related to date and time operates as intended. Given the relevance of this topic to your work in eCommerce, Supply Chain, and management consulting, it’s a detail that warrants careful attention.

And then to a question: What should we do if we operate in multiple time zones? Then I think there are more improvements to be made to ensure that time zone calculations are better handled, and is not originating from the preferred time zone on a service account.