With the shift to only minor versions, we no longer have a clean way to manage revisions of recipes (changes to which can be far more problematic than UI features updating since the developer doesn’t control the behavior of the framework around their display and storage of configuration.)
A few parts to this request laid out below that I thing would help give end users the best experience around deprecations.
- Add the ability to mark integration recipes, actions, triggers, custom fields as “deprecated” (with a date or immediately) in the dev center. Once deprecated the objects will no longer be available for new usage, but can still be edited by the end user in existing usages since the old template sill exists and is still accessible for display (with deprecated messaging).
- The developer can release NEW recipes, actions, and triggers to replace the deprecated version. These may have changes in fields, or endpoints.
- Deprecated objects will display with “being deprecated DD/MM/YYYY” until the deprecation date arrives - at which point they may remain visible but not able to be added (allow developer the choice of behavior - maybe controlled by custom messaging capabilities suggesting alternative solutions or recipes)
- Provide a facility within the dev center to hide deprecated objects so that the clutter doesn’t get in the way of active development.
- Permit us to unhide deprecated objects and make minor edits - particularly to the URLs so we can avoid disrupting our customers usage and migrate them to a new backend (monday code for example).
I realize the new Workflows features are full features and can deprecated individually (I believe) but the Workflow engine is far from being able to fully replace the existing automations & integrations frameworks for every use case and in all accounts regardless of their tier.