How to Troubleshoot Dynamics 365 Business Central

Before you touch any settings, you need to know exactly what failed. Business Central SaaS tenants have built-in telemetry you can query through Application Insights, and this is where real Dynamics 365 Business Central troubleshooting starts.

In the Business Central Admin Center (aka.ms/bcadmincenter), navigate to your environment, go to Telemetry, and copy your Application Insights connection string. If you haven't set one up yet, you need to do that first, go to Environment → Application Insights Key and paste in a key from an Azure Application Insights resource you control.

Once telemetry is flowing, open Azure Portal → Application Insights → Logs and run this KQL query to see the last 50 errors:

traces
| where timestamp > ago(1h)
| where severityLevel >= 3
| where customDimensions has "BusinessCentral"
| project timestamp, message, customDimensions
| order by timestamp desc
| take 50

For faster, no-code diagnostics, go to Business Central Admin Center → Environments → [Your Env] → Support → Collect Troubleshooting Information. This generates a ZIP file with session logs, extension list, and environment metadata, exactly what Microsoft Support needs if you escalate.

You should see a list of error messages with AL object references. Note the AL Object Type (Page, Codeunit, Table) and Object ID, this tells you whether the error is in the base application, a Microsoft extension, or a third-party customization you can actually fix.

Authentication errors are the most common Business Central connection error I see in enterprise environments. They almost always involve Microsoft Entra ID (formerly Azure Active Directory) and show up as error codes like AADSTS50020, AADSTS70011, AADSTS65001, or a flat "You are not authorized to access this page."

Here's the diagnostic path. First, have the affected user navigate to aka.ms/mysignins and check recent sign-in activity. If their last sign-in to Business Central shows "Failure" with an Entra ID error code, that's your starting point.

For AADSTS50020 (user account from an identity provider doesn't exist in the tenant): the user's UPN in Microsoft 365 doesn't match what Business Central expects. Go to BC Admin Center → Users and verify the user's email matches their M365 UPN exactly, including domain suffix.

For AADSTS65001 (user hasn't consented to the BC app): an admin must grant consent. Go to Azure Portal → Entra ID → Enterprise Applications → Dynamics 365 Business Central → Permissions → Grant admin consent for [TenantName].

For Business Central permission denied errors inside the app (after login succeeds): open BC → Settings (gear icon) → My Settings, check the Role, then go to Search → Permission Sets and verify the user has the correct permission set assigned. The minimum for finance work is typically D365 BUS FULL ACCESS. You can test exactly what's failing by running the Permission Diagnostic: search for "Permission Diagnostic" in the BC search bar and enter the user's name plus the specific table or object throwing the error.

-- Check effective permissions for a user (on-prem, run in SQL)
SELECT TOP 100 *
FROM [dbo].[Access Control]
WHERE [User ID] = 'DOMAIN\username'
ORDER BY [Role ID]

After correcting the permission set, sign the user out and back in, permission changes don't always take effect on an active session.

Posting errors are the ones that cause the most panic because they block actual business transactions. A Business Central posting error typically looks like: "The transaction cannot be completed because it will cause inconsistencies in the [TableName] table" or "You cannot post because [Field] is not filled in on [Record]."

The most important thing to understand: these errors are almost always data integrity problems, not software bugs. Business Central's posting routines are deliberately strict, they validate every field relationship before writing to the general ledger.

Here's my standard diagnostic flow for posting errors:

1. Read the full error message carefully. It usually names the exact field and record. If it says "Quantity (Base) must be positive in Item Ledger Entry," that's telling you an inventory adjustment has gone negative somewhere upstream.

2. Check the document's Dimensions. A huge percentage of posting errors I see come from missing or invalid dimension values. Open the document, click Related → Dimensions and look for any dimension that has a value code set to blank when the dimension setup requires a value. Go to Search → General Ledger Setup and review the mandatory dimension configuration.

3. Run the consistency check for inventory. Go to Search → Adjust Cost, Item Entries and run it for the affected items. If there's a cost discrepancy that's blocking posting, this often resolves it.

4. For "Out of balance" errors, navigate to Search → Check G/L Entries to identify which posting group or G/L account is missing its counterpart configuration.

If you're on-premises, you can also query the posting error directly from SQL:

SELECT TOP 20 *
FROM [dbo].[Posted Sales Invoice Header]
WHERE [No_] IN (
  SELECT [Document No_] FROM [dbo].[G_L Entry]
  WHERE [Source Code] = 'SALESPOST'
)
ORDER BY [Posting Date] DESC

If the same document keeps failing no matter what you fix, delete it and re-enter it. That sounds brutal, but sometimes a document gets into a partially-written state during a session timeout and it's faster to start clean than to chase corrupted field values.

If your Business Central slow performance or crashing problem started right after a Microsoft update or after someone published a new extension, you're almost certainly looking at an AL extension conflict. This is one of the more technically involved areas of Business Central troubleshooting.

Start by checking which extensions are installed: go to Search → Extension Management. Look at the Publisher column, anything not published by "Microsoft" is a third-party or custom extension. Note the version numbers.

To isolate whether an extension is the culprit, temporarily disable non-Microsoft extensions one at a time. Click the three-dot menu next to the extension and choose Uninstall (not Unpublish, uninstall just disables it for users, it doesn't remove the code). Test after each uninstall to see if the problem goes away.

For developers looking at the AL runtime errors directly, open the AL Language extension in VS Code, connect to your environment via launch.json, and use the built-in AL Profiler to capture a performance snapshot. The profiler output shows exactly which AL methods are taking the most time and which objects are throwing exceptions.

Check the extension's event subscriptions, a common source of Business Central performance problems is an event subscriber that fires on OnBeforePost or OnAfterInsert for a high-volume table and runs an expensive query inside. In VS Code:

// Search your extension's AL files for expensive event subscribers
// Look for patterns like this firing on high-volume tables:
[EventSubscriber(ObjectType::Codeunit, Codeunit::"Sales-Post",
  'OnBeforePostSalesDoc', '', false, false)]
procedure OnBeforePostSalesDocHandler(...)

If you can't uninstall the extension because it holds critical data, contact the extension publisher with the AL object type and ID from the error telemetry. They'll need to release a compatible version for the BC update wave you're on.

After resolving the extension issue, go to Extension Management → [Extension] → Configure to review any configuration tables the extension owns, sometimes the conflict is actually a missing required configuration value, not a code bug.

Business Central web client not loading, pages timing out, or jobs running for hours when they used to take minutes, these are all performance problems, and they have different root causes depending on whether you're SaaS or on-premises.

For SaaS tenants: navigate to BC Admin Center → Environments → [Env] → Operations. Look at the Scheduled Job Queue Entries log. If you see queue entries stuck in "In Process" status for more than an hour, a job has likely hung and is holding a table lock that's blocking everyone else. Select the stuck entry and choose Set Status to On Hold, then restart it.

To identify long-running queries from inside Business Central, go to Search → Database Locks. This page shows you every active table lock in real time, which session holds it, how long it's been held, and which table is affected. If you see the Item Ledger Entry or G/L Entry table locked for more than a few seconds, a batch job or posting routine is the culprit.

For on-premises Business Central: the performance diagnostics live in Windows Event Viewer and SQL Server. On the Business Central application server, open Event Viewer → Applications and Services Logs → Microsoft → DynamicsNAV → Common → Admin. Event IDs to watch:

Event ID 705 , SQL query exceeded threshold (default: 1000ms)
Event ID 706 , Lock timeout occurred
Event ID 1214, Client connection dropped
Event ID 705 , Reports running over time limit

On the SQL Server side, run this query to find the current blocking chain:

SELECT
  blocking_session_id,
  session_id,
  wait_type,
  wait_time / 1000 AS wait_seconds,
  SUBSTRING(st.text, (r.statement_start_offset/2)+1,
    ((CASE r.statement_end_offset
      WHEN -1 THEN DATALENGTH(st.text)
      ELSE r.statement_end_offset
    END - r.statement_start_offset)/2)+1) AS statement_text
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) st
WHERE blocking_session_id > 0

For on-premises NST (Business Central Server) tuning, edit CustomSettings.config on the application server. Key settings affecting performance:

<add key="SqlCommandTimeout" value="00:30:00" />
<add key="MaxConcurrentCalls" value="40" />
<add key="DefaultClientServicesPort" value="7046" />

After changing CustomSettings.config, restart the Business Central Server service. You should see response times improve immediately if a timeout setting was the bottleneck.