Hey @ColleenE -
I’d be a little cautious about layering Category → Subcategory on top of the existing HRSD structure, since HR Services are already tied to COE → Topic Category → Topic Detail. That hierarchy is meant to provide the classification and grouping out of the box.
If the Category/Subcategory setup is being used to describe things that are already represented at the Topic Category or Topic Detail level, it can start to feel redundant and add extra maintenance without much real benefit.
In many cases, those Subcategories are actually better off being their own HR Services, especially if they have unique workflows, SLAs, or fulfillment paths. Each HR Service should represent a distinct action or request — not just a label under another one.
A good way to decide: if the Subcategory triggers a different process or would need to be reported on separately, it probably deserves to be its own HR Service. If not, it might fit better as part of the existing Topic Detail structure.
I’ve also seen (and built) cases where an additional field is created to help further categorize a service — typically when the HR Service name includes something like “General.”
For example, employees might not know exactly what they’re looking for and choose a service such as “General HR Question.” In those cases, we’ve added a field like “General HR Question Type” with a predefined list of options (usually provided by the client with our help).
This approach keeps the HRSD structure clean while still offering flexibility for broad or catch-all services.
Something like this:
In closing, there’s no single “right” answer here — it really depends on the client’s structure and how they want their catalog to scale. But overall, it’s worth considering whether those Categories or Subcategories are actually representing distinct requests. If so, they might be better implemented as their own HR Services.
Hope this helps!
-Rob
