The Promise

"Single pane of glass" is one of the most repeated phrases in enterprise software. The pitch is simple and appealing: all your data, in one place, visible to everyone. No more switching between systems. No more information silos. One view, one truth, one screen.

It sounds like the answer to every coordination problem. And for a narrow set of use cases — executive dashboards, real-time monitoring of homogeneous systems — it works. When everyone on the team needs to see the same metrics at the same level of detail, a single unified view makes sense.

The problem is that most organisations do not work that way. Certainly not in field operations.

Where the Assumption Breaks

The single pane of glass assumes that visibility is universally good — that more information available to more people produces better outcomes. This is true up to a point, and then it stops being true and starts being dangerous.

Competitive separation. When multiple contractors work on the same infrastructure project, they need access to shared base layers — cable routes, pole locations, duct infrastructure. They do not need access to each other's work. Contractor A seeing Contractor B's progress, crew assignments, and material consumption is a competitive intelligence leak, not a productivity gain. A single pane of glass that shows everything to everyone makes this kind of separation impossible by design.

Role-appropriate information. A field worker installing cable needs to see their assignments, the relevant section of the map, and the materials they are authorised to pick up. They do not need to see quality control validation reports, payment calculations, or the work orders assigned to other crews. Showing them everything does not help them work better. It adds cognitive load, creates confusion, and increases the risk of someone acting on information they were not meant to see.

Regulatory and contractual boundaries. In regulated industries — utilities, government infrastructure, healthcare-adjacent operations — data visibility is not a preference. It is a legal requirement. Certain users must not see certain records. Certain data must not cross certain boundaries. A system designed around the principle that everyone sees everything has to bolt these restrictions on after the fact, and bolt-on restrictions are the ones that fail.

Operational focus. When a project manager looks at a hundred-kilometre fibre buildout, they need aggregate progress, timeline status, and budget variance. When a field supervisor looks at the same project, they need today's assignments, yesterday's reports, and this week's material availability. When an auditor looks at it, they need the transaction log and the approval chain. Giving all three the same view helps none of them. Each needs a different slice of the same data, presented at the right level of detail for their role.

The Real Problem Single Pane of Glass Was Trying to Solve

The appeal of a single pane of glass is not actually about visibility. It is about two deeper problems that organisations genuinely suffer from.

Data silos. When information lives in five different systems that do not talk to each other, coordination fails. The GIS team uses one tool, the work management team uses another, the inventory team uses a third, and the finance team uses a fourth. Nobody has a complete picture because the picture is split across databases with no common key. The single pane of glass promises to fix this by putting everything in one place.

Inconsistent truth. When the same fact — how many metres of cable were installed on Tuesday — exists in three systems and each has a different number, nobody knows which one is right. The single pane of glass promises to fix this by being the one source of truth.

Both of these are real problems. But the solution to data silos is not "show everything to everyone." It is "store everything in one system and control who sees what." And the solution to inconsistent truth is not "one view for all." It is "one dataset, queried differently depending on who is asking."

The distinction matters because it changes what you build. A system designed around "everyone sees everything" has to add restrictions later — and those restrictions are always incomplete, always an afterthought, always the thing that breaks when a new feature ships. A system designed around "the right view for the right role" builds visibility controls into the foundation and makes them the default, not the exception.

What the Right View Looks Like

The alternative to a single pane of glass is not information silos. It is the same data, the same system, the same source of truth — with visibility shaped by role.

Shared layers, separated work. Two contractors on the same fibre build see the same base infrastructure — poles, ducts, cable routes. Each sees only their own work orders, their own crew assignments, their own installation reports. The data lives in one system. The view is different.

Capabilities separated from visibility. A field worker can be granted the ability to edit reports without being granted the ability to see other workers' reports. The permission to do something and the permission to see something are independent controls. This means you can give a worker full editing capability within a precisely scoped view — which is what field operations actually requires.

Server-enforced boundaries, not UI hiding. When a user should not see a record, the record does not exist from their perspective. Not hidden behind a disabled button. Not filtered out of a list view. Not present in the API response. Not included in an export. The data genuinely is not there — because the visibility control is applied on the server before data leaves the database, not in the interface after it arrives.

Role-shaped dashboards from the same dataset. The project manager sees aggregate progress. The field supervisor sees today's assignments. The auditor sees the transaction log. All three are querying the same underlying data. None of them sees everything. All of them see exactly what they need.

The Vendor Test

A useful exercise when evaluating any platform that promises a single pane of glass: ask what happens when two users should not see each other's data.

If the answer involves separate deployments — separate databases, separate environments — then the platform was designed for full visibility and cannot handle partial visibility without splitting into silos. You have traded one problem for another.

If the answer involves UI-level filtering — hiding menu items, disabling buttons, filtering list views — then the data is still there, still in the API, still in exports. The boundary is cosmetic. It will hold up to casual use and fail under any scrutiny.

If the answer involves application-layer filtering applied endpoint by endpoint — then the boundary is real but fragile. Every new feature, every new API endpoint, every new export format is a potential leak. The boundary will be correct the day it ships and will drift as the codebase grows.

If the answer involves server-enforced, field-level restrictions applied before data leaves the database — then the boundary is structural. New features inherit it. Exports respect it. API calls respect it. The data genuinely does not exist for unauthorised users, regardless of how they try to access it.

The question is not whether the platform has restrictions. Every platform has restrictions. The question is where the restrictions live — and whether they were designed in or bolted on.

Different Numbers, All Correct

There is a subtler version of the single pane of glass fallacy that persists even after you accept that different roles should see different data. It is the assumption that there should be one number — one progress percentage, one status, one answer — and that any disagreement between views means something is wrong.

In practice, the same work viewed at different levels of aggregation produces different numbers, and every one of them is correct.

A work order might be complete. The worker picked up the materials, installed the cable, and submitted the report. From the work order's perspective, progress is one hundred percent. But that work order was one of four under a task, and the task is only forty percent complete because the other three work orders are still pending. The task itself is one of twenty in a project, and the project is at twelve percent. Three different progress numbers for the same physical stretch of cable — and none of them is wrong.

This is not a rounding error or a reconciliation problem. It is the natural consequence of looking at the same reality from different positions. The field supervisor cares about the work order — is today's assignment done? The project coordinator cares about the task — is this section of the network on track? The programme manager cares about the project — are we meeting the quarterly milestone? Each of them needs a number, and the right number is different for each.

The single pane of glass impulse says: pick one number and make everyone use it. In practice, that means either the field supervisor sees a twelve percent figure that is meaningless to them, or the programme manager sees a hundred percent figure that tells them nothing about the overall timeline. Neither view is wrong. Forcing them into the same frame makes both useless.

The same principle applies horizontally. Two contractors on the same project see different progress numbers because each can only see their own work. Contractor A is at seventy percent. Contractor B is at thirty percent. The project owner sees both, plus the combined figure. All three views are accurate. All three are necessary. None of them is the "right" view that should replace the others.

A system built around the right view for the right role handles this naturally. The data is the same. The aggregation is different. The visibility boundaries are different. And the numbers disagree not because something is broken, but because the questions being asked are different — which is exactly how it should be.

Summary

"Single pane of glass" assumes that visibility is universally good — that showing everything to everyone produces better outcomes. In field operations, this assumption fails at competitive boundaries, role-appropriate information, regulatory requirements, and operational focus.
The real problems that single pane of glass tries to solve are data silos and inconsistent truth. Both are genuine. But the solution is one system with controlled visibility, not one view with no controls.
A system designed around "everyone sees everything" has to add restrictions as an afterthought. A system designed around "the right view for the right role" makes visibility controls the foundation.
The alternative to a single pane of glass is not information silos. It is the same dataset, the same source of truth, with visibility shaped by role — shared layers where collaboration matters, separated views where boundaries matter.
Server-enforced visibility controls applied before data leaves the database are the only boundaries that hold up across every access path — UI, API, exports, and direct queries. Everything else is cosmetic.
The same work viewed at different levels — work order, task, project — produces different progress numbers, and every one of them is correct. Forcing all roles into one number makes every view useless. Different questions deserve different answers from the same data.
When evaluating a platform, the question is not whether it has restrictions. The question is whether the restrictions were designed in or bolted on.