Users and permissions in a CMMS

User management looks like an administrative matter until the day it matters: when a supplier sees another client’s prices, when a technician changes something they shouldn’t have, or when you need to prove who did what.

In a CMMS there’s an added twist: there isn’t one type of user, there are four very different ones — the person who plans, the person who executes, the person who commissions the service, and the person who subcontracts it — and each one needs to see a different part of the same system.

Three interfaces, not one with permissions

The first product decision worth understanding. In GMAO CLOUD, each role logs in through a different place:

• The web backend for whoever plans and administers.
• The technicians’ app for whoever executes in the field.
• Client access for whoever receives the service.

It isn’t the same screen with things hidden: they’re three interfaces designed for three needs that don’t resemble each other. A technician doesn’t need a stripped-down version of the admin panel; they need something else entirely.

Profiles and permissions

Within each interface, access is controlled by profile: which modules each person sees and what they can edit. That covers the usual needs — keeping admin staff from touching asset configuration, letting a team lead see only their own work without seeing the whole company’s orders — without having to decide it case by case.

Technicians are also grouped into teams with a lead, which is what makes a twenty-person workforce manageable: each lead sees their own team, not a list of three hundred open orders.

Document visibility, where most mistakes happen

This is the control that saves the most work and the one that gets configured the least.

Each document in the document manager carries its own visibility: whether the client sees it, whether the technician sees it, whether the supplier sees it, and whether it requires approval.

The practical result is that a decision that used to repeat every week disappears: what do I show this person. You configure it once per document type and you’re done. And when a supplier stops working with you, their access is revoked: the documentation stays yours and they stop seeing it, without moving a single file.

What the client sees, exactly

Worth spelling out because it’s where most questions come up when opening the portal.

The client sees what’s theirs: their sites, their assets, their orders, their incidents, and the documents you’ve marked as visible to them. They can open incidents with a description and a photo, follow the status of their work orders, download the report for each intervention, and see their upcoming preventive visits on a calendar.

And there are two limits worth knowing, because they’re product decisions, not gaps:

The client can’t change a work order’s status. That’s disabled on purpose: the status of the work is set by whoever executes it.

Their app doesn’t work offline. It installs on the device, but full offline mode belongs to the technicians’ app.

You can also control which statuses are visible to them and which stay internal, and mark which ones shouldn’t send notifications. That last part matters just as much as the opposite: notifying every internal move turns notifications into noise.

Suppliers

They’re registered as users with their own scope and receive the orders assigned to them, logging time, material, documentation, and signature. They can have their own associated warehouses, and you can set a price per item with their agreed discount.

Having them inside the system isn’t a convenience: if they work outside it, the history has gaps exactly where the most expensive interventions are.

The detail that shapes everything: per-user pricing

It looks like a pricing detail and it’s actually a permissions architecture issue.

If the software is charged per user, adding a new technician, a seasonal hire, a subcontractor, or a client becomes a financial decision. And then the predictable happens: accounts get shared.

As soon as two people sign in with the same user, three things break at once. Reports by technician stop meaning anything. The history stops holding up as proof, because you don’t know who did what. And the whole permissions system becomes decorative, because real access belongs to whoever shared the password.

In GMAO CLOUD, licenses are unlimited across all three plans. Register your team, your clients, and your subcontractors without doing math before every new account.

Traceability: who did what

Two things that get appreciated the day they’re needed.

A record is kept of creation, modification, and deletion, with user and date. In a dispute over whether a document was delivered or a value was changed, that’s the difference between an opinion and a fact.

Deletion is logical, not physical. Anything deleted by mistake can be recovered, which is an operational reassurance distinct from security but just as useful.

On data protection

A note of caution, because this is ground where more gets promised than should be.

What can be described are the controls: profile-based access, configurable document visibility, action logging, recoverable deletion, and access revocation for third parties. What can’t be claimed is that any software guarantees compliance with any regulation: legal qualification isn’t something a program does.

The same applies to certifications: describing controls, yes; promising seals, no.

The user who leaves

A case that always comes up and is worth having resolved before it happens: a technician leaves the company, or a contractor’s agreement ends.

What you should not do is delete the user. If you do, the history loses its author: every order they closed, every checklist they filled in, and every signature they collected loses the reference of who did it, and with it, its value as proof.

The right move is to revoke their access and keep the user. The work stays attributed to whoever did it, reports by technician for past periods stay correct, and that person can no longer log in.

It’s the same with a supplier: their access is revoked, and the documentation they uploaded or that was shared with them stays yours, in place.

Where to start

With the minimum: the internal team’s profiles and the default visibility of documents. Client and supplier access can open later, once there’s already content to show — an empty portal generates more calls than it saves.

And a practical recommendation: open access to a pilot client before rolling it out to your whole portfolio. Their questions will tell you which documents need to be marked visible, which is something you never get right the first time.

If you’d like to see how it would look with your roles, you can request a demo.