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

App's Element or Block
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:

  1. 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.

  1. 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.

  1. 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:

1

Remove the current primary connection.

2

Map the new connection as the primary connection.

3

Map the deprecated connection as the alternative connection.

Last updated