Your own maintenance app, with GMAO CLOUD behind it

Some GMAO CLOUD customers are building their own screens connected to our API, the entry point that lets other programs read and save data in the system: a dashboard with the indicators their management looks at, a portal where their customers see the status of their requests, a technician app with the exact flow of their operation.

We think it’s a good idea, and we want it done well. This post explains how to approach it: what you provide, what GMAO CLOUD keeps providing, and what’s worth deciding before you start.

GMAO CLOUD as infrastructure

A CMMS has two layers that are usually seen as one.

The bottom layer is what stores and runs maintenance: assets and their history, preventive maintenance that generates itself, users and their permissions, the record of who did what, backups, and sync for technicians with no coverage.

The top layer is how you see it and work with it: which screen your service manager opens in the morning, what your customer sees when they log in, in what order the technician fills in the report.

The top layer is where each company differs most. The bottom layer concentrates common capabilities that are costly to build and maintain properly. Building your own view on the GMAO CLOUD API means keeping the first without carrying the second.

What you can build

What we see among customers, without naming any:

Custom dashboards. The indicators that matter to your management, grouped your way and in your colours, alongside data from your other systems. They’re read-only, which makes them the simplest case to start with.

A portal for your customers. A website with your brand where your customers see their work orders, open requests or check the documentation for their facilities. If you don’t need anything special, GMAO CLOUD already includes its own customer portal; if you want it inside your website or customer area, the API makes that possible.

A technician app with your flow. For very particular operations, where the technician follows steps that are your way of working. It’s the most demanding case, for the reasons explained below about working offline.

They’re all built the same way: your app uses the API to read and write assets, facilities, customers, work orders, incidents, quotes, stock or documents. The full reference, with how to connect and examples of each operation, is at developers.gmao.cloud.

What GMAO CLOUD keeps handling behind it

Even if your users never see one of our screens, everything else keeps running behind them:

• Preventive maintenance keeps being generated with its frequencies, holidays and meters, even if your app knows nothing about it.
• Every change is recorded under the GMAO CLOUD user it was made with, whether it came from your app or ours.
• The data lives in one place: what your portal creates, your office sees in the panel, and what a technician closes with our app shows up on your dashboard.
• Backups, error tracking, updates and security are still handled by us, with a team that has been building CMMS for more than ten years.

And a safety net an in-house build doesn’t have: if your app fails, you can keep an alternative way of working through the GMAO CLOUD panel and apps, which run on the same data. For that to work on the day you need it, prepare it beforehand: make sure your users keep their GMAO CLOUD access and know the basics of its tools.

What to decide before you start

Which user your app connects as

Every time your app uses the API, it acts as a specific GMAO CLOUD user, and what it does is recorded under that user. Create a dedicated user for your app, with the profile that matches what it needs to do, instead of reusing a person’s. That way the history tells apart what your app did from what someone did by hand, and revoking its access doesn’t leave anyone without theirs.

Bear in mind what that implies: if your whole portal uses a single technical user, the GMAO CLOUD history will identify the application, not the specific person who did each thing in it. If you need to know which customer opened each request or which employee changed each order, your app has to record it, or connect with each person’s own user.

What each person sees in your app

If different people use your app — your customers in a portal, for example — what each of them sees is decided by your app. Design it from the start: a customer seeing only their own facilities and orders can’t depend on nobody editing the page address.

Working offline

If you build a technician app, think about what happens where there’s no coverage: basements, rooftops, warehouses, roads. Storing work on the phone and syncing it later without losing or duplicating anything is the hardest part of a field app. If your operation needs it and you’d rather not solve it, you can combine: your app for what’s particular, and the GMAO CLOUD technician app, which already works offline, for the rest.

What data goes out to other services

Always write through the API

Read and save data through the API, never by putting it in directly underneath the system. The API is what records every change and who made it; writing underneath skips that record, and that’s what turns a reliable history into one nobody trusts.

What we offer to help you build it

We don’t leave you alone with the documentation.

Advice before you start. We review the approach with you: which screens you want, what data they need, which user they connect as, and what’s best left in the GMAO CLOUD apps. An initial review can save weeks of later work.

Test environments. You develop and test on a separate installation, not on your real data. Whatever breaks while you build breaks there, and only what already works reaches production.

Custom access. If your app needs data or an operation the API doesn’t offer yet, we study it with you and consider adding it. The API grows with what the people building on it need.

How API access works

It goes by plan, with a usage volume suited to each one. For high-volume connections, we size it with you. That way you know from the start what your app can do and what it costs, and we can make sure the system responds just as well for everyone.

And if you’d rather we built it?

That’s an option too, and often the simplest one. If what you’re missing is a screen, a field or a workflow GMAO CLOUD doesn’t have, tell us: we study it with you and, when it’s useful, build it into the product, where our team maintains it instead of yours. How we adapt GMAO CLOUD to each company.

Building your own view and asking us to adapt ours aren’t mutually exclusive. What matters is that behind it there’s a single system, maintained by a team, holding everything.

If you’re thinking about building something on GMAO CLOUD, the documentation is at developers.gmao.cloud. And to plan it with us, request a test environment or tell us what the API is missing, write to us.

Frequently asked questions

Can I build my own app on GMAO CLOUD? Yes. The API lets you read and write assets, facilities, customers, work orders, incidents, quotes, stock and documents, and it is documented at developers.gmao.cloud. Your app provides the interface; GMAO CLOUD remains the system that stores the data, generates preventive maintenance and records every change.

What happens if my app stops working? You can keep an alternative way of working through the GMAO CLOUD panel and apps, which run on the same data. For it to be a real alternative, your users need to keep their access and know those tools.

Can I test my app without touching my real data? Yes. We offer test environments: a separate installation, without your real data, to develop and test on.

What if the API is missing something I need? Tell us. We study what your app needs and consider adding it to the API.

Does the API have limits? API access goes by plan, with a usage volume suited to each one. For high-volume connections, we size it with you.