What you're seeing
A tech opens inventory, or item availability, or the issues and transfers screen, and sees storerooms beyond the one they are assigned to. The data restriction on their group looks right. The condition looks right. They still see too much. You double-check the restriction, it is exactly what you wrote, and the tech still pulls up storerooms that are not theirs.
What's actually happening
The restriction is not broken. Access is combining.
In Maximo, a user's effective profile comes from the combination of their groups. When privileges combine, the highest privilege prevails, and data restriction conditions OR together. If another group the user is in grants the same object with no condition, your narrow condition is effectively bypassed. Almost every time, the tech is in a second group, usually a base or broad role that everyone gets, or MAXEVERYONE, the everyone group that always combines, that opens those same inventory objects with no condition on them. That open grant ORs with your scope, and the union is everything. Your restriction is doing exactly what you told it to. Another group is quietly overriding it by being broader.
| What it looks like | What is actually happening |
|---|---|
| Your data restriction is broken or being ignored | The restriction works fine. A broader group is ORing right past it |
| The condition is wrong | The condition is correct for its group. Another group has no condition on the object at all |
How to fix it
- List every group the tech belongs to. Not just the scoping group, all of them. That full set is the user's effective profile, and it is what actually decides what they see.
- For each group, check whether it grants access to the inventory objects the tech can see too much of, inventory, item availability and balances, issues and transfers, and receipts, without a data restriction narrowing it. The exact objects and views vary by your applications and customizations, so confirm the set in your own environment.
- The offender is the group that opens those objects at large. It is usually a base role everyone is in, a catch-all built years ago, or MAXEVERYONE, the everyone group.
- Make your scoped group the only path to those objects. Remove those objects from the broad group, or take the tech out of the broad group if they do not need the rest of what it grants.
- Recheck as the tech, not as an admin.
If you do not have rights to edit security groups, the person who does needs to do two things. Confirm which of the user's groups opens the inventory objects with no data restriction, and either strip those objects out of that group or remove the user from it, so the scoped group is the only path to that data. The fix is membership and group content. It is not the restriction you already wrote.
What to check after
The tech now sees only their own storeroom across inventory, balances, issues, and receipts. And just as important, they can still do their job, because the scoped group still grants everything they actually need. Fixing a leak by accidentally locking someone out is its own ticket.
Watch out for
MAXEVERYONE, the everyone group, always combines, even when it is marked independent, and it is the easiest broad grant to forget, because nobody put the tech in it on purpose.
Do not try to fix this by marking a group independent. Independence changes how site and application access combine across a user's groups. It does not make a restriction win against a more permissive group, so it will not isolate your scope the way it looks like it should.
The opposite symptom, a tech who suddenly sees nothing, is usually the reverse problem. Their ownership field is blank, so the condition matches nothing, or they are in no scoping group at all. Different cause, different fix.
A storeroom reached through a view, or through an object your condition family never covered, is a real leak rather than a combination problem. If the broad-group check comes up clean, confirm the condition covers every object and view the tech can reach the data through.
A note on where the screens live
Through Maximo Manage 9.0 and earlier, you check group membership and data restrictions in the Security Groups application inside Manage. Starting in MAS 9.1, user and group administration moves up to the suite level, with some of it still running through Security Groups in Manage. The path differs by version. The combination behavior behind this problem is identical across versions.
This fixes the immediate leak. If you are building or rebuilding per-user storeroom scoping from scratch, Give Your Techs Access to Only Their Own Truck, Without Building 200 Groups covers the pattern, and the Maximo Right-Sizing Playbook walks the full solve end to end.
Frequently Asked Questions
Why can a Maximo tech still see other storerooms when the data restriction looks correct?
Because access combines. The tech is in another group, usually a broad base role or MAXEVERYONE, that opens the same inventory objects with no condition. That open grant ORs with your narrow scope, and the union is everything. The restriction is fine; a broader group is overriding it by being broader.
Does marking a group independent fix a storeroom leak?
No. The independent flag changes how site and application access combine across a user's groups. It does not make a data restriction win against a more permissive group, so it will not isolate your scope the way it looks like it should.
How do I find the group that is bypassing my restriction?
List every group the tech belongs to, not just the scoping group. For each, check whether it grants the inventory objects, item availability and balances, issues and transfers, and receipts, without a data restriction. The offender is the group that opens those objects at large, usually a base role everyone is in or MAXEVERYONE.
A tech suddenly sees nothing instead of too much. Is that the same problem?
No, that is usually the reverse problem. Their ownership field is blank so the condition matches nothing, or they are in no scoping group at all. Different cause, different fix.
Related reading. For why this is a combination problem and which security layer actually owns it, see Maximo Security Is Three Layers, Not One.
Quick Maximo questions are always free. Reach out on LinkedIn. I never charge for chatting.