Operational limits for Business Central online
To ensure the availability and quality of Business Central services, there are limits on certain operations. This article describes the limits and, in some cases, the strategy behind them.
Tip
Telemetry is gathered on some of the operations that have a limit. The telemetry provides insight into operations for which limits were exceeded. For more information, see Monitoring and Analyzing Telemetry.
Client connection limits
| Setting | Description | Limit |
|---|---|---|
| Reconnect period | The time during which a client can reconnect to the service after being disconnected. | 10 minutes |
Data handling limits
| Setting | Description | Limit |
|---|---|---|
| Max file size | The maximum size of files that can be uploaded to or downloaded from the service. | 350 MB |
| Maximum stream read size | The maximum number of bytes that can be read from a stream (InStream object) in a single AL read operation. Examples include READ or InStream.READTEXT method calls. This setting pertains to UTF-8 and UTF-16 text encoding; not MS-DOS encoding. | 1,000,000 bytes |
| Upload timeout | The maximum time it can take for a file to upload to the service. When the limit is reached, the following message displays in the client: Upload did not complete within the 65 seconds limit. | 65 seconds |
Database limits
| Setting | Description | Value |
|---|---|---|
| Search timeout | The time (in seconds) that a search operation on lists in the client continues before it's stopped. When the limit is reached, the following message displays in the client: Searching for rows took long and was stopped. Try to search or filter using different criteria. | 10 seconds |
| SQL command timeout | The contextual time-out for a SQL command. | 30 minutes |
| SQL connection idle timeout | The time that a SQL connection can remain idle before being closed. | 5 minutes |
| SQL connection timeout | The time to wait for the service to connect to the database. When the time is exceeded, the attempt is canceled and an error occurs. This setting also applies to the beginning, rollback, and commit of transactions. | 1.5 minutes |
| Long-running SQL query threshold | The amount of time that an SQL query can run before a warning telemetry event occurs. If this threshold is exceeded, the following event is logged: Action completed successfully, but it took longer than the given threshold. | 750 ms |
Asynchronous task limits
| Setting | Description | Limit |
|---|---|---|
| Background sessions default waiting timeout | The maximum amount of time in hours for a background session to wait before being processed. | 8 |
| Background sessions max concurrency | The maximum number of background sessions per environment that can be processed at the same time in a server instance. Background sessions that come in when this limit is exceeded will wait in a queue until a time slot becomes available. | 10 |
| Background sessions max queue length | The maximum number of background sessions per environment that can be queued, waiting to be processed in a server instance. When this limit is exceeded, an error occurs. | 100 |
| Child sessions max concurrency | The maximum number of child sessions per parent session that can be processed at the same time. Child sessions that come in when this limit is exceeded will wait in a queue until a time slot becomes available. | 5 |
| Child sessions max queue length | The maximum number of child sessions per parent session that can be queued, waiting to be processed. When this limit is exceeded, an error occurs. | 100 |
| Scheduled tasks max concurrency | The maximum number of scheduled tasks that could simultaneously run in an environment was set to 3 in the past. To increase throughput, this per-environment limit has now been changed to a per-user limit | See the current per-user limit. |
| Maximum session recursion depth | The maximum number of nested sessions that can be created before being considered excessive recursion. When this limit is exceeded, an error occurs with the following message: Excessive recursive session creation detected, original session ID: [id], current session ID: [id]. | 14 |
| Page background task default timeout | The default amount of time in minutes for a page background task to run before being canceled. A timeout value can also be provided when page background tasks are enqueued at run-time. This limit is used if no timeout value is provided. | 2 |
| Page background task max timeout | The maximum amount of time in minutes for a page background task to run before being canceled. A timeout value can also be provided when page background tasks are enqueued at run-time. Timeout values greater than this limit will be ignored. | 10 |
Scheduled task limits (per user)
| Setting | Description | Limit |
|---|---|---|
| Scheduled tasks max concurrency | The maximum number of scheduled tasks that can be simultaneously run by a user. The more users you have in your environment, the more tasks you can simultaneously run in it, as long as we can continuously scale our resources. If many tasks are running at the same time and we couldn't sufficiently scale our resources, you might experience delays in running your tasks. | 5, see frequently asked questions on per-user limits. |
Report limits
| Setting | Description | Limit |
|---|---|---|
| Default max documents | The maximum number of documents that can be merged in a report using a Word layout. Users can override this setting on a report-basis from the report request page. If exceeded, the report will be canceled. Developers can override this setting by using MaximumDocumentCount property of a report. Client users can do the same when running a report from the report request page |
200 |
| Max documents | The maximum number of documents that can be merged in a report using a Word layout. If exceeded, the report will be canceled. | 500 |
| Default max execution timeout | The maximum execution time that it can take to generate a report by default. Users can override this setting on a report-basis from the report request page. If exceeded, the report will be canceled. Developers can override this setting by using the ExecutionTimeout property of a report. Client users can do the same via Report Limits and Settings page, or when running a report from the report request page as a one-time change. |
6 hours |
| Max execution timeout | The maximum execution time that it can take to generate a report. If exceeded, the report will be canceled. | 12 hours |
| Default max rows | The maximum number of rows that can be processed in a report by default. Users can override this setting on a report-basis from the report request page. If exceeded, the report will be canceled. Developers can override this setting by using the MaximumDataSetSize property of a report. Client users can do the same when running a report from the report request page. |
500,000 |
| Max rows | The maximum number of rows that can be processed in a report. If exceeded, the report will be canceled by the server. | 10,000,000 |
For more information on report limits, see Report limits.
Excel limits
Excel has limits on the total number of rows and columns on a worksheet. This means that Business Central features such as Open in Excel, Edit in Excel, Get report data in Excel without a layout, and Excel layouts can't exceed these limits. Learn more in Excel specifications and limits.
Query limits
| Setting | Description | Limit |
|---|---|---|
| Max execution timeout | The maximum execution time that it can take to generate a query. If exceeded, the query will be canceled. | 30 minutes |
| Max rows | The maximum number of rows that can be processed in a query. If exceeded, the query will be canceled. | 1,000,000 |
Company limit (per environment)
| Setting | Description | Limit |
|---|---|---|
| Max companies | The maximum number of companies that can be contained in one environment. | 300 |
Tip
This company limit will take effect in 2023 wave 1 release. When in effect, exceeding the limit will prevent you from doing some environment operations. Learn more about the consequences of exceeding the limit, in Operational challenges with many companies per environment.
If you already have more than 300 companies in one environment, distribute them across more environments to avoid problems later.
OData request limits (per environment)
| Setting | Description | Limit |
|---|---|---|
| Max body size | The maximum request body size in MB. | 350 |
| Max concurrent requests | The maximum number of OData V4 requests that can be processed at the same time. Requests that come in when this limit is exceeded will wait in a queue until a time slot becomes available. They wait in the queue until they time out after 8 minutes, where an HTTP response code 503 - Service Temporarily Unavailable is returned. To increase throughput, this per-environment limit has been changed to a per-user limit. |
5, see the current per-user limit. |
| Max connections | The maximum number of simultaneous OData V4 requests, including processed and queued requests. When this limit is exceeded, an HTTP response code 429 - Too Many Requests is returned. To increase throughput, this per-environment limit has been changed to a per-user limit. |
100, see the current per-user limit. |
| Max page size | The maximum number of entities that can be returned for an OData V4 request. When this limit is exceeded, an HTTP response code 413 - Request Entity Too Large is returned. |
20,000 |
| Max batch size | The maximum number of operations in an OData V4 $batch request. | 100 |
| Max request queue size | The maximum number of queued OData V4 requests, waiting to be processed. When this limit is exceeded, an HTTP response code 429 - Too Many Requests is returned. To increase throughput, this per-environment limit has been changed to a per-user limit. |
95, see the current per-user limit. |
| Speed (rate) | The maximum number of OData V4 requests that can be submitted in a minute. When this limit is exceeded, an HTTP response code 429 - Too Many Requests is returned. To increase throughput, this per-environment limit has been changed to a per-user limit. |
Sandbox: 300, Production: 600, see the current per-user limit. |
| Operation timeout | The maximum amount of time in minutes allocated to an OData V4 request. When this limit is exceeded, an HTTP response code 408 - Request Timeout is returned and the relevant session is canceled. |
8 |
| Max number of webhook subscriptions | The maximum number of webhook subscriptions. | 200 |
SOAP request limits (per environment)
| Setting | Description | Limit |
|---|---|---|
| Max concurrent requests | The maximum number of SOAP requests that can be processed at the same time. Requests that come in when this limit is exceeded will wait in a queue until a time slot becomes available. They wait in the queue until they time out after 8 minutes, where an HTTP response code 503 - Service Temporarily Unavailable is returned. |
5 |
| Max connections | The maximum number of simultaneous SOAP requests, including processed and queued requests. When the limit is exceeded, an HTTP response code 429 - Too Many Requests is returned. |
100 |
| Max message size | The maximum size in KB of a SOAP request. When this limit is exceeded, an HTTP response code 413 - Request Entity Too Large is returned. |
65,536 |
| Max request queue size | The maximum number of queued SOAP requests, waiting to be processed. When this limit is exceeded, an HTTP response code 429 - Too Many Requests is returned. |
95 |
| Speed (rate) | The maximum number of SOAP requests that can be submitted in a minute. When this limit is exceeded, an HTTP response code 429 - Too Many Requests is returned. To increase throughput, this per-environment limit has been changed to a per-user limit. |
Sandbox: 300, Production: 600, see the current per-user limit. |
| Operation timeout | The maximum amount of time in minutes allocated to a SOAP request. When this limit is exceeded, an HTTP response code 408 - Request Timeout is returned. |
8 |
Note
These following per-user limits will be rolled out gradually starting in late December 2023.
OData request limits (per user)
| Setting | Description | Limit |
|---|---|---|
| Max concurrent requests | The maximum number of OData V4 requests that can be processed at the same time. Requests that come in when this limit is exceeded will wait in a queue until a time slot becomes available. They wait in the queue until they time out after 8 minutes, where an HTTP response code 503 - Service Temporarily Unavailable is returned. The more users you have in your environment, the more requests you can simultaneously process in it, as long as we can continuously scale our resources. If many requests are being processed at the same time and we couldn't sufficiently scale our resources, you might experience delays/throttling in processing your requests. |
5, see frequently asked questions on per-user limits. |
| Max connections | The maximum number of simultaneous OData V4 requests, including processed and queued requests. When this limit is exceeded, an HTTP response code 429 - Too Many Requests is returned. |
100, see frequently asked questions on per-user limits. |
| Max request queue size | The maximum number of queued OData V4 requests, waiting to be processed. When this limit is exceeded, an HTTP response code 429 - Too Many Requests is returned. |
95, see frequently asked questions on per-user limits. |
| Speed (rate) | The maximum number of OData V4 requests that can be submitted within a 5-minute sliding window. When this limit is exceeded, an HTTP response code 429 - Too Many Requests is returned. The more users you have in your environment, the more requests you can submit to it around the same time, as long as we can continuously scale our resources. If many requests are being submitted around the same time and we couldn't sufficiently scale our resources, you might experience throttling in submitting your requests. |
6000, see frequently asked questions on per-user limits. |
SOAP request limits (per user)
| Setting | Description | Limit |
|---|---|---|
| Speed (rate) | The maximum number of SOAP requests that can be submitted within a 5-minute sliding window. When this limit is exceeded, an HTTP response code 429 - Too Many Requests is returned. The more users you have in your environment, the more requests you can submit to the environment around the same time, as long as we can continuously scale our resources. If many requests are being submitted around the same time and we can't sufficiently scale our resources, you might experience throttling in submitting your requests. |
6000, see frequently asked questions on per-user limits. |
Tip
Throttling could occur when many requests are submitted and handled (processed/queued) around the same time and they're taking a long time to complete. To optimize throughput, use API or OData instead of SOAP, as they execute faster. We'll also reduce the throughput for SOAP and deprecate it in the future. Learn more in Deprecated features in the platform - Clients, Server, and Database.
Frequently asked questions on per-user limits
This section includes frequently asked questions on per-user limits. If you have questions that aren't answered, please submit them using the This page option in the Feedback section below.
How do these limits apply to how many tasks, requests, or other resource consumption units a user is entitled to each day?
These operational limits control "how fast" you can consume resources simultaneously or in short periods (per second/minute) and are not related to entitlement quotas that control "how much" you can consume resources in longer periods (per day/week/month). At present, we haven't set definite entitlement quotas, but will do so in the future.
Are limits applied differently for application users (service principals)?
No. These operational limits are applied to all types of users in the same way.
Do more users mean more throughput per environment?
Yes, you can increase throughput by distributing or spreading your workload across multiple users. The more users you have in your environment, the more resources you can consume in it at or around the same time, as long as we can continuously scale our resources. If a lot of resources are consumed at or around the same time and we couldn't sufficiently scale our resources, you might experience delays or throttling in consuming your resources.
Why are my OData or SOAP requests throttled when the current per-user speed (rate) limits are much higher than the previous per-environment speed (rate) limits?
Your OData or SOAP requests will be throttled if they exceed the current per-user speed (rate) limits that are strictly enforced. They might not have been throttled in the past even if they had exceeded the previous per-environment speed (rate) limits, because those limits weren't strictly enforced. They served as recommendations or warnings for you to implement a retry logic with cool-off period that should already be in place. For more information, see Working with API Rate Limits.
If your integration is using a single user or service principal to perform a large number of operations, or if it's an interactive client application that uses a single user or service principal to send all OData or SOAP requests to Business Central online, the per-user operational limits can be reached fairly quickly. You can help prevent this situation and maintain or increase your throughput by distributing or spreading your workload in smaller batches across multiple users or service principals. A standard technique is to distribute your requests in a round-robin fashion or rotation through a list of users or service principals.