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?

Web browsers like Chrome or Edge are designed with strict security boundaries. A website cannot arbitrarily save files to your computer's hard drive without your explicit consent.

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.

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.

Connecting Azure Blob Storage to Business Central

Setting Up External File Storage in Business Central - No Code Required (Part 2: Connecting Azure Blob Storage to Business Central)

With Business Central version 28, Microsoft introduced a powerful capability to store attachments and files in external storage systems using a fully out-of-the-box, no-code approach.

One of the key limitations of Business Central is that storing large volumes of files directly in the database increases size, impacts performance, and raises cost. External file storage solves this by offloading files to scalable cloud storage like Azure Blob Storage, while still keeping everything fully integrated and configuration-based no development required.

In the previous part, we created an Azure Storage Account, Blob Container, and configured a Shared Access Signature (SAS). In this part, we will connect that storage to Business Central and complete the setup using standard configuration only.

Prerequisites

Before starting, ensure:

• An Azure Storage Account is created
• A Blob Container is available
• The container is accessible using a Shared Access Signature (SAS)

Step 1: Open External File Accounts in Business Central

In Business Central:

• Search for External File Accounts
• Click on Add File Account

This opens the assisted setup wizard.

Click Next.

Step 2: Select Storage Type

• Choose Blob Storage
• Click Next

Step 3: Configure Storage Details

Fill in the required fields:

• Account Name: A logical name for identification
• Azure Storage Account Name: Your Azure storage account name
• Authorization Type: Select Shared Access Signature (SAS)
• Secret: Paste the SAS token from Azure
• Container Name: Enter your blob container name

Click Next.

Step 4: Confirmation

If all details are correct, you will see a congratulations message confirming the connection.

At this point, Business Central is now linked to your Azure Blob Container as an external file account.

Step 5: Assign File Scenario

Now we define where this storage will be used:

• Search for Assign File Scenarios
• Open the page
• Select the configured file account
• Click Assign Scenarios

Choose:

• Documents Attachments - External Storage

Confirm the selection.

Warning Note

When enabling external file storage, Business Central displays a warning that:

• Files will no longer stored in the database
• Azure now becomes responsible for file storage and backups
• Retention and governance must be managed externally

This is an expected behavior when moving to external storage.

Step 6: Enable Scenario

• After you continue, External Storage Setup page will open.
• Click Enabled
• Optionally select a Root Folder (or let the system create one automatically)

Now attachments will be stored in Azure Blob Storage instead of the Business Central database.

Step 7: Test the Setup

To verify:

• Open a document such as a Purchase Order
• Add an attachment
• Upload the file, in my case I uploaded Cronus.jpg

Then go to Azure Portal:

• Open your Blob Container
• You will see the uploaded file stored there

Cost Benefit Analysis

To understand the real-world advantage of this setup, consider the following scenario:

• 1 TB of file storage
• Around 5,000 file operations per day

Azure Blob Storage

• Storage cost: approx. $18.43/month
• Operations cost: approx. $0.04/month

Total: approx. $18 to $20 per month

Business Central Database Storage

Business Central database storage is significantly more expensive because it is tied to SQL capacity pricing.

• Approximate cost: $40 to $60 per GB per year
• For 1 TB:

    Approx. $4,000+ per month

Conclusion

With the setup completed across both parts, we now have a fully working no-code, out-of-the-box external file storage solution in Business Central using Azure Blob Storage.

This approach allows Business Central to store attachments outside the database, improving performance, reducing storage growth, and enabling better scalability without any custom development.

At the same time, Azure Blob Storage provides a highly cost-effective solution, even at large scale making it a practical and modern alternative to traditional database-based file storage.

Together, this setup forms a clean, scalable, and cost-efficient architecture for managing files in Business Central.

Creating Azure Storage Account and Blob Container

Setting Up External File Storage in Business Central - No Code Required (Part 1: Creating Azure Storage Account and Blob Container)

This blog is part of a series where we’ll explore how to use External File Accounts in Microsoft Dynamics 365 Business Central to store files outside the database using standard, out-of-the-box features and without writing any code.

One of the first requirements for this setup is to have an Azure Storage Account and a Blob Container ready. In this post, we’ll walk through how to create them step by step.

Prerequisites

Make sure you have an active Azure subscription before getting started.

Step 1: Sign in to Azure Portal

Log in to the Azure Portal and search for Storage accounts using the search bar.

Step 2: Create a Storage Account

Click on + Create to begin.

Under the Basics tab, provide the following details:

• Subscription: Select your Azure subscription
• Resource Group:  Choose an existing one or create a new one
• Storage Account Name: Enter a globally unique name
• Region:  Select the region closest to your users or services
• Performance:  Choose between Standard (common) or Premium
• Redundancy: Select based on your needs:
• LRS (Locally Redundant Storage): cost-effective (we use here)
• ZRS (Zone-Redundant Storage): higher availability
• GRS / RA-GRS / GZRS: for geo-redundancy and maximum durability

You can explore additional tabs like Networking, Data protection, and Encryption if you want more control over security and access. For now, you can proceed with default settings.

Click Review + Create, verify the details, and then click Create.

Step 3: Deployment Completion

Once the deployment is complete, you’ll see a confirmation message. Click Go to Resource to open your storage account.

Step 4: Create a Container

Inside the storage account:

• In the left pane, under Data storage, click Containers
• Click + Add Container
• Enter a meaningful Name
• Click Create

Step 5: Verify Container

Your new container will appear in the list and is now ready to store.

Step 6: Generate a Shared Access Signature (SAS) for the Container

To allow Business Central to access the blob container securely, you need to generate a Shared Access Signature (SAS).

Azure provides multiple access methods such as:

• Azure Active Directory (Entra ID)
• Role-Based Access Control (RBAC)
• Access Keys
• Shared Access Signatures (SAS)

In this setup, we will use a container-level SAS, which gives controlled and time-limited access to a specific container. There are other account level access available as well but this container level access option is more granular.

Generate SAS from the Container

• Open your Storage Account in the Azure Portal
• Go to Data storage then Containers
• Select your newly created container
• In the left pane, under Settings, click on Shared access tokens

Configure Access

Set the required options:

• Permissions: Select based on your needs commonly Read, Write, Delete
• Start and expiry date/time: Define how long the access should be valid
• Allowed protocols: Select HTTPS only as its recommended

Generate token and Save

Click on Generate SAS token and URL.

You will see:

• Blob SAS token
• Blob SAS URL

Store these values securely (for example, in a key vault or another secure location). These will be used later when connecting the container to Business Central.

Conclusion

You have successfully created an Azure Storage Account and a Blob Container an essential first step toward using external file storage with Business Central.

In the next part, we’ll look at how to connect this container to Business Central and start storing attachments outside the database using standard features no custom development required.

New functionality: Control Database Isolation level on individual reads on a record instance

 

Hi,

We are familiar with the Record.LockTable property that we use to explicitly lock the table against write transactions that can conflict.

By default, Business Central automatically determines the isolation levels used when querying database. AL developers can now explicitly control the database isolation level on individual reads on a record instance.

With Business Central v.22, a new ReadIsolation method has been introduced on the record data type. Its syntax is as:

Rec.ReadIsolation := IsolationLevel::<enum value>

IsolationLevel can have following values:

Default, ReadCommitted, ReadUncommitted, RepeatableRead and UpdLock

Example:

To understand the concept, we use two simple procedures. One procedure will get customer 10000 and modifies Name while other procedure gets the same customer 10000 and shows the Name. Add these functions to actions on any page, I added them on Customer card using Page Extension. We will call these functions concurrently and one after the other to cover different scenarios in different sessions. Sleep function is used to delay the commit.

Procedure 1:

procedure modifyOnly()

    var

        Customer: Record Customer;

    begin

        Customer.Get('10000');

        Customer.Name := 'Modified Name';

        Customer.Modify();

        Sleep(45000);

    end;

Procedure 2:

procedure Show()

    var

        Customer: Record Customer;

    begin

        Customer.ReadIsolation := IsolationLevel::RepeatableRead;

        Customer.Get('10000');

        Message(Customer.Name);

    end;

       

We will go through the Isolation Levels one by one.

Default: 

It follows the table isolation level for reads; same behavior as not setting Isolation Level.

Open Business Central and Run ModifyName that will put the system to Sleep for 45 seconds after Customer.Modify. So, record is modified but not yet committed.

Open another Business Central session in incognito window and Run ShowName procedure. You will see that ShowName procedure will show the modified name even though it is not yet committed to DB. It is an example of dirty read.

Result: If Default is used then system can read uncommitted data.

ReadCommitted: 

Allows to read only committed data.

Change IsolationLevel to ReadCommitted in code. Open Business Central and change the customer 10000 name back to Original Name. Run ModifyName procedure that will put the system to Sleep for 45 seconds after Customer.Modify. So, record is modified but not yet committed.

Open another Business Central session in incognito window and Run ShowName procedure. You will see that after a few seconds you will get error that We cannot save your changes…

Result: If ReadCommitted is used then Read operation can performed only on a fully committed record, if the record is in between a transaction error will be thrown as above.

ReadUncommitted: 

Allows the record to read data that has been modified by other transactions but not yet committed (also called dirty reads)

Its behaviour is same that we saw in Default. You can perform example in same way.

RepeatableRead: 

Reads only committed data (as we see in ReadCommitted) but it also locks the record until current transaction is completed, means no write transaction can be performed on that record.

To understand it a bit more make a little change to Procedure 2 and replace Message(Customer.Name) by Customer.Modify(); Change IsolationMethod to RepeatableRead.

Open Business Central and change customer name back to Original Name and refresh.

Run procedure#1 ModifyName that will modifies the name and sleep.

Open Business Central in another incognito window and run procedure 2. After a few seconds you will get the error that We cannot save your changes….

Result: RepeatableRead only reads committed data and put lock until transaction is completed.

UpdLock: 

Ensures that reads stay consistent for the life of the current transaction. Until transaction completes record cannot read uncommitted data and other transactions with same isolation level cannot read  data that was read by this record.

Same behaviour as RepeatableRead, but additionally it does not allow other transactions with same isolation level to read data that was read by it. So, it reads only committed data, lock the record for write transaction and block the record from reading for transactions with same isolation level.

For any feedback or if you find any mistakes/issues feel free to send email at raibilalhaider@yahoo.com

Setting up Item's price based on Unit of Measure in NAV

 Question:

What if we have an item that we sell in two different units of measure? What to set up so that system should automatically pick the Unit price related to the unit of measure given in sales line?

Pre-Requisite:

Required units should present in our Unit of Measure table.

Steps:

1. Go to Sales Price Worksheet and put these two items on two different lines along with Unit of Measure and Unit Price.

2. Select the action Implement Price Change

3. To verify this Create a Sales Order and then create two lines of same item but with different unit of measure.