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

1 Like

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.


Cody, great point there. We will make sure to document the exact behaviors

Thank you

1 Like

Hi everyone!
Following up on this thread, we are going to release the new versioning mechanism during the next days. A community announcement will follow with all the release details


1 Like

@gregra - how will the additional permissions mechanism works for app that doesn’t have a view?
We’re now working on an update for report that will also generate a report via doc and therefore need additional scopes for docs.
The user has the automation configed, they got the new version, and now it’s suppose to run and create a doc but fails on permissions. Where/how do we request the user for the updated scopes?

1 Like

Hey @Fantasy-Media-Team, that’s a good question. We have a proposal to do it in one of two ways (maybe both), and I’ll be more than happy to hear your thoughts:

  1. Extend the existing app_installs api to support an optional account_id as another param, and return a permissions object that gets you the allowed scopes and the new scopes (so that you can compare and decide what to do in runtime)
  2. Return you a structured error for this specific case where you get the missing scopes

From that point on, you can return an appropriate error to the users that encourages them to update the app.


1 Like

Both suggestions basically give us an option to know that there’s a gap in scopes (either through api / structured error) which is great.
My question is, once we have this information, what method do we have to show it to the users other than failing their automations and hoping they’ll see and understand the error in the automation itself?
In the existing mechanism (major version) we can at least let them know that they can’t use functionality A,B,C unless they upgrade and evreything will work. With the new mechanism, they’ll get a bunch of new functionality, use it and start failing without understand what’s going on. Seems to me like a very bad experience.
I really don’t know what the solution is but I think there’s need to be a more structured solution + I doubt we’re the only ones that have apps without a view/UI.

I’m with you here. Automation/Integration apps have always been, in my opinion, treated like an afterthought. Even the app approval process barely works for them by trying to impose impossible requirements on them that only apply to UI apps - so much so that I’ve contemplated adding a “useless box” UI feature so we can get the reviewer to check the box on it.

@Fantasy-Media-Team This is what I can suggest to you:

  1. Have a logic in your code that gives the users that did not update yet some partial experience in case it’s possible. If not, fail the automation with a proper message so that the users can see it in the activity log - Error handling
  2. Also, send a notification through graphql that encourages to update the app (Notifications). BTW, I know that this one requires the additional notifications:write scope, and I see the irony here :smile:

Also, we’re adding some CTAs on the automation itself (on the custom recipe) so that users can see that their automation is missing scopes.

@codyfrisch I know it’s not always a smooth sale with us, but we are working hard to improve the apps framework, and we’re doubling down on workflow app features in 2024, stay tuned

@gregra thanks for hearing us out and being collaborative on this.
Basically it leaves us with the option to fail the automation and hope the user will understand what’s going on.
We’re working hard to give our customers the best possible product and service and I must say I feel this isn’t helping us.
Would it be possible for you to give us additional tools/mechanisms to handle this other than failing and alerting?

1 Like

Greg, I think for the integrations side I have an easy solution!

Include the scopes authorized in the JWT! Then we know the scopes beforehand and can respond accordingly from the get go - including the use of the error handling process that can send a notification and runtime error WITHOUT the need for notifications:write.

If there was a special code in the error handling we could use that to cause the integration/automation activity log to show a link to the place to accept new scopes, that would be icing. Like a specific 6001 severity that automates the whole process.

1 Like

@Fantasy-Media-Team We’re gradually improving the apps framework and looking into adding additional CTAs to help the user and the admin to update to the latest version of your app. In the meantime, as @codyfrisch mentioned, there are specific error handling methods to communicate with the user about such events, see here: Error handling

1 Like

@codyfrisch good idea! I’ll make sure it’s added to our product backlog