That instinct will cost you, and usually in both directions at once. The phrase that does the damage is "technician equals mobile equals simple license." It bundles two separate mistakes into one assumption, and MAS charges you for both. The first mistake is treating Mobile as if it were its own cheap license. It is not. The second is assuming a mobile role is the lightest tier just because the person is holding a phone. What the role can do sets the tier, not the device it runs on. Mobile is where I see the biggest sizing errors in a migration, and they cut both ways: shops that overpay by parking every mobile user at a heavy tier, and shops that under-buy and then hand their techs a blocked login on day one.
Mobile is not a license tier
Maximo Mobile is a way to reach Maximo, not a license class. A mobile user consumes AppPoints at their Manage user tier, the same Self-Service, Limited, Base, or Premium tier a desktop user consumes at, and a user's entitlement to Mobile is based on the Manage users and the AppPoints already purchased. The mobile capability is bundled into paid Manage user entitlement, not sold as a separate cheaper license. So "we will put them on Mobile to save money" is not a lever. There is no discounted technician-on-a-tablet license hiding in the model. The only lever is the tier the mobile role actually requires, and pretending otherwise is how you end up with a number you cannot defend. The exact weight each tier carries is in the Estimator. This article is about getting the tier right, because the tier is the input that weight multiplies, and a wrong tier multiplied across a few hundred techs is the whole error.
What the mobile role can do sets the tier
Here is the line that matters. A user at the Limited tier can, across all modules, view records, run and view reports, change record status, update the work orders assigned to them, and complete the inspections assigned to them, plus use a small number of modules without restriction. For a mobile tech whose entire job is to receive assigned work, do it, update the work order, and close it out, that envelope often fits, and that genuinely light role usually belongs at the lightest tier.
Now watch what happens as the role grows. The moment a mobile user needs to issue or return materials beyond that limited envelope, approve work, reassign or dispatch to other people, or work unrestricted across more applications than the Limited cap allows, Limited tends to stop covering them, and they move up to Base or Premium. If the mobile role reaches into an industry solution or an add-on application, that usually pushes it to the top tier. The device never changed. The work did, and the tier follows the work.
| Mobile role | What they do | Where the tier lands |
|---|---|---|
| Work-execution tech | Receive, update, and close the work assigned to them | The lightest tier that covers it |
| Inspector | Execute assigned inspections and file results | Light if it stays inside the assigned-work envelope, heavier if it does not |
| Materials-handling tech | Issue and return parts from a truck or storeroom | Heavier, since materials transactions tend to push past the limited envelope |
| Mobile supervisor | Reassign, dispatch, and approve | Heavier still |
| Any role reaching an add-on or industry solution app | Uses a capability outside standard Manage | Usually the top tier |
Exact module coverage per tier depends on your configuration and MAS version, so use this to sort roles, then validate the edges.
Split mobile roles before you size
The single biggest mobile sizing error is treating "mobile techs" as one block and giving the block one tier. They are not one role. The field tech who only executes assigned work, the inspector who files results, the tech who issues parts off a truck, and the working supervisor who reassigns and approves are four different tiers wearing the same hi-vis vest. Size them as one and you are wrong in both directions: you overpay for the pure executors and under-provision the ones who do more, and you will not even see it, because the average hides both.
Split the population by what each group actually does before you map a single tier. This is the same discipline that saves money everywhere in AppPoint sizing. Keep the base role tight, and lift only the subset that genuinely needs more. If only a handful of mobile users approve work or handle materials, that is an add-on role for those few, not a tier bump for the whole crew.
Mobile changes your concurrency math too
Tier is only half of the consumption decision. The other half is Authorized versus Concurrent, and mobile behavior quietly breaks the assumption people make there. Concurrent only pays when your peak number of simultaneous users sits well below your headcount. Mobile works against that, because mobile sessions tend to stay open. A device in a truck logged in all shift holds a concurrent slot the whole time. Offline use, background sessions, and a session closed without a clean logout that keeps holding its slot for a while after the person stops all push your real peak up toward your headcount, which is exactly where concurrent stops saving.
So if you are counting on concurrent savings for a mobile crew, do not model it on headcount and a hopeful peak. Measure the actual login peak for that population first. If you are weighing Authorized against Concurrent for any role, the companion article on concurrent AppPoints walks the break-even, and the Concurrency Calculator runs it for your numbers.
Mobile plus desktop is still one user
One more trap, in the other direction. A person who uses Mobile in the field and the desktop at their bench is one user, at one tier, not two licenses. Do not double-count them. But do set their tier by the most capable thing they do across both surfaces. A supervisor who approves on the desktop and reassigns on the phone is sized for all of it, once.
What good looks like
You know your mobile sizing is right when "mobile" is not a tier in your model at all. You have mobile roles, split by what they do, each mapped to the lightest tier that genuinely covers its work, with the heavier capabilities carved into add-on roles for the few who need them instead of lifting the whole crew. The pure work-execution roles sit light. The richer roles sit where their work puts them. And for any mobile role you want on a concurrent pool, you have a measured login peak, not a hope.
Where to start
- List your mobile roles by what they do, not by job title. Receive-and-close is not the same role as issue-materials or approve-and-reassign.
- Mark the heaviest thing each role does. That action sets the tier, not the device.
- Map each role to the lightest tier that actually covers its heaviest action.
- Flag the roles you assumed were light but are not: the materials handlers, the approvers, the ones reaching an add-on app.
- For any mobile role you want concurrent, measure the real login peak before you trust the savings.
What this covers, and what it does not
This article covers how to size mobile roles so the tier follows the work. It does not build the role-to-tier model for your whole shop, validate it against your entitlement, or design the security that enforces it. The tier and inclusion rules here are commercial terms that IBM revises between releases, so confirm the current licensing against IBM before you commit a number.
If your mobile population spans several sites, mixes in industry solutions, or has grown its own undocumented access over years, sorting it by hand stops scaling. That is the role model the Workshop is built to produce and the Playbook is built to execute.
A Mobile Role Inventory worksheet to sort your mobile population by capability and tier before you size a thing is on its way to the downloads here. In the meantime, run the AppPoints Estimator to turn your roles into a ballpark you can take into the budget conversation. When you are ready to build the role model and the security behind it, the Maximo Right-Sizing Playbook walks the full process from inventory through the build.
If you have not sized the rest of your roles yet, start with How to Size MAS AppPoints Without Overpaying. If you are leaning on shift-based concurrent savings anywhere, read Concurrent AppPoints Are Not Automatically Cheaper before you trust the peak.
Frequently Asked Questions
Is Maximo Mobile a separate, cheaper license?
No. Mobile is a way to reach Maximo, not a license class. A mobile user consumes AppPoints at their Manage user tier, the same Self-Service, Limited, Base, or Premium as a desktop user, and the capability is bundled into paid Manage entitlement. There is no discounted technician-on-a-tablet license.
What sets the tier for a Maximo Mobile user?
What the role can do, not the device. A tech who only receives, updates, and closes assigned work often fits the lightest tier. The moment the role issues materials, approves work, dispatches others, or reaches an add-on or industry solution, it moves up to Base or Premium. The device never changes the tier; the work does.
Should I size all my mobile techs at the same tier?
No. Treating mobile techs as one block is the biggest mobile sizing error. Pure work-execution techs, inspectors, materials handlers, and working supervisors are different tiers wearing the same vest. Split the population by what each group does, keep the base role tight, and lift only the subset that genuinely needs more.
Does Maximo Mobile change the Authorized versus Concurrent decision?
Yes. Mobile sessions tend to stay open. A device logged in all shift holds a concurrent slot the whole time, and offline or abandoned sessions push your real peak toward headcount, which is exactly where concurrent stops saving. Measure the actual login peak for a mobile population before counting on concurrent savings.
Quick Maximo questions are always free. Reach out on LinkedIn. I never charge for chatting.