AppPoints and Security Groups
Two books, one outcome. Decide your access and AppPoint model with the Workshop, then build it in MAS with the Playbook.
Most of the Maximo problems I get called in to fix are not software problems. They are decisions that got made fast, under pressure, by people who did not have the time or a framework to think them all the way through, and then the team lives with that decision for years. How you size AppPoints. How you build your security model. Get those two right and Maximo runs the way it is supposed to. Get them wrong and you spend the next three years building workarounds for your own setup.
It usually shows up as two separate headaches. Finance is looking at an AppPoint bill nobody can explain and asking why the number is so high. Meanwhile the security model has grown to a few hundred groups nobody fully understands, a new group bolted on every time someone needed to separate one more truck or storeroom or site. The two problems feel unrelated. They are owned by different people who do not talk to each other. And the gap between them is exactly where the money leaks.
Why this is one decision, not two
Here is the thing almost everyone misses. In MAS, the security model is the license bill. They are not two projects that touch at the edges. They are one project viewed from two angles. Every security group carries a field, LICENSEIMPACT, that sets the group's license tier, and a user consumes at the highest tier of any group they belong to. The act of granting access is the act of setting the licensing bill. There is no later step where finance independently decides what to buy. Security decided it the moment the groups were built.
That is why you cannot size AppPoints without designing access, and you cannot design access intelligently without seeing the AppPoint consequence. Try to size the license first and you are guessing at access. Design access with no view of cost and you build a clean model that happens to be needlessly expensive. The second half of the problem is group sprawl: without data restrictions, every new thing you need to separate becomes a new group, and fifty trucks becomes fifty groups nobody can maintain. The fix is one condition that reads each user's assignment at runtime, so one group scopes fifty people to fifty different sets of records. Fewer groups, lower cost, a model that stays manageable as you grow.
What each access tier costs in AppPoints
Every security group carries a tier in its LICENSEIMPACT field, and a user draws at the highest tier of any group they sit in. These are the per-user AppPoint weights, which means this table is the price list your access design is quietly writing.
| License tier | Authorized (per named user) | Concurrent (per session) |
|---|---|---|
| Self-Service | 0 | 0 |
| Limited | 2 | 5 |
| Base | 3 | 10 |
| Premium | 5 | 15 |
AppPoint weights as of 2026. Concurrent runs about three times the Authorized weight per seat, so it is not automatically cheaper. Administrators carry a reserved entitlement at Base 10 or Premium 15. IBM changes these over time, so re-verify against current IBM documentation before you budget.
Two books, two jobs
I pair them on purpose. A decision with no execution path stalls out in a steering committee. Execution with no real decision behind it just builds the wrong thing faster. Together they take you from "we need to figure this out" to "it is configured, and the team agrees with it."
Decide it
A structured working session, not a slide deck. You run it with your own team on your own data and walk out with a decision instead of another meeting. It produces:
- A security maturity score and a license efficiency score, read together
- A gap list with the evidence and the dollar figure behind each one
- A sequenced roadmap that hands off to the Playbook
- A results report and an executive readout for the budget conversation
Build it
The execution manual that turns that decision into a configured system, step by step and field by field, in the order you do the work. Seven phases:
- Inventory current access and consumption
- Design the target role and security group model
- Translate access into AppPoints, then validate against entitlement and budget
- Build, test, and provision in MAS
- Govern and true up, including the truck-and-storeroom scoping solve end to end
If you are not yet sure where you are headed, run the Workshop first. If the decision is already made, the Playbook executes it on its own. Both stand alone, but the pair is the point.
Why now
Two clocks make this work urgent. The universal one is the end of Maximo 7.6 support and IBM's path to MAS for every EAM customer. That migration is coming whether you shape it deliberately or have it shaped for you by defaults and deadlines. The federal accelerant is FedRAMP: federal and federally-adjacent organizations face a hard deadline to move to MAS SaaS for Government, which turns "we should plan this" into "we have to plan this now." The best time to run this set is before the migration kicks off, when the decision can still shape the scope and the purchase. It still pays off after, when the work shifts from sizing the first buy to recovering value from one already made.
Who this is for
This set is written for the people who do the work: Maximo administrators and functional leads who own access and licensing, planners and asset and reliability managers who live with the result, and the consultants who run these sessions and migrations for clients. It assumes you run Maximo through the web interface and it targets the current Maximo Application Suite (MAS 9) wherever versions matter.
This is the first set in The Maximo Workshop & Playbook Series. Every set covers one high-stakes Maximo decision and comes in two parts: the Workshop that gets your team to the decision, and the Playbook that turns it into a configured system.
Frequently asked questions
What is the difference between the Workshop and the Playbook?
The Workshop is a facilitated session that gets your team to a decision on access design and AppPoint sizing. It produces two linked scores, a gap list, and a roadmap. The Playbook is the execution manual that turns that decision into a configured MAS system, step by step and field by field. You decide with one and build with the other.
How do AppPoints and security groups relate in MAS?
They are the same decision. Every security group carries a LICENSEIMPACT tier, and a user consumes at the highest tier of any group they belong to. Granting access is the act of setting the license bill, so you size AppPoints by designing access, not by negotiating with procurement.
Do I need both books?
They stand alone, but they are built to pair. If you are not yet sure where you are headed, run the Workshop first to decide and sequence the work, then use the Playbook to build it. If the decision is already made, the Playbook executes it on its own.
We already migrated to MAS. Is this still useful?
Yes. Before migration the set sizes your first purchase. After migration it recovers value: finding over-tiered users, moving access type where real concurrency supports it, freeing pool headroom, and walking into the true-up and renewal with a defensible number instead of last year's guess.
Decide it on purpose. Build it without guessing.
Browse Store