Rebuilding the operational layer of an enterprise CMMS.

The situation

A technical foundation existed. The operating system did not.

Jeremy joined a utility organization to administer its computerized maintenance management system. The expectation was that a consultant-led implementation would be near handoff. The reality was earlier and less complete: the geographic information system work provided a useful foundation, but the operational layer that employees needed to request, route, perform, record, and review work had not been built into a usable enterprise system.

That distinction mattered. Replacing the platform or discarding completed GIS work would have wasted useful investment. Treating the implementation as finished would have left departments without the templates, roles, queues, rules, and views required to operate. Jeremy had to learn the system quickly enough to separate what should be preserved from what still needed to be designed.

The challenge was also organizational. A CMMS becomes useful only when it reflects how departments actually work. A template that makes sense in one area can create confusion in another. Permissions that are too broad create risk; permissions that are too narrow stop the work. A mobile queue, homepage, query, or notification has value only when it gives a specific role the right next action.

The decisions

Preserve the valuable work. Rebuild around the real departments.

Jeremy’s first important choice was not to turn the project into a public verdict on the prior implementation. He retained the completed GIS work and focused on the missing operational system. That kept useful technical work intact while creating room to redesign the layer employees would actually use.

The second choice was to learn the platform in context rather than configure it from a generic checklist. Over roughly two months, Jeremy learned Cityworks while working through how service requests, work orders, tasks, materials, labor, departments, crews, notifications, navigation, and mobile work needed to function together.

The third choice was to treat configuration as operating-model design. A work-order template was not just a screen. It defined what the team captured, which tasks followed, where the work routed, what a supervisor could see, and how the record would support future reporting. Permissions were designed around necessary access. Queries and inboxes were built for the context of a department or role rather than as one overwhelming enterprise list.

The rebuild

Build the pieces employees need to move work from request to completion.

The rebuilt operational layer included service-request and work-order templates, task workflows, routing, least-necessary permissions, departments, groups, crews, materials, payroll-fed labor-rate administration, navigation, notifications, and context-specific mobile inboxes. Jeremy also created the homepage, department menus, and hundreds of queries that made the system understandable to different operating audiences.

Those components were not independent features. They formed a chain. A clear intake created a usable request. The request initiated the right work. The workflow supplied the next tasks. Routing put responsibility in the correct queue. Roles and permissions let people act without exposing more than they needed. Materials and labor supported a complete work record. Queries and mobile inboxes turned the underlying data into a practical daily view.

Jeremy worked across departmental boundaries because the enterprise system had to carry handoffs, not just individual tasks. The same approach later supported extensions such as a large-meter process that connected engineering approval to downstream installation work and a hydrant-flow workflow that structured field collection and calculations while preserving professional certification responsibilities.

The system was designed to make the operational logic explicit. That reduced dependence on one person remembering every exception and created a platform that could be improved deliberately instead of through isolated workarounds.

Launch and adoption

Go live, then stay close enough to learn what the configuration missed.

The rebuilt operational platform launched by July 21, 2023. Launch was not the finish line. Jeremy spent the following months embedded with departments, training employees, observing how the system behaved in real work, correcting workflows, and helping people understand where their tasks and information now lived.

That period exposed the gap between configuration that is logically valid and a system that is operationally usable. A queue can contain the correct records and still be wrong for a mobile role. A notification can fire correctly and still arrive too late or with the wrong context. A workflow can satisfy a written requirement and still miss the exception that employees handle every week.

Continuing ownership allowed Jeremy to make those corrections with the full operating model in view. It also gave departments a direct path to explain what was not working rather than building new shadow processes outside the platform.

Continuing extension

Once the core was stable, use events to connect the work around it.

In 2024, Jeremy began extending the platform through webhooks, queued event handling, Power Automate HTTP endpoints, data manipulation, notifications, calculations, field updates, and automatic downstream work. The order was deliberate: integration came after the operational model was stable enough to produce trustworthy events.

This layer supported needs beyond standard configuration without turning the CMMS into an isolated custom application. A task event could trigger a controlled process, reshape information, notify the right audience, update a field, or create the next work in a larger workflow. The system remained the operating source while the automation layer handled carefully bounded transitions around it.

The result is best understood as sustained platform ownership rather than a one-time implementation. Jeremy continues to administer, support, troubleshoot, report on, integrate, and expand the system as operational needs change.

No recovered telemetry supports a public claim about total active users, transactions, time saved, error reduction, uptime, or financial return. The defensible result is that the missing operational layer was rebuilt, launched across the organization, adopted with direct departmental support, and extended into a continuing enterprise platform.

Evidence boundaries

What this story proves—and what it does not claim.

This case supports enterprise application learning, operational architecture, workflow and permission design, organization-wide launch, adoption support, integration, and continuing platform ownership. It also shows the value of preserving useful vendor work instead of treating rescue as replacement.

It does not disclose vendor criticism, implementation cost, infrastructure, access methods, security configuration, utility assets, locations, capacity, customer information, or production screens. Approximately 100 employees describes organizational scope, not verified active use by every employee. No ROI, uptime, adoption percentage, or transaction count is asserted.