How to add a scope to an installed app

We have an app installed by various users, and as we’ve developed it has become necessary to add a scope (account:read to be specific).
In our testing, doing so uninstalls the app for everyone, presumably because it’s a new permission they haven’t accepted yet:

What’s the smoothest, least disruptive way we can add this needed scope to our app without angering all of our users?

Hey @anderslyman - let me check in with the team on this. I’ll let you know as soon as I know more.


1 Like

hi @dsilva
I have the same issue because I need to extend the scope with me:read to overcome the issue using a stored (invallidated) token after a full delete / re-install cycle of my apps.

Hey @anderslyman / @basdebruin - thank you for waiting :slight_smile:

I checked in with the team - at this time if the application has already been submitted / is live on the marketplace, please shoot us an email if you need to update your OAuth permissions.

@anderslyman in terms of the window you are seeing in that screenshot - right now when the permissions are changed it does require the users to reinstall the application. Essentially what happens in our testing is that the users will need to hit the re-install button from the apps page, however their data should not be deleted. We do this essentially because we need the admins on the account to reaccept the new permissions.

@basdebruin in regards to the issue you were facing specifically - I followed up earlier on the email thread we have as we look into that issue.

1 Like

Thanks @dsilva
We’ll see what that flow looks like, and find a way to give our users a heads up.
We don’t actually know who most of them are, any way to tell or would you just recommend firing off a message window inside the app to let them know?

Hey @anderslyman - users should be notified of this when they try to access the application again.


1 Like

Hi @dsilva, @anderslyman

Let me try to explain where I have an issues with extending the scope of already installed apps.

My app converts two dates into a timeline. In the new version I want to support times added to the dates as well. When working with dates I obviously need to take the TZ into account and therefore need access to the me:read scope.

When I update the backend code (to read the TZ from the users profile) the existing users get an error during the API call because the token is not valid for the extended (me:read) scope. I managed to change the authorization flow so that when the owner of the board updates (or unsubscribe/subscribe) the recipe that scope is checked. If the scope of the (updated) app does not match the scope I have stored in my DB the token will be removed from my DB and the OAuth handshake will be initiated for the new scope.

However I can’t seem to find a good method to intercept the event when a user (maybe even a different user from the one who subscribed the app to the board) triggers the event leading to the invalid scope error.

Please advise the best possible solution for this.

Hey Bas!

I understand your frustration here. To be honest, this is an issue that is affecting only a handful of developers who have a public app in the marketplace and want to change a scope.

Potentially stupid question: why don’t you catch the invalid scope error and raise it to the user, for example through a notification? Or simply ignore the hour column when you’re converting the date to a timeline?

I’m trying to understand better the specifics here so we can come up with a solution.

By the way, in the future we want to add a versioning mechanism that will make it easier to test your integrations that are already live. I don’t have an exact ETA on this, but we’ve been discussing it internally and I’d like to say we’ll have something this quarter.

CC @Ben @Shay @amir

1 Like

Hi Dipro, hope all is safe and healthy at your side.

TL;DR :slight_smile:

It is not only a handful developers, it is affecting all my users (100+) too. There are no stupid questions :slight_smile: so I am glad to answer yours.

Ignoring the time. That was what I originally did. But then I had a call from Australia for the issue that they are using time (let’s say 8.00 AM their time) and the values in the monday database (UTC) returned YESTERDAY 11 PM (UTC). So, when ignoring the time during the conversion you can end up with yesterday. I have solved it but for that I need the TZ of the user, hence a me:read scope added to the app.

Catching the error and returning to the user is not really solving it because the actual user triggering the error is may not be the board owner who subscribed the recipe to the board.

This is not the only issue I have with the tokens. I have seen users that delete the app from their account and add it again. Because the token was stored in my DB I ended up with unauthorized requests. I have solved that one by doing a light query in the authorization flow and deleted the token from the database if that query fails. I now use the same mechanism to check the scope (I also store the scope with the token) and compare it with the required scope which is set in the app’s environment. For those people who are interested, here it is:

//Check if we already have a token for this account / user and if it has correct scope
    //If we have a token, do a test API call to check if it is valid
  const myToken = await mySqlAccess.readToken(accountId, userId, envVars.appCode);
  if (myToken) tokenValid = await mondayService.testToken(myToken);
  if (tokenValid) {
    const currentScope = await mySqlAccess.readScope(accountId, userId, envVars.appCode);
    if (currentScope) {
      const currentScopeArray = currentScope.split(",");
      const requiredScopeArray = envVars.requiredScope.split(",");
      scopeValid =
        currentScopeArray.length == requiredScopeArray.length &&
        currentScopeArray.every((v) => requiredScopeArray.indexOf(v) >= 0)
          ? true
          : false;
    } else {
      //No current scope, new account
      scopeValid = true;
  if (scopeValid) return res.redirect(backToUrl);
  await mySqlAccess.deleteToken(accountId, userId, envVars.appCode);
  console.log("TOKEN: new token requested for account: " + accountId + " / user: " + userId);

After this I start the OAuth handshake (invalid token).

So, I covered almost everything except that the user who triggers the automation and generating the scope error might be another user than the board owner. I was looking for a method to (re)start the OAth flow anywhere from code (after receiving an “invalid scope” erro, but that is where I got stuck.

hi @dipro

I was working on your cool tip for token checking and sending notifications, the issue here is that I need a token to send the notification so that is a dead end.

A little off topic but I am wondering if there are reasons why existing tokens gets invalidated. I do see message like these in my error log and it looks like that is because a token is not valid anymore. Can you elaborate on that?

App 1390700 output: Error: Should send 'token' as an option or call mondaySdk.setToken(TOKEN)
App 1390700 output:     at MondayServerSdk.api (/var/www/vhosts/

Hi all, @amir

Sorry to let you know the process for adding a scope to an existing app (in the marketplace) is not ready for a real production environment. I needed to upgrade my app and extended the OAuth scope. As I have paying customers who use the app in a production environment I planned this upgrade during the weekend (night).

When I wanted to extend the scope the system refers met o monday support, so I did. The first answer was “thank you for your feature request”, the second answer was “we need our CX specialist to have a look, can take 2 days”. Needless to say that we need to have a process to upgrade the scope in parallel with upgrading the app (code).

How will this be addressed?

Hi Bas,

Thanks for sharing your feedback! As @dipro and I are in touch with you directly in the past couple of days to find a quick solution together with our dev team, I hope we can soon solve this issue.

Indeed scope changes for published apps are currently handled by our team and cannot be changed directly by app developers.
Since security in a critical element in the app review process, material changes to published apps require a new review process. Changing a scope is regarded a material change and cannot be done automatically regardless of the actual scope requested.
We recommend in such cases to reach out to us early to make sure we can support app changes efficiently.

Even though your initial request was brought to our attention, the response you received when approaching our support could be clearer and more relevant - thanks again for the feedback.