Hey folks! Ran into a real head-scratcher this week while setting up Prisma Access for our mobile/remote workforce. I think I made a classic beginner mistake around licensing, specifically with how **license pools** work for mobile users. Sharing here so others can avoid the same trap! 😅
We had 100 `Prisma Access Mobile Users` licenses. I assumed that if I created a `Mobile Users` group in the portal and assigned all 100 licenses to it, that would cover our team. The confusion started when I saw the `License Pool` dropdown during the mobile user configuration.
Here’s the kicker: **The license pool you select isn't about assigning licenses TO the group. It's about pulling licenses FROM a pool you've already configured.** So you need to create the license pool first, allocate your total count there, and *then* select that pool when setting up your mobile user groups.
For example, here’s the step I missed in the portal:
1. **Go to Panorama (or the cloud admin portal) → `Tenants` → `Licenses`**.
2. Create a new license pool (e.g., `Mobile-Pool-All`), assign your 100 Mobile User licenses to it.
3. **Then**, when you configure your mobile user group (`Config` → `Mobile Users`), you select that `Mobile-Pool-All` from the dropdown.
If you don't do step 2 first, the dropdown in step 3 is empty, and you can't proceed. I was trying to assign licenses directly in the mobile user group config, which doesn't work. The pool acts as a central reservoir.
Lesson learned: Think of license pools as "license buckets" that you draw from. It’s a two-step process: fill the bucket first, then dip into it. Hope this saves someone a few hours of confusion!
Has anyone else stumbled on this? Or have best practices for structuring multiple pools (like by department or region)? I’m curious how others are managing it.
Clean code, happy life
Ohhh I totally get this now. That "License Pool" dropdown had me confused too. I was thinking the same way, like I was assigning licenses *to* something, not pulling *from* something. Your step-by-step is super clear, thanks for that!
One quick question, if you don't mind. Does this mean one license pool can supply multiple different mobile user groups? Like, could I have a "Mobile-Pool-All" of 100 licenses, and then have both a "Sales-Mobile" group and "Engineering-Mobile" group pulling from that same pool? That would make sense for shared resources.
Exactly. That's a common point of confusion. The license pool is a separate, pre-provisioned resource bucket.
People often miss the sequence. You allocate licenses *before* you have any users configured. The pool needs to exist and have a count.
Fail to do that and the mobile user group configuration will show an empty dropdown, or a pool with zero available licenses, stopping deployment.
Five nines? Prove it.
Exactly right, that's how it works. One pool feeds many groups. That shared bucket model is the whole point, otherwise you'd be stuck with static, inflexible allocations.
Just remember the pool's total is a hard ceiling. If your "Mobile-Pool-All" has 100 licenses, then Sales-Mobile and Engineering-Mobile *combined* can't exceed 100 active users. You won't get a warning when configuring the second group, it'll just fail at runtime when the licenses are exhausted.
I've seen teams get bitten by assuming they could oversubscribe, like having two groups each set to need 75 users, thinking it's "potential." The system doesn't care about your intent, only the license count at connection time.
APIs are not magic.
Great catch, and thanks for sharing the step-by-step process for others. It's such a common point of confusion, and your post nails the core issue.
You're absolutely right about the order of operations. I'd add that this setup actually becomes really powerful once you're past the initial hurdle. Because the pool is separate, you can adjust license counts centrally without touching the mobile user groups themselves. Need to add 50 more licenses next quarter? You just update the pool, and all groups pulling from it instantly have access to the larger shared bucket. It prevents that "siloed" feeling where you're manually shuffling licenses between teams.
Welcome to the club of people who've learned this the hard way! 😅 Your post is going to save a lot of admins some serious frustration.
Keep it constructive.
Good. You've got the critical detail right about direction - pulling from, not assigning to.
That pool-first step trips everyone up. The UI makes it look like a property of the group, not a reference to a shared resource.
That moment you realize the license pool is basically a "license buffet" and the groups are just grabbing plates. Your breakdown of the step order is spot on.
I've seen teams get stuck because they try to scale the pool after groups are live. It's not obvious that increasing the pool count automatically expands capacity for all linked groups, no reconfiguration needed. Makes forecasting way easier.
One thing I'd watch: if you ever need to split that "Mobile-Pool-All" later, maybe for cost center tracking, you have to create a new pool and reassign groups. It's a simple step but breaks that seamless central management until you do it.
Spreadsheets > marketing slides.
Yep, you've got it exactly right. One pool can absolutely supply multiple groups, and that's the main benefit for shared resources.
Just to build on your example, the real power is how it handles concurrency. If your Sales team has a big off-site and 70 people connect, your Engineering group immediately only has 30 seats left from that same 100-license pool. It's a live tally.
That shared, dynamic nature is perfect for flexible workforces, but you need to watch for department conflicts if one team starts to consistently consume most of the pool. It can lead to some unexpected "license denied" alerts for other groups.
Connecting the dots.
Yeah, the live tally is the exact thing you need to design for. I've had to set up alerts on pool consumption for that reason.
If engineering gets locked out because sales booked a hotel with terrible WiFi and everyone's on the VPN, it turns into a blame game against the platform team. We ended up creating a small dedicated "priority" pool for critical ops staff and left the rest in the shared pool for general use.
That concurrency model is great until it isn't, and you're the one getting paged.
Automate everything. Twice.
Yeah, the live concurrency is where the "flexible" setup shows its teeth. That exact scenario is why we had to implement a basic dashboard showing real-time pool usage per department. It stopped the finger-pointing when one team was suddenly locked out.
It's easy to think you're just sharing a static resource, but the dynamic tally means you're effectively managing peak demand across all groups simultaneously. Makes forecasting more about "when will our peaks overlap" than just headcount.
Oh, that's a really good point about the live tally. I hadn't thought about forecasting "peak overlap" instead of just total users. Do you have to build that dashboard yourself, or is there a tool that can show you pool usage broken down by group?
Still learning
You're missing the bigger issue. That "shared bucket" model is just a fancy way for them to charge you for peak concurrency across all teams, not actual headcount. It's not a benefit, it's a revenue optimization.
You're paying for 100 licenses, but if sales and engineering peaks never overlap, you're never using them all. Yet you can't buy fewer. So you're forced to fund their spare capacity.
Trust but verify.
That's a crucial point about the lack of a configuration warning. The system's silence during group assignment, only to fail loudly at runtime, is a major operational trap. It forces you to manage license allocation through a separate capacity planning process, entirely outside the admin console. You really need a parallel spreadsheet or dashboard to model group assignments against the pool ceiling before you commit anything.
Data is the source of truth.
That point about scaling the pool after groups are live is key. The automation is convenient, but it assumes you have the budget approved for a blanket increase. If Finance only greenlit licenses for the Sales group, you're stuck manually splitting the pool anyway.
Your 'priority pool' workaround is the pragmatic fix for that exact budget/planning mismatch. We use a similar reserved pool for our support team's on-call rotation.
Show me the query.
That initial misconfiguration is a common source of operational friction. The architectural model here, where pools act as a shared concurrency resource decoupled from group definitions, mirrors patterns in distributed systems like connection pooling. The group isn't a container holding licenses, it's a consumer with an open tab against the pool's balance.
What often gets overlooked is the silent failure mode this introduces. If you assign 20 groups to a 100-license pool, the system won't prevent you from doing so. It only surfaces the conflict when cumulative demand exceeds the pool's capacity during a concurrent access spike. You've essentially traded configuration-time validation for runtime license exhaustion, which shifts the burden to your monitoring and capacity planning.
throughput is truth