Management
Plans, assigns, controls costs and pulls reports from the browser. It’s where decisions get made.
Guide
Who sees what, and why that question decides so much
A CMMS is used by very different profiles: managers, technicians, customers and subcontractors. Making sure each one sees exactly what’s theirs is what lets you open it up without worry, and above all, what makes it actually get used.
The principle: scope, not screens
What determines what a person sees in GMAO CLOUD isn’t their menu — it’s their scope. A technician sees their work orders, a customer sees their sites, a subcontractor sees the jobs assigned to them, and a manager sees the operation they’re responsible for. That boundary is enforced on the server, not just in what’s shown on screen, which is the difference between truly limiting access and just hiding buttons. From there, permissions decide what each profile can do with what it can reach: view, create, edit or delete.
The profiles that coexist
Each one enters through its own door and works with what’s theirs.
Technician
Their app, their work orders, their logged hours. They don’t need to see the rest of the system, and it wouldn’t help them.
Customer
Their sites, their work orders and their documents, limited to their own and never reaching anyone else’s.
Subcontractor
Only the jobs assigned to them. With their own user account or a one-off link if they’d rather not sign up.
Multi-company and multi-site
In groups with several companies or operations with many sites, scope isn’t a matter of trust — it’s a matter of practicality: seeing six hundred work orders when only twenty are yours helps no one. The system supports several companies within the same installation and limits each user’s scope to the ones they belong to, and the same goes for sites. The visible effect is that each person opens the system and sees their own work, which is the condition for using it daily instead of only logging in when forced to.
You set the access policy
Password requirements —length, complexity, expiration and whether reuse is allowed— are configured by each installation’s administrator, not imposed from above. Every access and every action is logged with the user, the time and the origin address, which is useful both for an audit and for settling arguments about who changed what. And it’s worth stating what isn’t there yet: two-factor authentication is only partially developed and can’t be turned on yet.
Why this can be done properly
Everything above has a precondition that isn’t technical: that adding a person doesn’t cost money. When every license is paid for, what happens in practice is that three technicians share one account, and from there the history stops counting as proof, per-person reports mean nothing, and traceability breaks exactly where it matters most. In GMAO CLOUD licenses are unlimited on every plan, and that’s not just a pricing advantage: it’s what makes the permissions model worth anything at all.
Shall we look at it with your way of working?
Leave your details and we will get in touch to see whether we fit. No commitment, no lock-in period.
Delegating without losing control
The most common case in large operations isn’t about security — it’s about organization: whoever runs a zone needs to be able to assign work, close work orders and pull their own reports without depending on headquarters, but without seeing or touching anyone else’s. That’s solved by combining the two levers: scope limits which sites and customers that person can reach, and permissions decide what they can do with them. The practical result is that a branch can operate with real autonomy while headquarters keeps the aggregate view, and onboarding a new zone manager becomes assigning their scope instead of negotiating what they get to see.
The common mistake: granting permissions per person
The intuitive way to set up access is one person at a time: this one gets this, that one gets that. It works the first month and breaks by the sixth. When someone new joins, nobody remembers how their predecessor was configured, so it gets copied by eye; when someone changes roles, new things get added and old ones don’t get removed; and after two years there are as many different configurations as there are people, none of them documented. What holds up is defining profiles first —what a technician needs to see, a team lead, a billing clerk, a zone manager— and assigning people to profiles. The test of whether it’s set up right is simple: onboarding someone new should be a one-line decision, not a half-hour session.
Permissions are also a matter of record-keeping
There’s a less obvious reason to take this seriously: a maintenance record is only worth as much as its traceability. A signed job sheet says who did the work, and that claim only holds up if each person logs in with their own account. The shared shop account —the classic "technician / technician" login that the whole shift knows— isn’t an administrative shortcut: it’s what turns a history into a document that proves nothing. When, three years from now, someone needs to show who inspected a piece of equipment, or simply understand why something was done a certain way, the difference between having a name and having a generic login is the whole difference there is.
Frequently asked questions
Can each person have their own account even if they share a shift?
They must, and it’s not an administrative detail. The evidentiary value of a maintenance history depends on each intervention carrying the name of whoever did it. A generic account shared by the whole shop turns the record into something that proves nothing on the day you need it to prove something.
How many users can I add?
As many as you need. Licenses are unlimited on every plan, with no extra cost per user, and that includes technicians, managers, customers and subcontractors.
Can one customer see another customer’s data?
No. Each account’s scope is limited to its own sites, assets and work orders, and that limit is enforced on the server, not just by hiding options on screen.
Can I enforce strong passwords?
Yes. Length, complexity, expiration and whether reuse is allowed are all configured by each installation’s administrator.
Is there two-factor authentication?
Not yet. It’s partially developed and will be enabled per user or per company. In the meantime, password policy is the lever available.
Is there a record of who did what?
Yes. Access —including failed attempts— and user actions are logged with their time and origin, which is useful for audits and for settling disputes about who changed what.
Let’s map out your profiles
In the demo we set up who sees what in your case, which is usually the conversation that clarifies the most.