Manage breaking changes
When you make changes in an app, make sure your changes will not break existing scenarios.
Ideally, the removal of the connections, modules, and fields should be announced to the users in advance.
Contact the helpdesk with a request for e-mail notification to users.
Common breaking changes
Base
Any changes might break scenarios.
Connection
Changing the refresh
call for OAuth connection.
Module's Communication
Changing response.output
.
Changing response.type
.
Adding response.valid
for 2xx
response.
Changing response.trigger
.
Adding a condition
.
Adding an additional call (chaining request).
Changing a linked connection.
Module's Parameters
Changing required
from false
to true
.
Removing a parameter.
Changing type
(if the original type can be coerced to the new type, it’s fine. e.g. number -> text. See type coercions.
Adding validate
.
Setting the select parameter mappable
to false
.
Setting the select parameter dynamic
to false
.
Webhook's Communication
Any changes might break scenarios.
RPC
Changing parameter required
from false
to true
.
Changing RPCs building dynamic parameters.
Custom Functions
Any changes might break scenarios.
Remove a parameter from a module
It's important to avoid removing mappable parameters from a module without a clear indication or notification to the user. Even if it doesn't immediately cause a scenario to fail, it could still impact its functionality or disrupt the underlying process. Therefore, it's best to communicate any changes to the user. Also, the user should be able to see and work with the original input in the deprecated parameter/s.
In situations where a mappable parameter needs to be removed, there are several ways to handle the deprecation. The appropriate approach depends on the specific circumstances and how the API manages parameter deprecation in its endpoint.
Below, are methods ranked in order of least to greatest impact:
Add the [Deprecated] string to the module's label
The parameter should be put into advanced parameters and the [Deprecated]
string should be attached to the label. Additionally, you can add instructions to the help.

Add a banner
If you need to make sure that the user notices the deprecated parameters, you can use the banner element.
There are three distinct message types available, each with a specific icon and guidelines for appropriate use. The recommended length of the message is 50 to 300 characters.






Perform an additional check before the request is sent and throw an error if the deprecated parameter is present in the payload
If the called API service is too strict about using the deprecated parameters, you can do the error execution on the app's side.

Shut down a module
If you need to make sure that the module is not used anymore, you can throw an error whenever the module is executed.

Deprecate a connection
If you need to deprecate a connection, create a new connection to use as the functional alternative and rename the now-deprecated connection so it contains the (deprecated)
string.
Then, do the following:
Remove the current primary connection.
Map the new connection as the primary connection.
Map the deprecated connection as the alternative connection.
Last updated