Confusion around app installation & auth scopes

We are building a board app that displays data from our platform (ActivTrak) to users in their accounts. There is not necessarily a 1:1 match between users of both platforms, so for MVP we’ve chosen some account-level insights that are safe to share with all users, whether or not they’re personally generating data in ActivTrak.

Here’s what’s not clear to us:

  1. Are board apps installed at the account level (say, by an admin) and appear for all users in that account or do they have to be installed individually by each user?
  2. Can board apps be authenticated by a single user for that entire account or does each user need to have a corresponding user account in both systems to use it?
  3. Can we rely on the Storage API (in beta) to store secure data, like tokens?

We’ve been on seminars, read the docs, and still don’t have a clear understanding of these integration patterns. Thanks in advance!

Hi @ogold,

Welcome to the community!

Let me try and help you out on these questions:
1 - Apps run at an account level. Only the user who set up the app (integration) is able to edit the configuration. Any user is able to see a view
2 - Yes, an app can be authenticated by a single user. However any time this is interacted with, it will be on behalf of the user who authorised it. I.e., if I set up the integration, it will use my access token and my user_id when sending data to the action.
3 - I am not 100% sure, I would say no going by the information in the docs on storage. If you are using a view, you could use a sessionToken and send this to your server to collect your access_token as the sessionToken includes the account_id and user_id

If you would like to share some information around how your app will work, I might be able to give you some ideas?

1 Like

Really good explained by @mitchell.hudson ,

I have one addition.

  • You can add collaborators to your app.
    Those collaborators can also edit the configurations.
1 Like

Thank you for the responses, @mitchell.hudson and @TMNXT-Dev!

Our app is straightforward: our platform, ActivTrak, captures employee activity and processes it into productivity insights. Our webapp displays these insights in various charts and reports:

Our goal is to display several of these charts in the integration (i.e. on a board app). So a user sees these (ActivTrak) insights about their team’s productivity side-by-side with their progress/boards. Since our V1 will include only team-level insights, it only needs to be authenticated by a single user and all account users will see the same views.

@mitchell.hudson, can you help me confirm/clarify…
1 - The app is installed and configured at the account level and automatically appears on every users’ board within that account. As @TMNXT-Dev pointed out, other collaborators can be added to configure the app.
2 - The app can be authenticated by a single user and all users, when viewing the integration, will see the data based on that single user’s credentials. How do you we implement the app with single user credentials vs every user authenticating on their own (as in the documentation examples)?
3 - The reason we were asking about storing tokens was because we thought the OAuth applied only to user-level authentication and we were exploring ways to implement account-level auth (and persist tokens) on our own. Hopefully this will be unnecessary. :crossed_fingers:



Great, thanks for sharing! Here are a few tips that I would recommend, I am sure that @TMNXT-Dev will be able to provide some other tips as well.

  • You can use the sessionToken in the view by using monday.get('sessionToken') This gives you an access token that you can use in the board view to make monday API calls, or send back to your server. The sessionToken is encoded using your App CLIENT SECRET key, and contains the user_id and account_id of the logged in user. You can use these keys to get other information about the user/account and then return the data required based on the user that is viewing your app

  • A collaborator is used when you are developing your app. A collaborator can change config settings. I was referring to an integration/automation setup which doesn’t look like applies to you now so you can ignore that

  • Once an app has been installed, any user can see the view (your app). If you are billing, you will need to bill based on the account_id, not the user_id (unless you bill per user using the app)

In direct response to your points:
1 - This relates to the sessionToken point above. Once it is installed and the view added to the board, any user can view the app
2 - you can use the sessionToken for this. If you want to go through the whole oAuth process, you can do this but will need to do it in a new window as CORS will block your request in the iFrame
3 - I don’t think you will need this

Let me know if you have any other questions

Hey @ogold, just thought I’d jump in here and share a bit of insight from our team on this as well to add on to the amazing insight from @mitchell.hudson and @TMNXT-Dev :slight_smile:

I’ve just checked with the team and they have confirmed that you should avoid using Storage API to store tokens at this point. Just to make sure we are on the same page here, are you looking to create a "one-time only” connection between ActiveTrac and


@mitchell.hudson @AlexSavchuk Maybe you can help me guys.
In the publish section of our app - iv’e added multiple accounts and shared with them the installation link. When trying to install the app they get an error:
{“error”:“invalid_grant”,“error_description”:“Account is not allowed to install this app”}

or this massage:
“The app cannot be installed in this account”.

Anyone know’s why?


@AlexSavchuk thank you for verifying this question about the Storage API (and saving us time and headaches)! :pray:

What we’re trying to do - and maybe this is not supported in V1 - is to authenticate our integration against a single high-access user (e.g. an admin) and aggregate metrics with all users in that account/workspace. This will allow us to get a V1/MVP out quicker and avoid the complexity of user-level authentication (which requires user mapping between both platforms).

The purpose of storing tokens is to persist the credentials of that 1 admin/user securely for all users to access, so they don’t need to authenticate with their own credentials. This is a high-level diagram of what we’re trying to achieve: