A client came to us with a challenge that emerged as their program continued to grow.
What started as a single bureau expanded into multiple groups with overlapping responsibilities. Some users needed visibility across programs, while others only needed to focus on the events they were directly involved in.
As a result, the same system structure was expected to support very different visibility needs.
The core issue wasn’t access—it was noise.
Certain users were seeing more events than they needed, creating confusion and frustration. At the same time, other roles required broader visibility to effectively manage programs across teams.
The initial instinct was to solve this structurally.
One proposed solution involved introducing a separate hierarchy for specific programs, allowing events to be segmented into parallel organizational structures. This would give tighter control over visibility but came with tradeoffs—duplicated structures, increased maintenance, and fragmented reporting across what were logically the same territories.
The challenge wasn’t whether this approach would work—it was whether it was the right level of complexity for the problem.
Instead, we stepped back and reframed the issue.
Rather than restructuring how events were organized, we focused on how they were presented to users.
By leveraging configurable event grid presets and role-based filtering, we were able to create default views that showed users only the events they were directly involved in—while still allowing access to broader data when needed.
This approach reduced noise without introducing additional structural complexity, and it avoided the long-term overhead of maintaining parallel hierarchies.
The result is a more flexible system that supports different user needs without overengineering the underlying structure.
The takeaway? When systems become complex, it’s tempting to solve problems by adding more structure. But often, the better solution is simplifying how users interact with the system—not how the system is built.
