Give Your Techs Access to Only Their Own Truck, Without Building 200 Groups

Stop before you build the first one. The group-per-truck approach is the instinct almost everyone reaches for, it looks reasonable for about a month, and then it turns into the single most common way a Maximo security model rots. There is a way to do this that scales to two thousand trucks without adding a single group. Let me show you the wrong way first, because you need to feel why it fails before the right way makes sense.

The instinct that rots

You have fifty techs and fifty trucks, and each truck is modeled as a storeroom. A tech should touch only their own truck. The obvious move matches how the first two security layers already work: make a group per truck. SRVTECH-TRUCK-101, SRVTECH-TRUCK-102, and so on. Each group gets a restriction to its one storeroom. Put each tech in their truck's group. It works. You demo it, everyone is happy, you move on.

Then the operation grows. Now it is two hundred trucks. That is two hundred groups, each with its own restriction, its own application authorizations to keep in sync, and its own row in every report you run on security. Every new truck is a new group to create and document. Every tech who changes trucks is a group swap. Every time you change what techs can do in an app, you change it two hundred times, and the day you fix a hundred and ninety-nine and miss one, you have a tech who cannot do their job and no obvious reason why. I have walked into shops with eight hundred security groups where nobody could tell me what forty percent of them did. Once you cross a few hundred groups, the model stops being something a human can hold in their head, which means it stops being something a human can safely change. People stop touching it and create new groups instead, and the sprawl feeds itself.

Here is the part that should end the debate: group-per-truck does not even buy you the safety you think it does. I will come back to why under the combination rule below. So you pay the full maintenance price for a guarantee you never actually get.

Model the assignment as data, not as a group

The root mistake is using a static structure, the group, to model something that changes per person, the truck assignment. The number of groups grows with the number of things you are separating, and that number only ever goes up.

Flip it. Stand up one tech group. Then write a condition that reads the storeroom assigned to whoever just logged in and shows them only the records that match. One group, one rule, every tech scoped off their own record. Onboarding a new tech becomes a single field on their record instead of a new group. Two hundred trucks changes nothing about the design. That is the whole idea, and everything below is how to do it without getting bitten.

The ownership attribute is a real design decision

For the condition to scope per user, it needs a field that answers one question: which storeroom is this tech assigned to. Maximo has no native field that means assigned truck or storeroom, so the field you choose to hold that answer is a genuine design decision, not a detail to wave at.

A couple of native location fields can legitimately hold a storeroom, since a storeroom is a location. The thing to get right is meaning. Pick a field whose meaning is "this person's assigned storeroom." Common candidates are person or labor location fields, or a custom attribute you create specifically to mean assigned storeroom.

The trap is the field that looks convenient. There is a default storeroom field that exists to populate the storeroom on a self-service requisition. Do not hijack it for ownership scoping. It bites you twice. You change that requisition feature's behavior, because you are now writing to a field that drives it for a different reason. And it is only maintained for people who use that flow, so for a truck tech who never touches self-service requisitions it sits empty, your condition matches nothing, and the restriction behaves in ways you cannot predict. If the natural field already carries meaning in your shop, do not collide with it. Create a custom attribute that means assigned storeroom and point the condition at that.

One condition will not cover everything

A tech does not only look at inventory. They issue parts, receive parts, and check balances, and those live on different objects. The field that holds the storeroom is not named the same on all of them, so a single condition will not cover the whole picture. You build a small family of matching rules, one per object, all keyed to the same assigned-storeroom field on the user. The logic is identical each time. Only the object's own storeroom field changes. Miss one object, or a view that reaches the same data, and that gap is your leak. This is the detail a junior misses and a senior nods at, so plan the family up front rather than discovering the missing object in production. Which objects and views those are depends on your applications and any customizations, so map the paths in your own environment rather than trusting a generic list.

The combination rule is make or break

This is the one that catches people who did everything else right, and it is exactly where group-per-truck and the condition approach are in the same boat.

A data restriction does not work on its own. In Maximo, access combines. When a user belongs to more than one group, the security layers are additive and the most permissive group wins. Data restrictions OR together, so a narrow scope added to unrestricted access resolves to unrestricted access. Your careful per-user storeroom scope holds only if the scoped group is the tech's only path to those inventory objects. If that same tech also sits in a base group that opens inventory at large, or in MAXEVERYONE, the everyone group that always combines and rarely carries a condition on these objects, the union opens everything and your scope does nothing.

The discipline is to make the scoped group the only door to those objects. Strip those objects out of any broad group the techs also belong to, or keep the techs out of those groups. This is the part people get backward, and it is the most common reason a careful restriction does nothing in production. And do not reach for the independent flag to rescue it. Marking a group independent 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. If you need a scope to hold, control the membership, do not toggle a checkbox and hope. The habit that saves you is simple. Test the full effective profile, every group the user is in, not the scoped group on its own.

Verify the things the scope actually depends on

You build it and you are not done. The scope is only as good as four things, so check all four.

First, membership. Every tech who should be scoped is in the group. A tech in no scoping group is narrowed by nothing, so they keep whatever their other groups grant. Run it against your roster and find the stragglers.

Second, the ownership field is populated for every scoped tech. A blank value makes the condition match nothing, which fails safe to no access, but it generates a help desk ticket the moment that tech logs in.

Third, no competing broad group. The scoped group is the only path those techs have to the objects in question. This is the combination rule, and it is the one most people skip.

Fourth, coverage. The condition family covers every object and every view a tech can reach the storeroom data through. A missed object or an unrestricted view is a real leak, not a cosmetic gap.

Supervisors break the simple model

A supervisor covers a whole team, so the per-user condition is too tight for them. Do not fix that with a group per supervisor, because you are right back to sprawl. If a supervisor genuinely owns the whole site, give them a separate group scoped to the site with no per-truck restriction. If a supervisor must be limited to only their team's trucks, key off a team you already maintain, a crew or a person group, rather than building a one-off group for each supervisor. Pick the team source you already keep clean and scope off that.

A note on where these screens live

Through Maximo Manage 9.0 and earlier, you manage users and security groups in the Security Groups application inside Manage. Starting in MAS 9.1, user and group administration moves up to the suite level, and the suite carries only a subset of what the Manage application does, so some of this still runs through Security Groups in Manage. The screen path differs by version. The underlying model, the groups, the conditions, and the combination behavior, does not. Confirm the path for your version before you go looking for a tab.

What good looks like

You know it is right when the whole thing fits on one screen. Fifty trucks, one tech group, one supervisor group, a small family of conditions. Onboarding a tech is a single field on their record. A truck changes hands and you change one field. The fleet doubles and the design does not move. When you hand the model to the next admin, they can hold it in their head, which means they can safely change it. Eight hundred groups is the world where nobody touches anything. One group and a condition is the world where the model stays correct three years from now.

Where to start

1. Decide the ownership attribute, the field that means "this tech's assigned storeroom." If the natural field is already taken, create a custom one.
2. Populate it for every tech. This is the data that makes the whole thing dynamic, and later it is your entire onboarding step.
3. Plan the condition family across the objects a tech touches, inventory, balances, issues, and receipts, plus any views.
4. Lock the membership so the scoped group is the only path those techs have to those objects. This is the step that makes the scope real, not the condition itself.
5. Verify the four things above before you call it done.

This article covers the pattern and the decisions, enough to choose the right approach and steer around the landmines. When you are ready to build it for real, the Maximo Right-Sizing Playbook walks the full solve end to end, with the actual conditions written out object by object, the field-level restriction setup, the supervisor and team build, and a worked example that goes from an empty group to a tested scope.

Frequently Asked Questions

How do I scope a Maximo tech to only their own storeroom?

Use one tech security group with a data restriction that reads an ownership field on the user, the storeroom assigned to them, and shows only matching records. One group and one condition family scopes every tech off their own record, instead of a group per truck. Onboarding becomes a single field on the person record.

Why not just build a security group per truck?

A group per truck scales with the number of trucks. Two hundred trucks is two hundred groups, each with its own restriction and authorizations to keep in sync, and the model stops being something a human can hold in their head or safely change. It also does not give the safety you think, because access still combines across a user's groups.

Which Maximo field should hold the tech's assigned storeroom?

Pick a field whose meaning is "this person's assigned storeroom," such as a person or labor location field, or a custom attribute created for it. Avoid the default storeroom field that drives self-service requisitions, because reusing it changes that feature's behavior and it is only populated for people who use that flow.

Why does my storeroom restriction get bypassed?

Because access combines and a broader group wins. If the tech is also in a base group or MAXEVERYONE that opens the same inventory objects with no condition, that grant ORs with your scope and the union is everything. Make the scoped group the only path to those objects, and test the full effective profile, not the scoped group alone.

When this is not enough. The pattern and the four checks get a single-site fleet scoped correctly. When you have many sites, supervisors who span teams, or a condition family spread across customized objects and views, the full build with every condition written out is the Playbook. If the access is contested, a Workshop sets the model first.

Related reading. For why this is a layer-three problem and not a site one, see Maximo Security Is Three Layers, Not One. For the fast diagnosis when a scoped tech still sees too much, see A Tech Can See Storerooms That Are Not Theirs. For rebuilding the whole security model during the migration, see Rebuild Your Security Model During the MAS Migration.

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