Friday, May 8, 2026

Data Access Intent

Why Do Reports Slow Down Users in Business Central?

Many organizations using Microsoft Dynamics 365 Business Central face a common problem that when large reports or API calls run, normal users experience slower performance. One reason can be that the reporting and transactional operations use the same primary database resource.

To help solve this issue, Microsoft introduced DataAccessIntent. This property separates reporting workloads from transactional operations to keep the system running smoothly.

Understanding the Database Replica

Before using DataAccessIntent, it is important to understand the concept of a database replica.

A database replica is a synchronized copy of the main production database. It is mainly used for read-only activities i.e. reports, analytics, and API requests so that these operations do not overload the primary transactional database where users are working.

What is DataAccessIntent?

DataAccessIntent is a property in Business Central that tells the system whether database access should be:

  • ReadWrite: For transactional operations (Default).

  • ReadOnly: For reporting and analytical operations.

When set to ReadOnly, Business Central can route requests to a read-only database replica instead of the primary database.

Code: 



This property can be used in:

  • Reports

  • Queries

  • API pages




In SaaS, Microsoft automatically manages the database replicas and infrastructure so developers only need to apply the DataAccessIntent property. 

For on-premises environments, administrators must manually configure readable replicas in SQL Server, typically using SQL Server Availability Groups.

Benefits of DataAccessIntent

  • Using DataAccessIntent improves performance by running reporting operations separately from transactional workloads.
  • It reduces database locking by ensuring read-only operations minimize conflicts with transactional data.

Limitations to Consider

  • Using `ReadOnly` prevents the ability to insert, modify, or delete records.
  • Replica databases may experience a slight data delay and not reflect the latest transactions immediately. 

Conclusion

DataAccessIntent is an important performance optimization feature in Microsoft Dynamics 365 Business Central. It helps reduce load on the primary database by directing read-only workloads to replicas, improving responsiveness in environments with heavy reporting or integration activity.


Tuesday, May 5, 2026

Demystifying File System Access in Business Central SaaS:

It has been a while since Microsoft moved Business Central to the cloud (SaaS), but many people still think: "Okay but why can't I just save a file to a folder like I used to?"

If you remember the good old Dynamics NAV days, we were used to having full control over a server. We could create a folder, save a file there, and read it later. But in the cloud, that setup is gone. Let's break down why that changed and how to handle it like a pro.


The Big Difference: Machine vs. Service

In the old days, you were working on a specific machine. You owned the server, you knew where the hard drive was, and you could save files to local or shared drives without a second thought.

In Business Central SaaS, you aren't working on a machine. You are working with a service.

  • It is shared: Thousands of companies use the same cloud infrastructure.

  • It is managed: Microsoft handles all the back-end stuff.

  • It is temporary: The server where your code runs might restart or move to a different piece of hardware at any time.

Because the system is constantly shifting, you do not have a home folder on the server to store files.


Why Direct File System Access is Blocked in BC SaaS

Understanding why direct file system access is not allowed is key to understanding modern cloud development.

Security & Multi-Tenancy

  • Tenant isolation: One tenant cannot access another tenant's data.

  • No server access: You don't have access to the server's file system, because it is not your server.

  • Attack prevention: Direct file I/O could create opportunities for attackers to exploit server vulnerabilities or navigate through directories.

Technical Reasons

  • No predictable paths: The structure of the server drive is completely hidden and managed solely by Microsoft.

  • No persistence guarantee: Servers can scale up or restart at any time.

Why On-Prem Can Access Everything:

  • Your Infrastructure: The server runs in your own datacenter.

  • Single Tenant: It is your data, your server, and your rules.

  • Full Control: You manage all security and access policies.

  • Legacy Support: The file system capability remains for backward compatibility.



Important Clarification: Why Can't the Browser Save Files Automatically?

Whether you're using BC SaaS or On-Prem through the web client (which is now the standard for both), web browsers like Chrome or Edge enforce strict security restrictions. A website cannot arbitrarily save files to your computer's hard drive without your explicit consent.

This browser restriction applies to both SaaS and On-Prem web clients. Everything must be user-driven, you must actively click to upload or download files.

The key difference:

  • On-Prem: The server can save files to network shares for server-side processing because you control the network.

  • SaaS: The server cannot save to a persistent file system because you don't control the server infrastructure.

This is why On-Prem can still use file-based integrations, while SaaS must use Streams, Cloud Storage, or APIs instead.


How to Handle Files the SaaS Way

The trick is to stop thinking about storing files and start thinking about moving data.



1. Temporary Processing (In-Memory)

Instead of saving a file to a folder to process it, keep the data in the server's memory. You process the data as a "stream" of information. Think of it like pouring water through a pipe i.e. you don't need a bucket to hold it; you just need to ensure it flows from the source to the destination.

2. User Interactions

Use standard upload and download features. These trigger your browser's native file picker. You aren't "saving to a path"; you are initiating a hand-off between the cloud service and your local computer.

3. Long-Term Storage

If you need to keep a file, move it to a dedicated cloud storage service:

  • Azure Blob Storage: Designed to hold massive amounts of files securely.

  • SharePoint/OneDrive: Best for documents that users need to view, edit, or share using familiar Office tools.

  • Database Fields: For small images or tiny documents, store the file content directly in a field within your database tables.

4. Integrations

Stop using "File Drops" (where one system writes a file and another waits for it to appear).

  • The Modern Way (APIs): Use direct service-to-service communication. When one system needs to talk to another, it sends a request via an API and gets an immediate confirmation. It is faster, more secure, and doesn't rely on files sitting in a folder that might get locked or deleted.


The Fundamental Rule

  • BC SaaS: Code runs in Microsoft's cloud and cannot see your local infrastructure.

  • BC On-Prem: Code runs on your server and can see your entire network.

The browser is just the user interface in both cases. Where the server physically sits determines what it can access.


Why This Is Actually Better

  • No "It works on my machine" issues: Your code will work the same way in every environment.

  • Better security: Microsoft handles security at the infrastructure level.

  • Scalability: Cloud storage scales automatically.

  • Reliability: Cloud storage services have built-in redundancy and backup.

  • Modern integrations: APIs provide real-time, synchronous communication instead of waiting for file polling.

Bottom Line

The file system didn't disappear; it moved to the cloud. Once you transition to using data streams and API integrations, your solutions will be cleaner, more reliable, and significantly easier to maintain.



Friday, May 1, 2026

Mastering Job Queues: A Refresher on Configuration and Orchestration

If you are already working with Business Central you must be familiar with Job Queues in Business Central. They are the backbone of automation and run scheduled tasks in the background. But while many developers and consultants know how to create a basic Job Queue entry, there are critical configuration fields and advanced patterns that often go overlooked. 

This blog serves as a refresher on essential settings like Job Queue Category, Priority, and Parameter String, while discussing error handling techniques and orchestration strategies that can elevate your automation from simple scheduled tasks to intelligent, self-healing workflows.

1. Essential Job Queue Configurations

Before you build complex workflows, master these settings to keep your server stable and performant.

Job Queue Category

Think of the Job Queue Category as a dedicated load balancing lane.

When you have heavy, resource-intensive tasks i.e. high-volume General Ledger postings or complex inventory recalculations by grouping them into a single, defined category provides two major benefits:

  • Deadlocks prevention: You prevent multiple heavy processes from overwhelming the server at the same time, which significantly reduces the risk of database deadlocks and system timeouts.
  • Resource Management: Categorization allows you to effectively partition your workload. This ensures that high-impact background tasks do not starve the rest of your system of the essential resources needed to keep the user interface responsive.


Priority

The Priority field determines the execution order of jobs within a specific category. You can assign a value of Low, Medium, or High to reflect the urgency of the task.

When multiple jobs are ready to run simultaneously, the Job Queue Processor prioritizes those marked as High before processing Medium or Low tasks. This ensures that mission-critical operations, such as automated bank statement imports or essential system integrations, are executed ahead of non-urgent background processes, maintaining consistent performance for your most vital workflows.

Parameter String

The Parameter String allows you to pass data into your code without hardcoding values, making your extensions flexible and environment-aware.

Instead of embedding static values such as API URLs, folder paths, or specific file names directly into your AL source code, you store them in the Parameter String. This enables you to reuse the same code unit across different environments (e.g., Sandbox and Production) by simply updating the parameter value.



Maximum No. of Attempts to Run

This setting serves as your primary defense against transient failures. Because Business Central often interacts with external web services or APIs, momentary network instability can occasionally cause a task to fail.

By setting the Maximum No. of Attempts, you instruct the system to automatically retry a failed task a specified number of times. This acts as a self-healing mechanism, allowing the system to resolve minor, self-correcting issues without human intervention. The task will only be marked with a status of Error once all configured retry attempts have been exhausted.

2. Robust Error Handling

When code fails, you don't want the whole queue to stop. To manage background tasks effectively, you can implement one of error-handling strategies. Each offers a different level of control over the Job Queue's execution status:

The [TryFunction] Pattern

Perfect for risky tasks, such as calling an external web service where a failure is a possibility. By marking a procedure as a TryFunction the system catches any errors that occur within that logic and returns a boolean value instead of crashing the entire Job Queue entry.



The Wrapper Pattern (Codeunit.Run)

This can be used when you need to ensure that a database transaction doesn't corrupt your data or stop your background process, wrap your logic inside a Codeunit.Run call. If the code inside the inner code unit crashes, the database rolls back only that specific transaction, keeping the main Job Queue entry alive. This pattern effectively isolates failures, allowing you to log the error, skip the problematic record, and move on to the next item in your queue.


3. Orchestration: Building a Better Pipeline

Orchestration in Job Queues is about coordinating separate jobs so they behave like a connected workflow rather than isolated tasks. In Microsoft Dynamics 365 Business Central, this is typically achieved by controlling data readiness and processing conditions. Each step updates the state of the data it works on, and subsequent jobs are designed to process only what is ready. This ensures that one step completes fully before the next begins, creating a reliable and traceable flow without requiring direct links between jobs.

Orchestration Strategies

Linear Pipeline: Each job performs one stage of the lifecycle. By updating a status field in a central table, you create a chain reaction where the completion of one task acts as the "green light" for the next. Below is illustration:




Event-Driven: Instead of relying on a timer that polls every 5 minutes, use an event-driven approach. By triggering the next step programmatically the millisecond the previous one finishes, you eliminate "dead time" between tasks.

Batch or Parallel: When dealing with thousands of records, you can use a Dispatcher to break your data into smaller, manageable chunks. By scheduling multiple instances of the same worker code unit to run at the same time, you can process data in parallel, significantly increasing throughput.

By decoupling your integration processes into distinct, sequential stages such as Ingest, Validate, and Commit you transition from fragile, single-run integrations to a resilient, enterprise-grade architecture.

This approach ensures that external data is verified before updating your core business records, provides a clear audit trail for every transaction, and allows you to safely reprocess specific failures without the risk of data duplication. Ultimately, orchestration shifts your integration strategy from reactive troubleshooting to a controlled, predictable data lifecycle.

Practical Scenario:

This diagram illustrates a 4-stage sequential job queue pipeline designed for automated data integration in Business Central.

The process begins when a scheduled trigger activates Job 1 (Import), which fetches data from an external source with high priority and automatic retry capability. Once imported, the data flows sequentially through Job 2 (Validate) to verify business rules, then Job 3 (Transform) to apply formatting and calculations, and finally Job 4 (Post) to create the actual records in Business Central.

Jobs with external dependencies (Import and Post) are configured with 3 automatic retry attempts to handle temporary network issues, while validation and transformation jobs fail immediately to the error log when issues are detected. 

All failed jobs that exhaust their retry attempts trigger an administrator alert, ensuring no data loss goes unnoticed. The colored flow highlights the critical path in green through purple, with error handling branches in orange and red, demonstrating how the system isolates failures while maintaining overall pipeline integrity.

Conclusion:

In this blog, we covered the essential Job Queue configurations including Job Queue Category, Priority, Parameter String, and Maximum No. of Attempts to Run, which form the foundation of reliable background processing. We explored robust error handling strategies using TryFunction and Wrapper patterns to isolate failures and keep your automation resilient. 

Finally, we examined orchestration strategies i.e. Linear Pipeline, Event-Driven, and Batch/Parallel that coordinate separate jobs into cohesive workflows, transforming isolated tasks into intelligent, self-healing automation pipelines.


Data Access Intent