Maximo Security Is Three Layers, Not One, and Most People Fight the Wrong One

Here is the short version. Maximo security is not one thing. It is three layers, and each one answers a different question. Most of the frustration people have with it comes from reaching for the wrong layer to solve a problem, or from not understanding what happens when a person belongs to several groups at once. Once you see the three layers clearly, most of the confusion goes away, and the restriction that "would not work" usually turns out to have been the wrong tool for the job, or undone by another group you forgot the user was in.

Let me lay them out.

The three layers

Layer one is application security. It controls which applications a person can open and which actions they can take inside them. Can this group open Work Order Tracking. Can they hit Save, change status, delete a record. That is all this layer does. It is binary and visible: a button is either there or it is not. It is the easiest layer to understand and the easiest to get lazy about. And it has one hard limit. It cannot tell two people who use the same apps apart. A storeroom clerk in Atlanta and a storeroom clerk in Dallas open the same applications and click the same buttons. To this layer, they are identical.

Layer two is site and org authorization. It controls which sites a group operates in. A group can have full access to Work Order Tracking and still see only the work orders for the sites it is authorized for. This is where most real separation in a multi-site shop happens, and it happens almost for free. If your Atlanta team and your Dallas team are genuinely different sites in Maximo, authorizing each group to its own site separates the data cleanly, with no conditions and almost no maintenance. But this layer has its own hard limit, and it is the one that trips people. Site authorization cannot separate users who share a site. Five trucks running out of one site are one site to Maximo. Three storerooms inside one plant are one site. A planner who should see only their own work, in a building full of planners, is one site.

Layer three is data level security. It controls which individual records a person can touch, inside the apps and sites they are already authorized for. A tech who should see only their own truck storeroom. A planner who should see only their assignment group. A contractor who should see only the assets they maintain. None of those are app problems and none are site problems. They are record problems, and this is the only layer that solves them. It is also the hard part, and I will come back to why.

Use the simplest layer that solves the problem

Here is the rule that saves you the most pain. Solve the problem at the highest layer that can actually hold it, and do not reach lower than you have to.

I have watched people build elaborate record-level restrictions to separate two teams that a single site authorization would have handled. That is effort spent making something hard that Maximo wanted to make easy. The flip side is the bigger mistake, and it is the one that wrecks security designs: using a site-level or group-level tool to solve a record-level problem.

When the separation you need is finer than a site, you have left the first two layers behind whether you admit it or not. The people who do not admit it start creating a group per truck, a group per storeroom, a group per region. It works for a month. Then every new truck is a new group and a new set of authorizations to maintain, and the design collapses under its own weight. That sprawl is not a sign you are working hard. It is a sign you are solving a record problem with a site tool.

Why the third layer is the hard part, and the one insight that changes everything

Data level security is harder for a real reason. The first two layers are checkboxes. This one is a rule that gets evaluated against records as a person works. Getting that rule right and making it scope correctly per user is genuine skill, and it is most of what a good security design is.

But the single most useful thing I can tell you about Maximo security is this. A person experiences the combined effect of every group they belong to, and the combination always runs toward more access, never less. Almost everyone assumes that testing the one group they built tells them what the user will really see. It does not.

Application access and site authorization are additive, and most people already know that. Across a user's groups the permissions merge, the union wins, the most permissive group decides, and adding a group can only add reach.

Data restrictions are where people get burned, because they expect the opposite and the opposite is not true. Conditions across groups do not narrow each other. They OR together. If a user is in two groups that both restrict an object, they get the union of both conditions, which is broader than either one alone. Worse, if a user is in any group that touches that object with no condition at all, that group wins outright and they get unrestricted access. A single broad group, the kind that quietly grants everything so people stop complaining, silently defeats the careful storeroom restriction you built somewhere else.

Extra groups can only widen access, so a restriction is not finished until you test it against every group the user actually holds.

Sit with that, because it is the reverse of what most people expect, and it is the most common reason a data restriction "does not work." The restriction itself is fine. The user is also in a broad group that opens the same object without a condition, and that group wins. So the rule is not build it and trust it. The rule is this: never test the scoped group by itself and call it done. Put the user in every group they will actually hold, log in as that user, and confirm what they can see through the application, the lookups, related records, and views. A restriction that works in isolation is not finished until it works in the full profile.

The other failure modes are worth knowing too: a condition returning the wrong records, an ownership field left blank on the user record, or a restriction pointed at the wrong object. But the combination behavior is the one that catches people who did everything else right, because the group that loosens the restriction is usually sitting in a completely different corner of the security design. And independent groups are not the escape hatch they look like. Marking a group independent changes how it combines, but it is not a most-restrictive switch, and it will not quietly resolve a user down to their narrowest access. If you are counting on it to tighten a user's scope, test the actual result against that user's full set of groups before you trust it. Plan for combination, and test for it.

A trap that springs during a migration

If you are consolidating sites as part of a move to MAS, and a lot of shops do because it cleans up the org model, watch this. Two teams that used to be separated because they were different sites are now one site. Site authorization is additive, so the moment they share a site, both reach it, and the wall that was separating them for free is gone.

That is not a reason to avoid consolidating. It is a reason to know that when you collapse sites, any separation those sites were providing has to be rebuilt at the data layer, on purpose, with a record-level restriction that you have tested against the full set of groups each user holds. Do not assume the restriction holds on its own, because a broad group somewhere else can open the object right back up. Build it, then confirm it. Consolidate without planning for that and you find out the hard way, when the wrong people start seeing each other's work.

So what do you do

Before you build anything, name your layer. Write down the separation you actually need and ask which question it is. Is it about which apps or buttons someone gets? That is layer one. Which sites? Layer two. Which records inside a shared site? Layer three. Most of the time people are frustrated because they have been trying to solve a layer-three problem with layer-two tools, and once you see that, the path forward changes completely.

And when the answer is layer three, remember you are not done when the restriction works for the one group you built. You are done when it works for the user in every group they actually hold. Build for the layer, then test the whole profile.

Get the layer right and you stop fighting Maximo. Get it wrong and you build a maze.

This article covers how the three layers work and how to tell which one your problem lives at. Actually building the third layer, writing a record-level restriction that scopes to each user, doing it without a group for every truck, and scaling it across a real shop, is the work. Give Your Techs Access to Only Their Own Truck walks the per-user storeroom pattern, and the Maximo Right-Sizing Playbook walks the full process, from the mechanics of data restrictions through the patterns that keep them maintainable, including the truck-storeroom solve worked end to end.

Frequently Asked Questions

What are the three layers of Maximo security?

Application security controls which applications and actions a user gets. Site and org authorization controls which sites they operate in. Data level security controls which individual records they can touch inside the apps and sites they are already authorized for. Each answers a different question, and most problems come from using the wrong layer for the job.

Why does my Maximo data restriction not work?

Usually because access combines and a broader group wins. Data restriction conditions OR together across a user's groups, and any group that opens the same object with no condition grants full access outright. The restriction itself is fine. Another group the user is in is opening the object back up. Test the full combined profile, not the scoped group alone.

When should I use a data restriction instead of site authorization?

Use the highest layer that can hold the separation. If two teams are on different sites, site authorization separates them for free. When the separation is finer than a site, such as five trucks sharing one site or a planner limited to their own work, you have a record problem, and only data level security solves it.

Does consolidating sites during a MAS migration affect security?

Yes. Site authorization is additive, so when two formerly separate sites become one, both teams reach it and the separation those sites provided for free is gone. Any separation the sites were providing has to be rebuilt at the data layer on purpose, and tested against each user's full set of groups.

When this is not enough. Naming the layer gets you unstuck. Building layer three for real, per-user scoping that holds against every group a user actually holds and scales across a shop, is the work the Playbook walks, with the truck-storeroom solve shown end to end. If the access is contested, a Workshop sets the target model first.

Related reading. For the layer-three build done without a group per truck, see Give Your Techs Access to Only Their Own Truck. For the fast fix when a scoped tech still sees too much, see A Tech Can See Storerooms That Are Not Theirs. For rebuilding security during the migration instead of porting it forward, see Rebuild Your Security Model During the MAS Migration.

Quick Maximo questions are always free. Reach out on LinkedIn. I never charge for chatting.