You’re offline. This is a read only version of the page.
Hello, I am looking at this license guide and, have few question on 'Per App Plan'
It says "Best for businesses that want to license each user to run one app at a time, with the flexibility to stack licenses for each additional app."
Question 1:
Let's assume we buy 300 'Per App Plan' licenses and, we have total 3000 employees. At any point in time only 300 users can access this app or, in other words only 300 concurrent users are supported to use this app?
If yes, then if 301th user wants to use the app then one of the user from initial 300 pool has to close the session?
Question 2: Do we need to buy this license for each app we build? so we can set concurrent users limit = number of 'Per App Plan' license?
Thanks, let me verify in the environment releasing process.
AS far as I know the license is not released back to the pool when you unshare the app from the user. If and when it does go back to the pool it will be at least 90 days after assignment before it can be used again. For the scenario you describe Pay as you go is the only real solution. But I suspect to do it well you'll need two environments and two copies of the app. One paygo and one regular per app.
Hi @Pstork1 , Thanks for sharing your experience. Agree, License check will happen during app launch.
Though, I am unclear about when that license released to pool again? if we unshare the app with user or remove the security role, can that license will be released to pool? it is just admin over head, should go for pay-go subscription model.
Seeking your guidance what licensing scheme will be apt for following requirement(pay-go option is not feasible). here are the two persona's:
Which licenses should we go for? Thanks in advance.
I don't have a source for that statement. Its just empirical logic on how the process works. If you assign licenses when the app is shared you need to do a lot of extra work, like enumerate all the users it is shared with, check their licenses, and assign licenses to those who don't have one. At runtime you are already checking whether they have a license so its much easier to assign one to a single user if needed. This pattern requires a lot less code and still insures that every user who needs one has a license.
This is a common pattern for Microsoft. For example, User's are not added to the UserInformation table in a SharePoint site collection when they are given permission to a site. They are added when the user logs into the site for the first time.
@Pstork1 wrote:<snip> The reason it works the way it does now is because of the processing overhead it would require checking every user to see if they needed a license whenever an app was shared. It's much more efficient to check whether a single user needs a license when they access the app. That overhead is why it works the way it does today. <snip>
I understand and agree with you on the documentation part. My question about sources was in regards to this statement.
If that's true, it would be great, and the documentation truly needs to be updated. Do you have sources at Microsoft who can back up this information?
I doubt that will happen. The reason it works the way it does now is because of the processing overhead it would require checking every user to see if they needed a license whenever an app was shared. It's much more efficient to check whether a single user needs a license when they access the app. That overhead is why it works the way it does today. I don't see that changing.
Understood, and appreciate the feedback. Just be ready for when they change it, and an app you have shared with 500 people but only 20 people use suddenly eats up all of your app passes.
Yes, that is what Microsoft says, its just not the reality of how it actually works. Part of the reason for that is that they currently have no way to report who is consuming what license for each app.
#1
Michael E. Gernaey
15
Super User 2025 Season 1
#2
stampcoin
9
#3
bscarlavai33
5
Super User 2025 Season 1
Share
Report
All responses (
Answers (
