Release R25-10 #
Available from 14th October 2025
Highlights #
Cyclr API – improved reference interface
The Cyclr API reference has been updated to use a new interface, allowing for clearer documentation of its endpoints. This only affects the reference; the actual Cyclr API and its endpoints have not been modified.
Private Cyclr Instances – view Cyclr Application Release
Partners with Private Cyclr Instances can now go to their Private Instance Administrator area to view the Release of the Cyclr Application they have installed.
Improvements #
Account User Interface – installing Templates using Connectivity Tools
Templates containing Connectivity Tools Steps can now be installed into Accounts using Cyclr’s end-user interface, as used by Account Users.
Connectors > Installation User Experience – Authentication Description can now be modified
While most text Cyclr displays when installing a Connector could already be customized, the Authentication Description shown wasn’t so that’s now modifiable.
Console > Templates – Cycle upgrading could attach to different Connectors
Resolved a situation where upgrading a Cycle to a new Template Release could result in a new Cycle Version that attached to different instances of Connectors. This was only possible if:
- the Account had more than one instance of the correct Connectors installed within it.
- and the new Template Release had been exported and imported across Consoles as a way to copy it.
Custom Connectors – resolved missing options for nested Custom Object Method Categories
When working with a Custom Connector’s Method, some options would not appear if that Method was from a Method Category with the “Category Customization Enabled” setting, and that was also nested within another Method Category.
Cycle Execution – before_action Script and rate limiting evaluation
Previously before_action Script functions would be executed prior to Rate Limiting being evaluated. That has now been reversed so that Rate Limiting is first evaluated, and only at the point the call will be made will any before_action Script be executed. This ensures code executed occurs immediately before a call is made, rather than when there could be a potential delay afterwards.
