Operational limits for Business Central online

Article
06/10/2024

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

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.	1,000,000

For more information on report limits, see Report 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. For information about the consequences of exceeding the limit, go to 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.

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.

Share via