Maximo Security Groups: Designing Access That Does Not Collapse

Almost every messy Maximo security model I have been asked to untangle started the same way. Someone needed a user to see one extra application, so they cloned an existing group, tweaked it, and moved on. Multiply that by a few years and a few administrators and you arrive at the familiar picture: 400 users spread across 90 groups, half of which nobody can explain. The root cause is rarely incompetence. It is a misunderstanding of the one behaviour that governs everything in Maximo security, the additive model.

The additive model, stated plainly

In Maximo, a user's effective permissions are the union of every security group they belong to. If group A grants read access to Work Order Tracking and group B grants approve access to Purchase Orders, a user in both groups can do both. Permissions add together. They never subtract. There is no group that says "deny", and no way for one group to overrule the grant made by another.

The single exception is the Independent of Other Groups flag on a group. When set, that group's site, storeroom, GL, and limit authorisations are evaluated on their own rather than merged with the rest of the user's groups. It exists precisely because the default merging behaviour produces surprising combinations, and it is the tool you reach for when you want a group's data scope to stand alone. Used deliberately, it is powerful. Used by accident, it is another source of confusion.

Why additive plus flat equals sprawl

The additive model is not the problem. Flat design on top of it is. When every group tries to be a complete description of one job at one site, the number of groups you need is roughly the number of jobs multiplied by the number of sites multiplied by every small variation in between. A planner at Site A and a planner at Site B become two groups even though the only difference is the site. Add an approval limit variation and you have four. Add a storeroom restriction and you have eight.

This is combinatorial, and it explains the 90-group estate exactly. Each new request looked reasonable in isolation. Clone the closest group, adjust one thing, save. Nobody was wrong at any single step, yet the outcome is an estate where two groups with near-identical names grant subtly different rights, where nobody can say with confidence what a given user can actually do, and where an audit becomes archaeology. The fix is not more discipline applied to the same flat pattern. It is a different shape.

A layered design

Because permissions add, you can compose a user's access from small, single-purpose groups instead of one bespoke bundle. I use four layers, and I keep each layer doing exactly one job. A user is assembled by picking one or more groups from each layer as needed.

The functional role groups carry application and option access but deliberately no site scope. The scoping groups carry site and organisation restrictions but no application rights. Because Maximo merges them, a user in ROLE-PLANNER plus SCOPE-SITE-A plus SCOPE-SITE-B is a planner at both sites. You never create a "Planner Site A and B" group again. You compose it.

The matrix: a planner at two sites

Here is the worked example that convinces people. A planner covering Site A and Site B, able to raise purchase requisitions up to a limit, is assembled from four small groups rather than one custom one. Each row is a group; the combined effect is the union of all four.

Move the planner to Site C next year and you swap SCOPE-SITE-B for SCOPE-SITE-C. Promote them and you add LIMIT-PR-50K. Nothing about the ROLE-PLANNER group changes, which means it stays true for every planner in the company. That is the entire payoff: groups become reusable building blocks, and the group count grows by addition of sites and roles rather than by multiplication of them.

The security elements that matter in practice

Maximo's Security Groups application exposes more than application access. Knowing which tabs carry which authority is what separates a working design from a leaky one. These are the elements I always account for.

• Application and option access. Which applications a group can open, and which actions inside them (read, insert, save, delete, plus signature options like approve, route workflow, change status). This is the functional role layer.
• Storeroom restrictions. Which storerooms a group can issue from and transact against. A storekeeper at one site should not be able to issue stock at another.
• Labour restrictions. Which labour and crews a group can view and assign, which matters where labour cost is sensitive or unionised.
• GL component authorisation. Which general ledger account segments a group may enter or select. This quietly controls where cost can be charged.
• Purchasing approval limits. Ceilings for purchase requisitions, purchase orders, invoices, and contracts. This is the approval limit layer, and it is exactly where additive merging bites hardest.
• Data restrictions with conditional expressions. Object and attribute level rules that hide, make read-only, or qualify records based on a condition. Powerful, and the element most often misused.
• Start centre template assignment. Groups drive which start centre a user lands on. Tie a clean start centre to your base or role layer so users get a sensible default without a bespoke setup each.

Auditing what you already have

If you have inherited a sprawling estate, do not redesign in the dark. Measure first. The audit is four extractions and one plan.

1. Extract group membership. Pull the full user-to-group map (MAXUSER, GROUPUSER, MAXGROUP). This is your ground truth for who has what today, before any theory about who should.
2. Identify single-member groups. Any group with exactly one user is almost always an accident of cloning. These are your quickest wins and your clearest evidence of sprawl. Flag every one.
3. Identify unintended approval unions. For each user, compute the union of purchasing limits and approval options across all their groups. This surfaces the person who can approve a purchase order to a level no single group intended, because two groups combined to grant it. These are the findings auditors care about.
4. Map each user to the target layers. Decide which base, role, scope, and limit groups each existing user should resolve to. Where the target union differs from today's actual union, you have found a genuine access change to review with the business.

The remediation sequence matters as much as the findings, because the fastest way to lose trust in a security project is to lock people out on Monday morning. I run it additively, mirroring the model itself:

1. Build the new layered groups alongside the old ones. Nothing is removed yet.
2. Add the new groups to users so their union is a superset of what they had. Access can only expand at this stage, never contract, so nobody is blocked.
3. Verify in a test cycle that every user can still do their job through the new groups, using the extracted membership as the checklist.
4. Remove the legacy groups from users one cohort at a time, watching the helpdesk after each removal.
5. Retire the emptied legacy groups only once no user references them.

Because you only subtract access in the final, monitored steps, any mistake shows up as a support ticket rather than a plant-wide outage. Access design is closer to RBAC design across CAFM systems in spirit than to a configuration switch, so treat it with the same change control you would give any configuration change in Maximo.

Joiner, mover, leaver, and the identity provider

A clean model decays without a process to keep it clean. The layered design pays off most when it drives a joiner-mover-leaver (JML) workflow, because each life event maps to a simple group operation rather than a bespoke build.

• Joiner. Assign base plus the role, scope, and limit groups for the job. No cloning, no new group. A new planner at Site A is BASE-ALL plus ROLE-PLANNER plus SCOPE-SITE-A.
• Mover. A transfer is a swap of scope groups. A promotion is an added limit group. A change of function is a swap of role groups. Because roles carry no site and scopes carry no rights, the moves do not interfere with each other.
• Leaver. Deactivate the user. Group hygiene is unaffected because no group was personal to them.

Push this upstream by integrating Maximo with your identity provider. Maximo supports application server security and federated sign-on, so the identity provider becomes the source of truth for who a person is, and directory group membership can drive Maximo group assignment. When HR moves someone in the identity provider, the mover operation flows through rather than waiting on a manual ticket, and a leaver is deactivated centrally. The layered groups are what make that mapping clean, because directory groups line up naturally with roles, sites, and limits instead of tangled bespoke bundles.

Conclusion

Maximo security is additive, and that single fact should shape every design decision you make. Fight it with flat, bespoke groups and you get sprawl that no audit can penetrate. Work with it through layered, single-purpose groups and access stays legible even at hundreds of users, an audit becomes a query rather than a dig, and joiner-mover-leaver turns into a set of small group swaps you can hand to an identity provider. The model was never the problem. The shape you build on top of it is. For the wider context, see my introduction to IBM Maximo.

References: IBM Maximo Manage documentation and the IBM Maximo Application Suite overview.