Quick Answer (TL;DR)
A 404 error in the Business Central web client almost always means the page ID, bookmark, or URL you opened no longer points to a valid page. Common reasons include unpublished extensions, missing permissions, wrong environment, or leftover links from an older NAV setup. Most cases resolve in minutes once you isolate which of these it is.
Key Takeaways
- A Business Central 404 error means the client cannot locate the page tied to the URL, not that the whole system is down.
- The most frequent causes are broken bookmarks, unpublished or removed extensions, missing permission sets, and mismatched environments (sandbox vs. production).
- Old NAV shortcuts and browser favorites are a common source of 404s after an upgrade or migration.
- Custom pages and third-party extensions can trigger 404s if they were modified, uninstalled, or not republished after an update.
- Most fixes take under 15 minutes: verify the page ID, clear cache, confirm environment, and check user permissions.
- Recurring 404 errors across a team usually point to a deeper implementation or customization issue that needs expert review.
Understanding the Business Central Web Client 404 Error
When you see a 404 in the Business Central web client, the browser is telling you it reached Microsoft's servers successfully but could not find the specific page you requested. This is different from a connection error or a 500 server error. The environment itself is working; the individual page ID or route in the URL simply does not exist, is not published, or is not accessible to your user.
This distinction matters because it changes how you troubleshoot. You are not debugging the whole tenant, you are hunting down one broken link, one disabled extension, or one missing permission. If your team runs into this often or the errors keep multiplying after every update, it is worth having your setup reviewed by a team that provides ongoing rather than chasing each error one at a time.
Common Causes of the 404 Error in Business Central
Incorrect or Outdated Page URL
Business Central URLs are built around page IDs and record identifiers. If a bookmark was saved months ago and the page was later renumbered, renamed, or removed by an extension update, the old link will return a 404 even though a working version of that page exists elsewhere in the system.
Page Not Published or Extension Disabled
Every custom page lives inside an extension. If that extension was unpublished, is pending an update, or failed to install correctly, any page it contains becomes unreachable. This is one of the most common causes reported after a routine update cycle.
Missing User Permissions or Security Group
Business Central does not always show a clear "access denied" message. In some cases, a user without the right permission set trying to open a restricted page will simply see a 404 instead of a permissions warning. Checking the user's assigned permission sets is a quick way to rule this out.
Environment or Tenant Mismatch
If a link was shared from a sandbox environment but opened in production, or vice versa, the page or record ID referenced may not exist in the environment currently loaded. This is especially common in organizations running multiple environments for testing and live operations.
Leftover Pages From a Legacy NAV Migration
Companies that moved from an on-premises NAV setup often carry over old shortcuts, saved views, or integration links that reference page structures from the legacy system. These do not always map cleanly to Business Central's page architecture. If your 404 errors started right after a migration, it is worth reviewing how the transition was handled; our breakdown of the covers where these mismatches typically come from.
Conflicts From Custom Extensions
Heavily customized environments are more prone to 404 errors because custom pages depend on the extension staying installed, updated, and correctly versioned. A poorly maintained customization layer, or one built without proper documentation, is a frequent root cause. If your team is dealing with recurring page errors tied to custom development, it may be time to have your audited rather than patched repeatedly.
Step-by-Step Troubleshooting Guide
- Confirm the page ID and URL syntax. Check whether the URL includes a valid page number and that no characters were altered or truncated when it was shared or bookmarked.
- Clear browser cache and cookies. Cached versions of old pages can sometimes trigger a stale 404 even after the underlying issue is fixed.
- Verify the environment. Make sure you are opening the link in the correct tenant and environment, sandbox or production, since page IDs are not always shared between the two.
- Review user permission sets. Confirm the user has the correct security role assigned and that the permission set includes access to the object in question.
- Test in an incognito window or different browser. This rules out browser extensions or session data as the cause.
- Check the Extension Management page. Look for any extension showing an error, pending status, or one that was recently uninstalled.
- Check the telemetry or event log. Admins can review Business Central's built-in telemetry to see if the page request failed at the server level, which usually points to a deployment or extension issue rather than a user error.
When the 404 Points to a Deeper Implementation Issue
A single 404 error is usually a quick fix. A pattern of them, especially across multiple users or right after go-live, is often a symptom of a rushed or misconfigured implementation. Systems that were deployed with default settings and minimal customization planning tend to develop these gaps over time as teams try to bend the standard setup to fit their actual workflows. Our article on explains why this happens and what typically needs to change.
If the errors are already widespread and affecting daily operations, patching individual pages will only buy time. In cases like this, teams usually need a structured review of the environment rather than one-off fixes; we have documented how this looks in practice in our writeup on .
How to Prevent Future 404 Errors
Preventing recurring 404 errors comes down to good environment hygiene. Keep a documented list of custom pages and the extensions they belong to, avoid sharing hardcoded page links across environments, and test extension updates in a sandbox before pushing them to production. Assigning a clear owner for permission sets also prevents the silent access issues that show up disguised as 404s. Teams that plan customization changes carefully, rather than adding them ad hoc, see far fewer of these errors after each update cycle.
FAQs
Does a 404 error mean Business Central is down? No. A 404 means the specific page you requested cannot be found, while the rest of the environment is typically running normally.
Can a 404 error be a permissions issue instead of a broken link? Yes. Business Central sometimes returns a 404 instead of an access-denied message when a user lacks permission to a page, so checking permission sets is a necessary troubleshooting step.
Why did 404 errors start right after we migrated from NAV? Legacy shortcuts, saved views, and integrations built around old NAV page structures do not always translate directly to Business Central, which can produce 404s on links that used to work.
Should I worry if only one user sees the error? If it is isolated to one user, it is most often a permissions or cached-session issue. If multiple users see it on the same page, check the extension tied to that page first.
When should I bring in outside help for this? If 404 errors are frequent, tied to custom development, or appearing across your team after updates, it is a sign the underlying setup needs review rather than repeated manual fixes.
Final Thoughts
A 404 error in the Business Central web client is rarely a mystery once you know where to look. Start with the URL and environment, move to permissions, and check the extension layer last. If the errors keep coming back, treat that as a signal about the health of your implementation rather than a one-off glitch. Teams that get stuck at this stage are usually better served by a conversation with a partner who can look at the full setup; you can if you want a second opinion on what is causing the errors in your environment.