Seeking Feedback: Proposed Changes to Apps Framework Versioning Mechanism

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?

@anon29275264
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.

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

Thank you

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

Greg

@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?

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.

Thoughts?

@gregra
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 😀

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.

@anon29275264 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?

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.

@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 @anon29275264 mentioned, there are specific error handling methods to communicate with the user about such events, see here: Error handling

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