Reference: Studio and Core Connector Limits

When you reach or exceed any integration or web service request limits set forth below, Workday may, in its sole discretion, (a) throttle your use of the integration or web service; or, (b) suspend your access to the integration or web service until usage is brought within the limit. In the event Workday makes available products or services which allow you to purchase additional capacity for a particular integration or web service, you can elect to purchase those products or services subject to any applicable terms and conditions.

Integration Runtime Capacity and Queueing

Concept	Description
Pool Share	Integration jobs run on shared runtime pools. Each tenant is allocated a share of the pool's total capacity. This limits the number of integration jobs a tenant can run concurrently, ensuring that no single tenant prevents others from running their integrations. When a tenant reaches the limit of its share, additional jobs are queued until that tenant's running jobs complete and capacity is freed. Lack of capacity can cause jobs to be delayed, but it doesn't cause them to fail. A queued job has the status 'Processing' in Workday. There is no associated error or failure. The job runs as soon as a runtime becomes available for that tenant. If you submit a large batch of integration jobs simultaneously, the system processes them at your fair share of pool capacity. This is expected behavior. Workday offers no guarantees regarding job completion time and makes these recommendations: Don't build integrations or external applications that depend on another integration completing at a specific time. Instead, chain integrations as steps in a business process so that the second integration launches only after the first completes successfully. Contact Workday Support only when an integration consistently takes an abnormally long time to complete.
Developer and System-Level Limits	Workday enforces 2 categories of integration limits: Developer runtime limits on memory, duration, disk allocation, and File-Backed Managed Data apply at the job level. When a job exceeds these limits, it's terminated. You can design integrations to stay within them. System-level limits on pool share capacity and queueing behavior are platform controls that depend on total demand across all tenants. When these limits are reached, jobs queue rather than fail. These constraints aren't configurable by developers and can't be designed around.

Concept

Description

Pool Share

Integration jobs run on shared runtime pools. Each tenant is allocated a share of the pool's total capacity. This limits the number of integration jobs a tenant can run concurrently, ensuring that no single tenant prevents others from running their integrations.

When a tenant reaches the limit of its share, additional jobs are queued until that tenant's running jobs complete and capacity is freed. Lack of capacity can cause jobs to be delayed, but it doesn't cause them to fail.

A queued job has the status 'Processing' in Workday. There is no associated error or failure. The job runs as soon as a runtime becomes available for that tenant.

If you submit a large batch of integration jobs simultaneously, the system processes them at your fair share of pool capacity. This is expected behavior.

Workday offers no guarantees regarding job completion time and makes these recommendations:

Don't build integrations or external applications that depend on another integration completing at a specific time. Instead, chain integrations as steps in a business process so that the second integration launches only after the first completes successfully.

Contact Workday Support only when an integration consistently takes an abnormally long time to complete.

Developer and System-Level Limits

Workday enforces 2 categories of integration limits:

Developer runtime limits on memory, duration, disk allocation, and File-Backed Managed Data apply at the job level. When a job exceeds these limits, it's terminated. You can design integrations to stay within them.

System-level limits on pool share capacity and queueing behavior are platform controls that depend on total demand across all tenants. When these limits are reached, jobs queue rather than fail. These constraints aren't configurable by developers and can't be designed around.

Studio Integration Limits

Category	Limit
Runtime Duration	4 hours
Memory	17 GB
JVM Heap	12 GB
File-Backed Managed Data	21 GB
Disc Allocation	13 GB
Single Document Stored on a Run	5 GiB (compressed)
Report/Log File Retention	60 days
Report/Log File Size	50 million characters (approximately 48 MB)
PUT Integration Message Subassembly	500 messages for each integration event. Included in the 500 message limit: Standard log messages (severity and summary/detail) sent using the PutIntegrationMessage subassembly. Entries surfaced in the Integration Messages or Process Monitor reports. PIMs carrying only document references, message targets, or status changes are excluded from the 500 message limit.

Connector Limits

These limits apply to Workday-built Connectors. Because Connectors run on a separate runtime pool from custom Studio integrations, they have different limits.

Category	Limit
Runtime Duration	30 hours. Any pause in processing doesn't count toward the limit.
Memory	30 GB. Document transformations can consume several times the amount of memory that the source data requires.
Concurrent Integrations	Concurrent integration capacity varies by environment and is shared fairly across active tenants.

When to Use Workday Studio