Managing breaking changes
Breaking change
When you make changes in an app, you need to make sure they will not break existing scenarios. Please, check the below list of common breaking changes.
Base
Any changes might break scenarios.
Connection
Changing refresh
call for OAuth connection.
Module's Communication
Changing response.output
.
Changing response.type
.
Adding response.valid
for 2xx
response.
Changing response.trigger
.
Adding condition
.
Adding additional call (chaining request).
Changing 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 select parameter mappable
to false
.
Setting 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.
How to 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.
1. Adding [Deprecated]
string into the module's label
[Deprecated]
string into the module's labelThe 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.

2. Adding 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.






3. Do 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.

How to shut down a module
If you need to make sure that the module is not used anymore and the user acknowledges it at least from the error log, you can throw an error whenever the module is executed.

How to deprecate a connection
If you need to deprecate a connection create a new connection, that should be used as the functional alternative, and rename the now deprecated connection so it now 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