Connectivity Development Release Notes for November 2026
Custom property keys
Fix
Resolved an issue where custom property keys named type or subType returned empty values. Previously, if a tracked group property, tracked property, or dynamic document property used a key named type, subType, dataType, or sourceType, it overwrote the runtime's internal identity field. All properties in that group then returned empty, and the process could fail with a 500 error when it tried to load the connector info.
The runtime now stores these internal identity fields with an _id suffix instead of _s, so your custom keys no longer collide with them. This change is on by default. (CON-11449) (CON-11155) (CON-11156)
This fix is in the runtime release.
Operation-only connectors no longer require a connection
New Features
Connectors that run only operations, with no connection, can now have a connectionless experience in the Platform UI. The feature is available in the SDK, but cannot be adopted directly without contacting Boomi and turning on an internal flag.
With the flag on, an operation-only connector:
-
Shows a connectionless label in the connection area instead of a connection chooser.
-
Hides the Allow dynamic connection properties option.
-
Cannot have a connection component created for it.
-
Appears in the connector search palette and can be dragged onto the build canvas.
-
Shows no connection chooser in the Browse pop-up.
Connection-based connectors are not affected. (CON-11458)
- Packaging a process now fails if it includes a generic connector step (other than operation-only) that has no connection configured. The error identifies the step and connector. Before you package, add a connection to each affected step. Operation-only steps are not affected. (CON-11460)
This feature is not in the runtime release.
- There are runtime changes that allow connectionless operation-only connectors to deploy, register, and execute without throwing NPEs and listeners should not throw "missing server key" errors. (CON-11459)
This feature is in the runtime release.
Runtime workers
Fix
Resolved an issue where Runtime workers no longer shut down when a listener has a bad connection.
Previously, a listener with an invalid connection configuration, such as an unreachable Kafka broker or an invalid Disk directory, could stop a Runtime worker from starting. The listener kept retrying its connection during startup, so the worker could not communicate with the Controller. The Controller then shut the worker down. If this happened to every worker in an environment, no listeners stayed active.
Workers now start and register with the Controller even when a listener fails to initialize. A listener that takes longer to start than the worker's startup timeout no longer causes the worker to shut down. This applies to both execution and listen workers. (CON-10460)
This fix is in the runtime release.