For 17 years, Western University has relied on Cascade CMS to manage its web presence. So when Western Technology Services set out to rebuild its IT Service Catalog, the team wasn't looking for a new content management system. They were looking for a better way to manage and publish service information.
The goal was ambitious: replace a static services document with a dynamic, self-maintaining catalog that pulls from a single source of truth. Rather than storing service information directly in Cascade CMS, Western paired it with Atlassian Assets, using Cascade as the publishing engine for hundreds of automatically generated service pages.
The project pushed Cascade well beyond traditional content management and created a model for managing structured content at scale.
Before launching the new catalog, Western Technology Services relied on a traditional services document describing available offerings, pricing, and support information.
Over time, maintaining that document became increasingly difficult.
"We didn't really have a service catalog," explained Judy Steward, Associate Director of Services and Application Support. "We had what was called a services document. It would talk about some of the services and how to obtain them, but there was never anything as slick as this."
As ownership changed and the document became harder to maintain, keeping information current became a growing challenge. Users often had to contact the help desk simply to learn what services existed or whether they qualified for them.
The team wanted something more comprehensive, easier to maintain, and capable of staying accurate without someone manually updating every page.
The first architectural decision shaped everything that followed: where should the service data live?
Rather than storing service information in Cascade CMS, Western chose Atlassian Assets, where it could integrate directly with existing Jira Service Management workflows.
Each service is maintained as structured data within Assets and follows an established governance process involving service managers, service owners, and communications staff before publication.
"The services are all edited within Assets and then pulled over into Cascade and published out to the web server," Judy explained.
This approach separates content from presentation. Service owners maintain information in one authoritative system while Cascade focuses on delivering a consistent web experience.
While Atlassian Assets serves as the system of record, Cascade CMS powers the public-facing experience.
Western built an integration that synchronizes approved service data from Atlassian into Cascade through the Cascade API. When information changes in Assets, an integration layer automatically creates or updates corresponding pages in Cascade, populating structured data fields without manual entry.
"We are creating and managing all these pages through the API," said Caio Mello, Senior Software Engineer. "The integration sends us JSON payloads that fit exactly into the data structure we built in Cascade."
Rather than functioning primarily as a place where editors write content, Cascade serves as a publishing engine. Atlassian Assets owns the service data, while Cascade manages page structure, presentation, navigation, and publishing workflows.
Even if the integration were unavailable, staff could still edit content directly through Cascade's structured editing interface.
One of the project's biggest advantages is how little manual maintenance the catalog requires.
Service pages include structured metadata such as audiences, categories, and related services. Cascade's Velocity templates automatically generate category pages, audience listings, service counts, navigation elements, and related-service relationships from that metadata.
When a service owner changes a category assignment, the service automatically appears everywhere it should across the catalog.
"The only thing you need to update is the service itself," explained Caio. "You don't need to keep updating the index pages because everything is dynamically loaded."
For a catalog that may ultimately contain hundreds of services, this automation dramatically reduces maintenance while ensuring information stays consistent throughout the site.
The catalog wasn't designed only to make maintenance easier—it was built to help students, faculty, staff, and other campus users quickly find the services they need.
Visitors can browse services specifically available to students, faculty, staff, alumni, researchers, and other audiences.
According to Judy, this has become one of the catalog's most appreciated features.
"People are definitely enjoying the audience piece. Those are exactly the kinds of questions we get: 'I'm a former student, what do I have access to?'"
Users can search not only by official service names but also by aliases and related keywords. Searching for "Excel," for example, returns relevant Microsoft application services even when "Excel" doesn't appear in the service title.
A custom breadcrumb system adapts based on how visitors arrive at a page. Whether someone browses by category, audience, or a direct link, navigation reflects their journey while maintaining clean, shareable URLs.
Every service page includes a feedback mechanism that connects directly to Western's service management processes, allowing users to report issues or request assistance without searching for the right contact.
Because service information directly affects support operations, Western implemented a publishing workflow that balances governance with efficiency.
Changes first publish automatically to a development environment, where service owners review them before communications staff publish updates to production.
This approach allows distributed teams to maintain their own service information while ensuring the public website remains consistent in both structure and presentation. Service owners update facts; Cascade enforces formatting, branding, and publishing standards.
One unexpected benefit has been the catalog's role in defining service boundaries.
Previously, users had limited visibility into which IT services were officially supported. The new catalog creates a shared understanding between service providers and the campus community.
"We can now establish a line between what is actually supported and what is not," said Caio.
Each service page clearly outlines eligibility, documentation, support information, and related resources, reducing ambiguity and helping users understand exactly what they can expect.
Western's service catalog is already in active use across campus, but the team continues to refine it. Priorities include expanding catalog coverage, improving audience-based navigation based on user feedback, and further streamlining the integration between Atlassian Assets and Cascade.
The project has also changed how the team thinks about Cascade's role. Rather than serving solely as a place where staff author content, it now functions as a dynamic presentation layer for structured data maintained elsewhere.
"The technology wasn't the biggest concern," Judy reflected. "The bigger challenge was consolidating the information and figuring out what our services actually were."
With that foundation now in place, the harder work is done.
Let's talk! Don't hesitate to contact us if you want tailored guidance on your content strategy or a demonstration of how Cascade CMS balances flexibility with brand protection.
To learn more about how Cascade CMS and Clive Web Personalization can help your institution reach more students than ever before, reach out to our team.
Last Updated: Oct 21, 2026 9:00 AM
