New list views in GMAO Cloud

List views are the screen where anyone managing maintenance spends the most time, and the one that gets the least attention during rollout. They get used as they come out of the box, with default columns, and every query ends up being a manual search exercise.

It’s worth spending time on them, because the payoff is daily.

What a well-built list solves

A list isn’t a table: it’s a saved question.

“This client’s overdue orders,” “assets not reviewed this quarter,” “what’s waiting on materials,” “high-priority incidents open for more than three days.” Each of those questions gets asked many times a week, and the difference between having it saved and rebuilding it every time is minutes a day.

Columns, chosen by decision

The criterion for deciding which columns to keep visible isn’t which data exists, it’s what decision gets made on that screen.

In a work order list used to hand out the day’s work, what you need is the technician, the date, the client and the status. Estimated cost or the quote reference are unnecessary there, even though they’re useful data elsewhere.

Practical rule: if a column doesn’t change what you’re going to do when you look at that screen, remove it. A table with twenty columns reads worse than one with six.

Filters that keep coming up

Most management work consists of coming back again and again to the same subsets. It’s worth identifying them and having them ready.

The ones that show up in almost every operation:

• Overdue, which is anything past its status’s maximum time.
• No owner, because that’s what’s going to fall through the cracks.
• Waiting for materials and needs a return visit, so that work doesn’t end up living in a notebook.
• By client or by site, if you manage several.
• By asset family, to review a whole type of equipment at once.

The list as a starting point, not an endpoint

A feature that’s underused: from the list you can go straight to the action, not just to the lookup.

See unassigned orders and hand them out. See a family’s assets and launch a review for them. See a client’s incidents and convert the ones that need it into orders.

When the list is used this way, the screen stops being a report and becomes the working tool.

Exporting without building a report

Not everything you need to pull deserves a report. A filtered, exported list handles most one-off requests: what needs to be sent to a client, what gets brought to a meeting, what gets cross-referenced in a separate spreadsheet.

For anything recurring, a report pays off. There are more than sixty in GMAO Cloud reports, with their own filters, and if you need your own dashboards, the way to do it is connecting your BI tool via REST API or SQL connection — covered in integrations — which also lets you cross-reference with data the CMMS doesn’t have.

Searching, which isn’t the same as filtering

Two operations that get confused, used at different times.

Filtering narrows down a stable subset: this client’s open orders, this family’s assets. It’s what you set up in advance because it repeats.

Searching is finding a specific record you already know something about: a license plate, a serial number, a client’s last name, an item code. It’s a one-off and doesn’t get saved.

The common mistake is using a filter to search — narrowing down step by step until one result is left — when what you need is to type in the value you already know. And the opposite: redoing the same search every day instead of leaving the filter saved.

It’s worth teaching both separately when training the team, because a good part of the feeling that “the system is slow” comes from there.

Sorting by what drives the decision

A small detail with a daily effect: a list’s default sort order should be whatever serves the decision being made on that screen.

For the day’s work, by time or by route. For overdue items, by age. For a family’s assets, by last review date — which puts exactly what’s fallen behind at the top. For items waiting on materials, by order date, so none of them get left to age.

The difference between a list and a report

Worth keeping clear, because it saves arguments:

The list is for operating: viewing, filtering and acting on specific records, right now.

The report is for deciding: aggregating, comparing and seeing trends, every week or every quarter.

Trying to make the list act as a report produces huge tables that can’t be read. Trying to make the report act as a list produces slow queries for something a filter would have solved.

The four lists worth having ready

If you have to start somewhere:

Today’s work by technician. To hand out work and spot imbalances.

Overdue and unassigned. The two subsets that trigger complaints.

Assets by family with their last review. To spot what’s fallen behind.

Waiting on materials. To close out work that’s only waiting on a part, which is usually more common than it looks.

And on mobile

The technician has their own list in the app: their orders for the day, within whatever time window you decide, with the option to sort by route using GPS or to view and take unassigned work.

It works without coverage, just like the rest of the app.

A tip when setting them up

Do it with the people who use them, not in a meeting room. The columns that look essential from management are usually different from the ones needed to hand out work on a Monday morning.

And review them every few months: lists age just like everything else, and columns nobody looks at anymore pile up.

One last note: lists are also the best way to detect that something in the configuration isn’t right. If an “overdue” filter always returns zero, statuses probably don’t have a maximum time associated with them; if the “unassigned” one is always full, assignment isn’t working.

If you want to see how these would look with your own data, you can request a demo.