Cloudflare has changed the signature of createBatch() for Workflows so that it accepts an options object rather than the array form developers previously passed. According to the changelog entry, the call can now create up to 100 Workflow instances in one request, and the returned result lists which instances were created and explains why any of the others were not.
The change is documented as a single API surface update rather than a new product. The same method name is retained, so existing code that calls createBatch() with an array continues to run; the changelog states that the array form is deprecated but that code using it keeps working. That means the update is additive for new code and non-breaking for deployed code, at least as far as the source describes.
Two input shapes are supported. The first is a count: passing count together with shared params asks the platform to create that many instances, and each one receives a generated ID. The changelog's example shows a count of 10 with a params object containing a report value, which illustrates the pattern of one shared configuration applied across a set of instances.
The second shape is an explicit list. Passing instances lets the caller give each entry its own ID or its own options, which matters when the instances are not interchangeable. The documented example supplies two entries with distinct IDs and distinct params, one keyed to an order identifier of 1 and another to an order identifier of 2.
The return value is structured around outcomes rather than a simple success flag. The changelog describes a created collection holding the instances that were made, and an errors collection holding each entry that was not created. Errors are identified by the entry's position in the input, and the example iterates over errors logging the index, id, code and message for each one.
The error semantics are the most consequential part of the change for anyone who has written batch code before. The changelog states that IDs which already exist, and IDs repeated within the same batch, are reported as errors rather than being skipped silently. In other words, a caller that submits a batch containing a duplicate does not get a quiet partial success; the duplicate surfaces in the errors list.
That behaviour shifts responsibility onto the calling code. A batch that mixes valid and invalid entries will still produce created instances, so the caller has to inspect errors to know the full picture. The changelog does not describe any all-or-nothing transaction guarantee, and it does not say that a failed entry rolls back the entries that succeeded.
There is also a tooling requirement attached to the new form. The changelog says that to use this form in local development and to get its types from Wrangler types, developers need Wrangler 4.148.0 or later. That version floor applies to the local development and type-generation path described, not to every possible use of the API.
The changelog does not state a general availability date for the API change itself, nor does it describe pricing, quota or billing implications for creating up to 100 instances in one call. It also does not say whether the 100-instance ceiling is configurable or whether it differs between the count form and the instances form.
For freelancers and small teams building on Workers, the practical effect is mostly about how batch creation is expressed and how failures are handled. A count-based call is a compact way to fan out a set of identical jobs, while the instances form is the option when each job needs its own identity or parameters. The errors array is the part worth wiring into logging early, because silent skips are exactly the kind of failure that is hard to notice in production.
The deprecation of the array form is a forward-looking signal rather than an immediate break. Because the changelog explicitly says existing array-based code continues to work, there is no forced migration deadline in the supplied material. Teams that want the new error reporting and the count form will need to move to the options object, and teams that want typed local development will need the stated Wrangler version.
What remains unknown from the source is how the platform orders or schedules the instances created in a single batch, whether the 100 limit is enforced per call only, and what error codes can appear in the errors entries beyond the two duplicate cases named. The changelog points readers to the createBatch reference for more information but does not reproduce that reference content here.
The safest reading is that this is a focused API ergonomics and error-visibility change. It gives callers a documented way to create many instances at once, a documented way to give each instance its own identity, and a documented place to look when some entries do not make it. Everything beyond that, including operational limits and failure modes, is not established by the supplied text.