Maximo Mentor Series  ·  Moving to MAS 9, part 4

Martin Williams  ·  Sep 30, 2026  ·  Part 4 of 10 in Moving from Maximo 7.6 to MAS 9

In part 3, Meadowbank Water found 30 empty security groups and rated its licensing and access work amber. This part is for the person who has to fix that: the Maximo administrator. And it starts with the question every 7.6 admin asks on their first day in MAS: where do I create a user now?

The short answer: in one place, and it isn’t the Users application you know. The longer answer is easiest with a picture of an office building.

In 7.6, Maximo had its own front door. It checked who you were, and it held the keys to every room. In MAS, the suite is the front desk. It checks who you are, gives you a pass for the floors you’re entitled to, and hands out the keys, your security groups, to the rooms on those floors. Some visitors, such as the Technician app on a phone, come in through the service entrance, and they need keys of their own.

We’ll follow one new starter at Meadowbank, Tessa Rosnes, a planner, from the day her account is created to her first login.

1. One register, one front desk

In 7.6, everything about a user lived in Maximo: the user record, the password or the link to LDAP, and the security groups, each in its own application.

MAS 8, 9.0 and 9.1 split that in two. The suite kept its own copy of every user and group, and synchronised it into Manage. Admins learned to watch the sync, and to fix it when it failed.

MAS 9.2 puts it back together. User and group data now lives in one place (for now), the Manage database, and the sync has gone. What hasn’t gone back is where you do the work. Almost everything starts at the front desk: Suite → Access and usage, where you’ll find Users and Security groups. (In 9.1 the same pages were under Suite → Security.)

If you’re reading older advice: anything about “user sync”, MongoDB or the MASUSERSYNC cron task describes MAS 9.1 or earlier. On 9.2 you can skip it.

2. Who are you? Sign-in

Before the front desk can give Tessa a pass, it has to know who she is. MAS 9.2 supports four ways to sign in:

• Local: users and passwords held by MAS itself. Fine for a small team or a test system.
• LDAP: your existing directory, such as Active Directory. Most 7.6 sites use this today.
• SAML: single sign-on through your identity provider, so users sign in once for everything.
• OIDC: single sign-on using OpenID Connect.

For most organisations moving from 7.6, the answer is “the same directory we use now”. That’s one decision to make early, because it shapes how accounts are created.

If you’re loading hundreds of users on day one, you can import them from a .csv file. If users and groups should follow your directory automatically, MAS can take them from providers such as Entra ID using SCIM.

3. Creating a user in MAS 9.2

Here’s Tessa’s account, step by step. Everything is in Suite → Access and usage → Users → Create user, over two tabs: Identity & authentication, then Access & license.

Identity. Her user ID and display name, and a choice most 7.6 admins won’t have seen on one screen: the person record. You can generate it from the user ID, link an existing person, or create a new one, as we do for Tessa. Choose the user ID carefully, because it can’t be changed later.

Account status. Two switches: Deactivate on date and Deactivate after user inactivity. For a contractor with an end date, set it now. It’s the easiest leaver control Maximo admins have had.

Preferences, with Manage settings new in 9.2. This is where 7.6 admins will do a double take. Settings that lived in the Manage Users application are now set as the user is created:

• default site, and whether to use it as a display filter
• storeroom for self-service requisitions
• default repair facility, and access to inactive sites
• default application, language, locale and time zone
• supervisor and workflow delegate

Purchasing. In the Purchasing section, Add permission opens a two-step dialog: pick the organisation (and optionally a site), then build a GL account from its segments. Meadowbank’s segments are cost centre, activity, resource and element, and Tessa gets 6000-100-000. When she raises a requisition, the cost goes to the right budget without anyone typing a code.

Sign-in. Choose her authentication type. With Local, the username can be the user ID, her email or something custom, and MAS can generate a password and email it to her. Then Create & continue to access.

Access & license. Two decisions here:

1. Authorized or concurrent. Authorized reserves her AppPoints permanently. Concurrent takes them only while she’s logged in. Tessa is in Maximo all day, so she’s authorized. Part 5a explains the numbers.
2. Security groups. Add the groups that give her the right applications. Every new user also joins MAXDEFLTREG (so she can change her password) and EVERYONE automatically.

The license summary on the same tab shows what she’ll use. Click Re-calculate license summary after any change.

4. No more user sync, and why that’s good news

In MAS 9.2, IBM removed three things that 8.x to 9.1 admins knew well:

• the suite’s own store of users and groups in MongoDB
• the MASUSERSYNC cron task that copied them into Manage
• the screen that showed whether the sync had worked

The one exception is Maximo Real Estate and Facilities, which still keeps its copy up to date through API calls.

For a 7.6 site going straight to 9.2, that’s one less moving part. There’s nothing to monitor, and no “the user exists in MAS but can’t open Manage” puzzles caused by a failed sync. If you’re upgrading from 9.1 instead, the upgrade moves the sign-in details across for you, and keeps the old MongoDB data as a backup.

5. Security groups: the keys, now cut at the front desk

Security groups still do what they did in 7.6: they decide what people can see and do. What’s new is that in 9.1 and later you manage them at the front desk, in Suite → Access and usage → Security groups, and in 9.2 they cover more. Here’s a group for Meadowbank’s north-depot planners, tab by tab:

• Identity. The name, and new in 9.2, a default application: where members land when they log in. Tessa can still choose her own in her profile, and hers wins, as part 2 showed.
• Sites (new in 9.2). All sites, or the ones this group works at. Before 9.2 this was set only in Manage. The north-depot planners get the north depot.
• Applications. Read, insert, save and delete for each application. Every application needs at least Read, or it won’t appear in the side menu at all.
• Object structures (new in 9.2). Which integration object structures the group can use. More on these in section 6 and in part 8.
• Restrictions. Rules that limit which records the group can see, such as only approved work orders. Rules for everyone are under System actions → Global data restrictions.
• Users, and an Operational dashboard for the group.

Think of sites, applications and restrictions as three layers of the same key: which building, which rooms, and which cupboards in them.

Two more things worth knowing:

• Authorize group reassignment (under More actions) lets named people add others to a group, such as a stores supervisor adding new storemen, without making them full administrators.
• If you’re carrying 7.6 groups across, tidy them first. Part 3’s query finds the empty ones in seconds.

6. Maximo Mobile and role-based applications: keys for the service entrance

Technician, Inspections, Work Approvals, Service Requests, Assets, Inventory Counting, Receiving, and Issues and Transfers are some of the role-based applications. The same app runs in a browser and in Maximo Mobile, which also works offline. (Part 6 covers the move from Maximo Anywhere.)

They don’t come in through the Manage screens. They come in through the service entrance: REST/OSLC API calls on object structures. That changes how you secure them.

Nothing is switched on by default. Role-based applications grant no access when they’re installed. An administrator has to add them to security groups.

How the security fits together. It’s a simple hierarchy once you see it:

The app

Technician

one of the role-based apps

↓

One security template

TECHMOBILE

applied to a security group

↓

Application authorisations

The actions

what you can do: each one a Grant Access? tick

Object structure authorisations

The data

29 object structures in TECHMOBILE

↓

Each object structure

Its own list of authorisations

MXAPIWODETAIL has 52

• The app. Each role-based app has one out-of-the-box security template. For Technician it’s TECHMOBILE.
• Application authorisations: the actions. These decide which actions are available in the app. On a security group, each one is switched on with a Grant Access? tick.
• Object structure authorisations: the data. This tab can hold many object structures (TECHMOBILE lists 29), and each object structure has its own list of authorisations. MXAPIWODETAIL, for work orders, has 52. They start with Read, Insert, Save and Delete, and go on to work steps such as starting and finishing an assignment or stopping a timer. The group needs at least Read on each object structure the app uses.

Apply the template and the group gets both halves in one go. Also check that the group can read the Manage applications behind the data. IBM’s example is MXAPIVENDOR, which lists vendors but also needs Read on the Companies application.

Object structure security is always on in MAS 9. In 7.6, the system property mxe.int.enableosauth was usually left at 0. In that mode, object structure permissions weren’t checked at all: an authenticated user with access to the application behind an object structure was enough. Many 7.6 sites never granted object structures to anyone. Since Manage 8.5, IBM sets the property to 1 and makes it read-only, to close a security gap. So in MAS 9, every REST and OSLC call, including every call a role-based app makes, checks that the user’s groups have an explicit grant on that object structure. Without one, the call fails with an authorisation error such as BMXAA9301E. That’s why the templates matter: they grant every object structure the app needs in one go.

The quick route is a security template. Each role-based app comes with one. In the Security Groups application, on the Applications tab, filter the application type to Tools and Tasks, select the app, and choose Manage/Apply Template → Apply Template. It grants the application, object structures and options the app needs in one go. If you want something different, duplicate IBM’s template and change the copy (more on that below). One catch in 9.2: suite security groups (Suite → Access and usage) can change a group’s object structure permissions, but they can’t apply these templates. Apply templates in the Manage Security Groups application. It’s best to manage them there.

The one people miss is MXAPIPERUSER. Every group for a role-based app needs Read and Save on the MXAPIPERUSER object structure: it’s how the app knows who’s using it. Check the group’s storerooms, labour, GL components, and limits and tolerances too. These are on the additional tabs, along with Dashboards.

How much a template does for you. Open a template’s Security Template Authorizations and you see why nobody should build these groups by hand. TECHMOBILE grants 29 object structures, from domains and assets to tools and work types. On MXAPIWODETAIL alone it sets 52 authorisations, from Read and Save to starting and finishing assignments and stopping timers. Some are deliberately left off, such as Delete, Remove Safety Plan and Enable Assignment Flow.

Duplicate, don’t edit. The templates can be edited, but it’s better to duplicate one and change the copy. It becomes a user-defined template, and IBM’s original stays untouched as your reference and fallback. Name the copy after the role, such as MB-TECHMOBILE, so it’s obvious which one is yours.

Why is my list empty? Each app fills its lists with named queries on its object structures. If a technician says “there’s nothing here”, check the query before the security:

Some data isn’t downloaded to the phone by default, such as work order history in Technician.

At Meadowbank, the 60 technicians moving off Anywhere get a Meadowbank Technicians group: the Technician template applied, MXAPIPERUSER and MXAPIWODETAIL checked, their depot as the site, and a test on a real phone with a real technician’s login, not MAXADMIN.

7. Who administers the administrators?

In many 7.6 systems, “admin” meant one thing: MAXADMIN, or a copy of it. MAS lets you split the job, and it’s worth doing. There are three administrative privileges, set on the user’s Access and license tab:

• System configuration: the catalogue, configurations and licence use in suite administration.
• IDP management: sign-in (LDAP, SAML, OIDC), email (SMTP), certificates and the look of the interface, but not deploying applications or changing database connections.
• API key management: creating and managing API keys. Part 8 covers these for integrations.

People who only create users and assign groups need the USERMANAGEMENT security group, not system configuration. Every administrator must have Authorized access: concurrent isn’t allowed for admins.

At Meadowbank, the service desk team lead gets USERMANAGEMENT so she can set up starters like Tessa. Only two people get system configuration.

8. What lives where

The table to keep by your desk:

9. Five things that catch admins out

1. Following old advice. Anything about user sync or MongoDB describes 9.1 or earlier. On 9.2, users and groups are in one place.
2. Planning for administrator concurrent access. Admins are always authorized.
3. Granting an application without Read. It won’t appear in the side menu, and the user will tell you it’s missing.
4. Assuming object structures are open, as they often were in 7.6. In MAS 9, object structure security is always on. Integrations and role-based apps fail with an authorisation error until each group has the object structures it needs.
5. Leaving leavers active. Account status can switch them off on a date, so set it when you create the account, if you know it.

If you remember one thing

In MAS 9.2 there’s one register of users, and one front desk to run it: Suite → Access and usage. The pass decides who gets in and which floors they can reach. The keys, your security groups, still decide what they can do once they’re inside. Plan your groups by role, tidy them before you rebuild them, and keep the people who create users separate from the people who run the system.

What’s next

Part 5a explains AppPoints in plain English: what authorized and concurrent really cost, and how to count what you need. Part 5b covers installs, custom applications and watching the pool. You can see all ten parts of the series, and what’s coming, on the series page.

← All parts of Moving to MAS 9 Talk to us about MAS 9 administrator training →