Seeking Feedback: Proposed Changes to Apps Framework Versioning Mechanism

Hello Monday Developers!

I hope this message finds you well. I’m reaching out to the community to share some proposed changes to our app framework versioning mechanism and seek your feedback.

We are exploring the possibility of removing major versions in our app framework to streamline the app promotion process. This change is designed to automatically promote an app to its latest live version in all accounts using it, among other improvements.

Proposed Changes

  1. No need to decide/choose if you’re promoting to major VS minor version, you will be simply creating a new version (behind the scenes it will create a “minor” version)

  2. Admins no longer are required to upgrade / install / update a new version of your application

  3. Automatic enrolling to the latest live version across all accounts where the app is installed, even if scope permissions are added
    3.1. The users get the latest views and recipes
    3.2. Users that will use a view or a recipe will get a banner/disclaimer that this app requires additional permissions to fully operate
    3.3. In this case the admin will need to review and approve the new permissions so that your tokens have full permissions to operate with the new scopes
    3.4. In the store (view store and integration store) we’ll mention next to the feature card whether it requires review of additional permissions in case admin hasn’t approved them yet. Users will still be able to add them to their boards / items / etc

  4. We will support removing and deprecating features for all draft versions
    4.1. Removing a feature is always permitted in a new draft version
    4.2. For view instances → we will disable the view so that it’s not accessible by the user
    4.3. For active automations that use your integration feature, we will display a message that says that “this recipe is no longer supported by the developer”
    4.4. In case of deprecation we will show a default “deprecation” message to be displayed on the view and on the automation and allow you to override this custom message
    4.5. Deprecated features will not be shown in the stores
    4.6 It’s up to you when you remove a deprecated feature (that you can no longer support)

  5. We’ll provide through the SDK and the public API a way to know what are the approved scopes and the new required scopes

Why Your Feedback Matters
We believe that these changes will enhance the developer experience and make app promotion more seamless. However, your input is crucial to ensure that we address any concerns or potential challenges that may arise during implementation.

How You Can Help
Please share your thoughts, concerns, or suggestions regarding these proposed changes. Are there specific use-cases, scenarios, or considerations we might have overlooked? Your feedback will play a vital role in shaping the final implementation.

We plan to collect feedback until the end of November. After that, we’ll review all responses and incorporate the valuable input from the community into the final design.

Thank you in advance for taking the time to contribute to this discussion. Your insights are instrumental in making our framework better
Best regards,

Greg, Apps Framework


In regard to 4, will there be an ability to deprecate individual recipes and action/trigger blocks?

There are instances where one action needs to be reworked in a breaking way (so a new block, deprecate the original, and any preformed recipes), and it would be a shame to force every recipe in the feature to be replaced by users with those from a new supported feature that is entirely the same except one action/recipe they don’t even use.

Lastly, will there be a method for admins/owners to be notified if a recipe they created has been deprecated?


Hey Cody,
Thanks for the feedback.

For the current phase it’s a bit stretchy to implement such a behavior, but we will consider it for automations roadmap.
About admin / owner notifications - are you referring to board owners or to account admins?

1 Like

see above

One thing that would be helpful at least is detailed documentation on what can change in a recipe without breaking existing recipes and custom automations. I know in pre-made recipes you can change certain things you can’t change when using an action block in a custom recipe (such as adding new fields that map to trigger outputs, the field won’t get populated without re-adding the action, but in a pre-made recipe since thats mapped at the recipe level, changes will work as long as the recipe is the same ID).

At least then we have clarity on when we can just change things vs when we have to create a new recipe/action and communicate to customers a need to replace usages.

1 Like